Compartilhar via


Azure DevOps Server 2022 Notas de Atualização da Versão 2


| Comunidade de Desenvolvedores | Requisitos do Sistema e Compatibilidade | Termos de Licença | Blog DevOps | Hashes SHA-256 |


Neste artigo, você encontrará informações sobre a versão mais recente do Azure DevOps Server.

Para saber mais sobre como instalar ou atualizar uma implantação Azure DevOps Server, consulte Azure DevOps Server Requisitos.

Para baixar os produtos do Azure DevOps Server, visite a página de Downloads do Azure DevOps Server.

A atualização direta para o Azure DevOps Server 2022 Atualização 2 é suportada a partir do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2013 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.


Data de lançamento do Patch 7 do Azure DevOps Server 2022 Atualização 2: 11 de novembro de 2025

File SHA-256 Hash
devops2022.2patch7 73523C82BA4F910170E812C1B43374146BFD0EA9A29E2B0DA50A096360E1461F

Lançamos o Patch 7 para o Azure DevOps Server 2022 Atualização 2 para incluir o seguinte:

  • Atualização de proxy do TFVC: o algoritmo de hash usado no processo de autorização foi atualizado de SHA-1 para SHA-256. Para garantir a compatibilidade e evitar interrupções, atualize o proxy junto com o servidor.
  • Resolvido um problema com binários não assinados nas tarefas MSBuildV1 e VSBuildV1.
  • Desempenho otimizado para o executor da etapa DeleteJobDefinitionsByExtensionName.

Data de lançamento do Patch 6 do Azure DevOps Server 2022 Atualização 2: 10 de junho de 2025

Important

Atualização de 25 de julho: estamos investigando um problema com o Patch 6 para o Azure DevOps Server 2022.2. Nossa equipe está trabalhando ativamente para identificar a causa raiz e implementar uma resolução o mais rápido possível. Continuaremos fornecendo atualizações e detalhes neste blog à medida que elas estiverem disponíveis. Obrigado por sua paciência e compreensão.

File SHA-256 Hash
devops2022.2patch6 B0B42C0085045C0B8B8B60C1ECB6D157734758AA24D6A3040A9B57770401A55D

Lançamos o Patch 6 para o Azure DevOps Server 2022 Atualização 2 para incluir os seguintes aprimoramentos de Planos de Teste:

  • Exportar casos de teste com colunas personalizadas no XLSX

Com esse patch, os Planos de Teste dão suporte à exportação de casos de teste com colunas personalizadas, proporcionando maior flexibilidade e controle sobre os dados que você compartilha e analisa. Esse aprimoramento ajuda você a adaptar as exportações às suas necessidades, garantindo que as informações exportadas sejam relevantes e acionáveis.

  • Importar suítes e copiar casos de teste com a ID do plano e a ID da suíte somente na busca.

Data de lançamento do Patch 5 do Azure DevOps Server 2022 Atualização 2: 8 de abril de 2025

File SHA-256 Hash
devops2022.2patch5 299AC29F15BC254167C2987450EF722B083594AFA885A8DAB46625C92D982C1C

Lançamos Patch 5 para Azure DevOps Server 2022 Update 2 para incluir:

  • Anteriormente, o Agente do Azure DevOps usava a CDN do Edgio com endpoint vstsagentpackage.azureedge.net. Como parte da aposentadoria de Edgio, o domínio *.azureedge.net está sendo desativado. Para garantir a disponibilidade contínua, migramos para uma CDN com suporte do Akamai com um novo endpoint download.agent.dev.azure.com. Esse patch inclui as alterações necessárias para buscar os binários do Agente do novo ponto de extremidade cdn, migrando assim para longe do ponto de extremidade da CDN anterior.

Data de lançamento do Patch 4 do Azure DevOps Server 2022 Atualização 2: 11 de março de 2025

File SHA-256 Hash
devops2022.2patch4 975B0FC28737C15BA40D6E084663D1A735A66FA821EB40C7A377AE3D58F0C7DA

Lançamos o Patch 4 para o Azure DevOps Server 2022 Update 2 com o objetivo de incluir:

  • Atualize as tarefas devido à descontinuação da CDN do Edgio. Confira a postagem no blog Troca de Provedores de CDN para obter mais detalhes.
  • Atualizada a dependência do Mermaid.

Data de lançamento do Azure DevOps Server 2022 Atualização 2 Patch 3: 11 de fevereiro de 2025

Note

Na segunda-feira, 24 de fevereiro de 2025, relançamos o Patch 3 para o Azure DevOps Server 2022.2. Se você já instalou a versão anterior deste patch, atualize-a usando o link fornecido. Este relançamento resolve um problema que causa falha nos pipelines YAML. Mais detalhes sobre o problema podem ser encontrados na Comunidade de Desenvolvedores do .

File SHA-256 Hash
devops2022.2patch3 F5C2DA846B8A38A1FB55D1EB555FB2FD6B974B0436F573CC01A0FEBAF3D67521

Lançamos patch 3 para o Azure DevOps Server 2022 Atualização 2 para incluir:

Data de lançamento do Patch 2 do Azure DevOps Server 2022 Atualização 2: 12 de novembro de 2024

File SHA-256 Hash
devops2022.2patch2.exe 70930BE091607B490890A48C250DAB6C2087F7F610CC695C9C632C679A491D23

Lançamos o Patch 2 para Azure DevOps Server 2022 Atualização 2 com o objetivo de incluir uma correção para uma dependência vulnerável.

Azure DevOps Server 2022.2 RTW Data de lançamento: 9 de julho de 2024

Resumo das novidades no Azure DevOps Server 2022.2 RTW

Note

Relançamos Azure DevOps Server 2022.2 para corrigir um problema com o carregamento de nomes do Teams. O problema foi relatado na postagem do blog do Azure DevOps Server 2022.2 RTW agora disponível. Se você instalou a versão do Azure DevOps Server 2022.2 lançada em 9 de julho, poderá instalar o Patch 1 para Azure DevOps Server 2022.2 para corrigir o problema. O Patch 1 não será necessário se você estiver instalando Azure DevOps Server 2022.2 pela primeira vez desde que os links de download foram atualizados para incluir a correção.

Azure DevOps Server 2022.2 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2022.2 RC lançado anteriormente. Você pode instalar diretamente Azure DevOps Server 2022.2 ou atualizar de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou mais recente. Os seguintes problemas e vulnerabilidades foram resolvidos com esta versão:

Azure DevOps Server 2022 Atualização 2 RC Data de lançamento: 7 de maio de 2024

Azure DevOps Server 2022.2 RC inclui muitos novos recursos. Alguns dos destaques incluem:

Você também pode pular para seções individuais para ver todos os novos recursos de cada serviço:


General

Tarefa de publicação de Resultados de Teste

A tarefa Publicar Resultados do Teste agora oferece suporte a anexos de execução de teste para o formato de relatório JUnit.

Nova versão do SDK da Extensão da Web do Azure DevOps

Com esta atualização, estamos lançando uma nova versão do SDK da Extensão da Web do Azure DevOps. O SDK do cliente permite que as extensões da Web se comuniquem com o quadro do host. Pode ser usado para:

  • Notifique o host de que a extensão está carregada ou tem erros
  • Obter informações contextuais básicas sobre a página atual (informações atuais de usuário, host e extensão)
  • Obter informações sobre o tema
  • Obtenha um token de autorização para usar nas chamadas REST de volta ao Azure DevOps.
  • Obter serviços remotos oferecidos pela estrutura de host

Você pode encontrar uma referência completa da API na documentação do pacote azure-devops-extension-sdk. Esta nova versão oferece suporte para os seguintes módulos:

  • Suporte ao módulo ES: O SDK agora oferece suporte a módulos ES (ECMAScript), além dos módulos AMD (Asynchronous Module Definition) existentes. Agora você pode importar o SDK usando a sintaxe do módulo ES, que fornece melhorias de desempenho e reduz o tamanho do aplicativo.

  • Compatibilidade com versões anteriores para módulos AMD: O suporte existente para módulos AMD permanece intacto. Se o seu projeto estiver usando módulos AMD, você poderá continuar a usá-los como antes, sem nenhuma alteração.

Modo de utilização:

Para módulos ES, você pode importar nossos módulos usando a instrução import:

import * as SDK from 'azure-devops-extension-sdk';
// Use the module here

Se você estiver usando módulos AMD, poderá continuar a importar o SDK usando a require função:

require(['azure-devops-extension-sdk'], function(SDK) {

  // Use the module here
});

Boards

Limites para áreas e trajetos de iteração

Os limites desempenham um papel importante na manutenção da saúde e eficiência de um grande serviço global. Com esta versão, estamos introduzindo restrições rígidas de 10.000 por projeto, tanto para caminhos de área quanto de iteração. Visite a página Acompanhamento de trabalho, processo e limites de projeto para saber mais sobre os diferentes limites no serviço.

Capturas de tela de Caminhos de Área e Iteração.

Controles de desenvolvimento e implantação

Agora removemos os controles de Desenvolvimento e/ou Implantação do item de trabalho, dependendo de como seu projeto está configurado. Por exemplo, você pode definir as configurações do projeto para desativar Repos e/ou Pipelines.

Capturas de tela de serviços de DevOps.

Quando você for para o item de trabalho, os controles de Desenvolvimento e Implantação correspondentes serão ocultados do formulário.

Capturas de tela de trabalhos relacionados.

Se você decidir conectar um repositório GitHub ao Azure Boards, o controle de desenvolvimento para repositórios GitHub será exibido.

Capturas de tela do controle de desenvolvimento .

Repos

Nova "Política de Ramificação" impedindo usuários de aprovarem suas próprias alterações

Para melhorar o controle sobre quais alterações o usuário aprova e corresponder a requisitos regulatórios/de conformidade mais rígidos, oferecemos uma opção para impedir que o usuário aprove suas próprias alterações, a menos que seja explicitamente permitido.

O usuário com a capacidade de gerenciar as políticas do ramo agora pode ativar a opção recém-adicionada "Exigir pelo menos uma aprovação em cada iteração" em "Quando novas alterações são feitas". Quando esta opção é selecionada, é necessário pelo menos um voto de aprovação para a última alteração da ramificação de origem. A aprovação do usuário não é considerada em relação a nenhuma iteração anterior não aprovada enviada por ele. Como resultado, a aprovação adicional da última iteração deve ser feita por outro usuário.

A imagem a seguir mostra a solicitação de pull criada pelo usuário A e 4 confirmações adicionais (iterações) feitas a essa solicitação de pull pelos usuários B, C, A novamente e C. Depois que a segunda iteração (commit feito pelo usuário B) foi feita, o usuário C aprovou isso. Naquela época, isso implicava a aprovação do primeiro commit do usuário A (quando a solicitação de pull foi criada) e a política recém-introduzida será bem-sucedida. Após a quinta iteração (último commit do usuário C), a aprovação foi feita pelo usuário A. Isso implicava aprovação para o commit anterior feito pelo usuário C, mas não implicava aprovação para o segundo commit feito pelo usuário A na quarta iteração. Para que a política recém-introduzida seja bem-sucedida, a iteração quatro não aprovada deve ser aprovada pela aprovação do usuário B, C ou de qualquer outro usuário que não tenha feito nenhuma alteração na solicitação de pull.

Imagem de gerenciamento de permissões.

Note

Há um problema conhecido em que as políticas de ramificação tomarão um grupo, configurado como revisor, como entidade de aprovação. Vamos imaginar que haja uma aprovação necessária feita por qualquer usuário do Grupo G. O usuário A é membro desse Grupo G. Depois que o usuário A fornece a aprovação como na imagem acima (após a quinta iteração), a aprovação do Grupo G aprova a alteração feita pelo usuário A. Isso não é esperado e será resolvido na versão RTW.

Suporte a filtros sem blobs e árvores

Important

O recurso é desabilitado por padrão. Para habilitar o recurso, execute a seguinte consulta no Config DB:

exec prc_SetRegistryValue 1,'#\FeatureAvailability\Entries\Git.EnablePartialClone\AvailabilityState\', 1

O Azure DevOps agora dá suporte a duas filtragens adicionais durante a clonagem/busca. Elas são: --filter=blob:none e --filter=tree:0 A primeira opção (clone sem blob) é melhor usada para desenvolvimento regular, enquanto a segunda opção (clone sem árvore) se encaixa melhor nos casos em que você descarta o clone depois, por exemplo, executando uma compilação.

SSH-RSA substituição

Azure Repos fornece dois métodos para os usuários acessarem um repositório git em Azure Repos – HTTPS e SSH. Para usar o SSH, você precisa criar um par de chaves usando um dos métodos de criptografia suportados. No passado, oferecemos suporte apenas ao SSH-RSA e pedimos aos usuários que habilitassem o SSH-RSA aqui.

Com essa atualização, estamos anunciando a substituição do SSH-RSA como um método de criptografia com suporte para se conectar a Azure Repos usando SSH. Você pode ver mais detalhes na postagem no blog Fim do suporte SSH-RSA para Azure Repos.

Pipelines

Evite execuções involuntárias de pipeline

Hoje, se o pipeline YAML não especificar a seção trigger, ele será executado para quaisquer alterações movidas para seu repositório. Isso pode gerar confusão quanto ao motivo de um pipeline ter sido executado e levar a muitas execuções não intencionais.

Adicionamos uma configuração de Pipelines no nível da coleção de projetos e do projeto chamada Desabilitar gatilho de CI YAML implícito, que permite alterar esse comportamento. Você pode optar por não disparar pipelines se a seção de ativação estiver ausente.

 Captura de tela do gatilho de CI YAML.

Reiniciar um estágio quando as aprovações e verificações expirarem.

Quando as aprovações e verificações expiram, o estágio ao qual pertencem é pulado. Etapas que dependem da etapa ignorada também são ignoradas.

Agora é possível repetir um estágio quando as aprovações e verificações expirarem. Anteriormente, isso só era possível quando uma aprovação expirava.

Captura de tela da repetição da etapa.

Ignorar aprovações e verificações

Aprovações e verificações ajudam a proteger o acesso a recursos importantes, como conexões de serviço, repositórios ou pools de agentes. Um caso de uso comum é empregar aprovações e verificações ao realizar a implantação na produção, visando proteger a conexão do serviço ARM.

Digamos que você tenha adicionado as seguintes verificações à conexão de serviço: uma verificação de aprovação, uma verificação de horário comercial e uma verificação de invocação de função do Azure, para impor um atraso entre diferentes regiões.

Agora, imagine que você precisa realizar uma implementação rápida para corrigir um problema. Você inicia uma execução de pipeline, mas ela não prossegue e aguarda a conclusão da maioria das verificações. Você não pode esperar que as aprovações e verificações sejam concluídas.

Com esta versão, tornamos possível ignorar as aprovações e verificações em execução, para que você possa concluir seu hotfix.

Você pode ignorar as verificações de Aprovações, Horário de Funcionamento, Invocar Função do Azure e Invocar API REST.

Ignorar uma Aprovação.

Captura de tela de Evitar uma aprovação.

Ignorar verificação do horário de expediente.

Captura de tela da verificação de Horário Comercial de Bypass.

Ignorar verificação de invocação da Função Azure. Ignorar verificação do horário de expediente.

Captura de tela da verificação do Bypass Invoke da função Azure.

Quando uma verificação é ignorada, você pode vê-la no painel de verificações.

Captura de tela da verificação ignorada.

Você só poderá ignorar uma verificação se for um administrador do recurso no qual as verificações foram definidas.

Captura de tela do modelo YAML necessário.

Executar novamente as verificações da função do Azure invocada

Imagine que você implanta seu sistema em vários estágios. Antes de implantar o segundo estágio, há uma verificação de Aprovação e Invocação de Função do Azure que executa uma checagem de integridade na parte já implantada do sistema.

Ao revisar a solicitação de aprovação, você percebe que a verificação de integridade foi executada dois dias antes. Neste cenário, você pode estar ciente de outra implantação que afetou o resultado da verificação de sanidade.

Com esta atualização, você pode executar novamente as verificações de Invocar Função do Azure e Invocar API REST. Essa funcionalidade está disponível apenas para verificações bem-sucedidas e sem novas tentativas.

Captura de tela da verificação dinâmica.

Note

Você pode executar novamente uma verificação somente se for um administrador do recurso no qual as verificações foram definidas.

Suporte para o GitHub Enterprise Server na verificação necessária do modelo

Os modelos são um mecanismo de segurança que permite controlar os estágios, trabalhos e etapas de pipelines em sua coleção de projetos.

A Verificação de modelo obrigatório permite garantir que um pipeline esteja baseado em um conjunto de modelos aprovados antes que acesse um recurso protegido, como pool de agentes ou conexão de serviço.

Agora você pode especificar modelos localizados em repositórios do GitHub Enterprise Server.

Função de administrador para todos os ambientes

Os ambientes em pipelines YAML representam um recurso de computação no qual você implanta seu aplicativo, por exemplo, um cluster do AKS ou um conjunto de VMs. Eles fornecem controles de segurança e rastreabilidade para suas implantações.

Gerenciar ambientes pode ser bastante desafiador. Isso ocorre porque, quando um ambiente é criado, a pessoa que o cria automaticamente se torna o único administrador. Por exemplo, se você quiser gerenciar as aprovações e verificações de todos os ambientes de forma centralizada, terá que pedir a cada administrador de ambiente para adicionar um usuário ou grupo específico como administrador e, em seguida, usar a API REST para configurar as verificações. Essa abordagem é tediosa, propensa a erros e não é dimensionada quando novos ambientes são adicionados.

Com esta versão, adicionamos uma função de administrador no nível do hub de ambientes. Isso coloca os ambientes no mesmo nível que as conexões de serviço ou pools de agentes. Para atribuir a função de Administrador a um usuário ou grupo, você já precisa ser um administrador do environments-hub ou proprietário da coleção de projetos.

Captura de tela da função de administrador.

Um usuário com essa função de administrador pode administrar permissões, gerenciar, exibir e usar qualquer ambiente. Isso inclui disponibilizar ambientes para todos os pipelines.

Quando você concede a um usuário a função de administrador no nível do hub de ambientes, ele se torna administrador de todos os ambientes existentes e de todos os ambientes futuros.

Validação YAML aprimorada

Para verificar se a sintaxe YAML está correta, você pode usar a funcionalidade Validar do editor da Web do Azure Pipelines. Portanto, é importante que essa funcionalidade capture o maior número possível de problemas YAML.

Captura de tela da validação YAML.

A validação YAML agora é mais completa quando se trata de expressões.

Ao escrever pipelines YAML, você pode usar funções para definir valores variáveis.

Imagine que você defina as seguintes variáveis:

variables:
  Major: '1'
  Minor: '0'
  Patch: $[counter(fromat('{0}.{1}', variables.Major, variables.Minor ), 0)]

A Patch variável é definida usando a counter função e as outras duas variáveis. No código YAML acima, a palavra format é escrita incorretamente. Anteriormente, esse erro não era detectado. Agora, a funcionalidade Validar detectará isso e exibirá uma mensagem de erro.

Captura de tela de definições de variáveis incorretas detectadas.

O Azure Pipelines detectará definições de variáveis incorretas no nível do pipeline/estágio/trabalho.

Em pipelines YAML, você pode ignorar a execução do estágio usando condições. Erros de digitação também podem aparecer aqui, como no exemplo a seguir.

steps:
- task: NuGetCommand@2
  condition: eq(variable.Patch, 0)
  inputs:
    command: pack
    versioningScheme: byPrereleaseNumber
    majorVersion: '$(Major)'
    minorVersion: '$(Minor)'
    patchVersion: '$(Patch)'

A tarefa NuGetCommand é executada apenas se o valor da variável Patch for 0. Novamente, há um erro de digitação na condição e a funcionalidade Validar o exibirá.

Captura de tela da variável Patch.

O Azure Pipelines detectará condições YAML incorretas definidas no nível de pipeline, de estágio ou de trabalho.

APIs REST para ambientes

Um ambiente é uma coleção de recursos que podem ser alvos de implantações realizadas a partir de um pipeline. Os ambientes oferecem histórico de implantação, rastreabilidade de confirmações e itens de trabalho, e mecanismos de controle de acesso.

Sabemos que você deseja criar ambientes programaticamente, por isso publicamos a documentação para sua API REST.

Melhorias na API REST de Aprovações

Melhoramos a localização de aprovações atribuídas a um usuário, incluindo os grupos aos quais o usuário pertence nos resultados da pesquisa.

As aprovações agora contêm informações sobre a execução do pipeline a que pertencem.

Por exemplo, a seguinte chamada https://fabrikam.selfhosted/fabrikam/FabrikamFiber/_apis/pipelines/approvals?api-version=7.2-preview.2&top=1&assignedTo=john@fabrikam.com&state=pending da API REST GET retorna

{
    "count": 1,
    "value":
    [
        {
            "id": "7e90b9f7-f3f8-4548-a108-8b80c0fa80e7",
            "steps":
            [],
            "status": "pending",
            "createdOn": "2023-11-09T10:54:37.977Z",
            "lastModifiedOn": "2023-11-09T10:54:37.9775685Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers":
            [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikam/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/pipelines/approvals/7e80b987-f3fe-4578-a108-8a80c0fb80e7"
                }
            },
            "pipeline":
            {
                "owner":
                {
                    "_links":
                    {
                        "web":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_build/results?buildId=73222930"
                        },
                        "self":
                        {
                            "href": "https://dev.azure.com/buildcanary/26dcfaeb-d8fe-495c-91cb-fec4acb44fbb/_apis/build/Builds/73222930"
                        }
                    },
                    "id": 73222930,
                    "name": "20231109.1"
                },
                "id": "4597",
                "name": "FabrikamFiber"
            }
        }
    ]
}

Os registros do pipeline agora contêm a utilização de recursos.

Os logs de pipeline do Azure agora podem capturar métricas de utilização de recursos, como memória, uso da CPU e espaço em disco disponível. Os registros também incluem recursos usados pelo agente de pipeline e processos filhos, incluindo tarefas executadas em um trabalho.

Captura de tela dos registros, incluindo recursos usados pelo fluxo de trabalho.

Se você suspeitar que sua tarefa de pipeline pode enfrentar restrições de recursos, habilite logs detalhados para que as informações de utilização de recursos sejam injetadas nos logs do pipeline. Isso funciona com qualquer agente, independentemente do modelo de hospedagem.

O agente do Azure Pipelines agora dá suporte ao Alpine Linux

O Agente de Pipeline v3.227 agora oferece compatibilidade com o Alpine Linux, versões 3.13 e posteriores. O Alpine Linux é popular como imagem base para contêineres. Você pode encontrar o agente na página de releases. As versões do agente do Alpine Linux têm um prefixo vsts-agent-linux-musl , por exemplo, vsts-agent-linux-musl-x64-3.227.1.tar.gz.

As tarefas do Azure Pipelines usam o Node.js 16

As tarefas no pipeline são executadas usando um executor, com Node.js usado na maioria dos casos. As tarefas do Azure Pipelines que utilizam o Node.js como executor agora usam o Node.js 16. Como o Node 16 é a primeira versão do Node a oferecer suporte nativo ao Apple Silicon, isso também conclui o suporte completo a tarefas para macOS no Apple Silicon. Agentes executados no Apple Silicon não precisam do Rosetta para funcionar.

À medida que a data de fim da vida útil do Nó 16 avançou, iniciamos o trabalho para executar tarefas com o Nó 20.

Aumentamos os limites do Azure Pipeline para alinhar com o tamanho máximo de 4 MB do template do Azure Resource Manager (ARM).

Você pode usar a Tarefa de Implantação de Modelo do Azure Resource Manager para criar a infraestrutura do Azure. Em resposta aos seus comentários, aumentamos o limite de integração do Azure Pipelines de 2 MB para 4 MB. Isso se alinhará com o tamanho máximo de 4 MB dos Modelos ARM, solucionando restrições de tamanho durante a integração de modelos grandes.

A tarefa AzureRmWebAppDeployment dá suporte à autenticação de ID do Microsoft Entra

As tarefas AzureRmWebAppDeploymentV3 e AzureRmWebAppDeployment@4 foram atualizadas para dar suporte ao Serviço de Aplicativo com a autenticação básica desabilitada. Se a autenticação básica estiver desabilitada no Serviço de Aplicativo, as tarefas AzureRmWebAppDeploymentV3/4 usarão a autenticação do Microsoft Entra ID para executar implantações no endpoint Kudu do Serviço de Aplicativo. Isso requer uma versão recente do msdeploy.exe instalada no agente, como é o caso nos agentes hospedados windows-2022/windows-latest (consulte a referência da tarefa).

Desabilitada a substituição do status da política de cobertura de código para Falha quando a compilação está falhando

Anteriormente, o status da política de cobertura de código era substituído por 'Erro' se a compilação no PR estivesse falhando. Isso foi um obstáculo para alguns de vocês que tinham a compilação como uma verificação opcional e a política de cobertura de código como uma verificação obrigatória para PRs, o que resultou em PRs sendo bloqueados.

Captura de tela de PRs bloqueados.

Agora, a política de cobertura de código não será substituída por 'Falha' caso o build falhe. Esse recurso será habilitado para todos os clientes.

Captura de tela dos resultados após a alteração.

Artifacts

Apresentando o suporte do Azure Artifacts para Caixas de Carga

Temos o prazer de anunciar que o Azure Artifacts agora oferece suporte nativo para caixas de carga. Esse suporte inclui equivalência de funcionalidades em relação aos nossos protocolos existentes, além de crates.io estar disponível como uma fonte upstream. Os desenvolvedores e equipes do Rust agora podem consumir, publicar, gerenciar e compartilhar suas caixas de carga sem problemas, tudo isso enquanto usam a infraestrutura robusta do Azure e permanecem no ambiente familiar do Azure DevOps.

Anúncio de descontinuação para tarefas de pipeline Restauração do NuGet v1 e Instalador do NuGet v0

Se você estiver utilizando as tarefas de pipeline NuGet Restore v1 e NuGet Installer v0, faça a transição imediatamente para a tarefa de pipeline NuGetCommand@2. Em breve, você começará a receber alertas em suas pipelines se a transição não tiver sido feita. Se nenhuma ação for tomada, a partir de 27 de novembro de 2023, seus builds resultarão em falha.

Suporte do Azure Artifacts para auditoria npm

O Azure Artifacts agora dá suporte aos comandos npm audit e npm audit fix. Esse recurso permite que os usuários analisem e corrijam as vulnerabilidades de seus projetos atualizando automaticamente as versões de pacotes inseguros. Para saber mais, visite Use npm audit para detectar e corrigir vulnerabilidades de pacote.

Reporting

Nova experiência de diretório do Dashboard

Ouvimos seus comentários e estamos entusiasmados em apresentar a nova experiência do diretório Dashboard. Ele não apenas apresenta um design de interface do usuário moderno, mas também permite classificar por cada coluna, com a adição da coluna Última configuração . Esta coluna fornecerá melhores insights sobre o uso geral do painel em sua coleção de projetos. Além disso, agora você pode filtrar por painéis no nível da equipe ou do projeto, permitindo acessar apenas a lista do que precisa ver enquanto oculta os painéis que não deseja visualizar.

GIF para demonstração do novo diretório do Painel.

Experimente agora e deixe-nos saber o que você pensa em nossa comunidade Azure DevOps

Filtragem de itens de trabalho

Temos o prazer de anunciar a filtragem de gráfico de item de trabalho. Esse recurso permitirá que você passe o mouse sobre o gráfico de item de trabalho para obter uma visão geral rápida e faça uma busca detalhada em segmentos de gráfico específicos para obter insights detalhados. Você não precisa mais criar consultas personalizadas para acessar os dados exatos de que precisa. Agora você pode explorar seus itens de trabalho nos gráficos dos itens de trabalho com apenas alguns cliques.

Gif de demonstração para filtragem de itens de trabalho.

Seu feedback é inestimável para moldar o futuro desse recurso. Experimente agora e deixe-nos saber o que você pensa em nossa comunidade do Azure DevOps.

Resultados de Code Coverage para pastas

Resultados de cobertura de código agora estão disponíveis para cada arquivo e pasta individual, em vez de apenas como um número de nível superior. A exibição de cobertura de código aparece quando o botão modo de exibição de pasta é alternado. Nesse modo, você pode aprofundar e ver a cobertura de código para essa subárvore selecionada. Use o botão de alternância para alternar entre as visualizações nova e antiga.

Widget de múltiplos repositórios para GA

Test Plans

Cópia rápida e importação com ID do plano de teste ou da suíte

Agora você pode lidar com vários planos de teste no Azure Test Plans com facilidade! Reconhecendo os desafios enfrentados anteriormente com longos menus suspensos para importar, copiar ou clonar casos de teste, especialmente para planos ou conjuntos de teste extensos, tomamos medidas para simplificar seu fluxo de trabalho.

Temos o prazer de anunciar o recurso de pesquisa por ID do Plano de Teste e da Suite. Insira seu Plano de Teste ou ID do Suite para importação ou cópia rápida de Casos de Teste sem atrasos. Esta atualização faz parte do nosso compromisso contínuo de melhorar sua experiência de gerenciamento de testes, tornando-a mais intuitiva e menos demorada.

Gif para demonstração do Plano de Teste, detalhes da pesquisa do ID do Conjunto.

Atualização para o Azure Test Runner

Temos o prazer de compartilhar que o Azure Test Runner foi atualizado para uma versão mais recente. Esta atualização melhora a estabilidade e o desempenho, permitindo que você execute seus testes sem interrupções ou atrasos. Não há mais suporte para a versão mais antiga do Azure Test Runner. Para obter o melhor desempenho e confiabilidade de suas operações de teste, recomendamos que você atualize para a versão mais recente o mais rápido possível.

Quais as novas?

  • Estabilidade e desempenho aprimorados: Fizemos melhorias significativas no Test Runner, resolvendo problemas que alguns usuários enfrentaram. Essa atualização garante um processo de teste mais confiável, minimizando interrupções em seu trabalho.
  • Prompt de atualização: para tornar a transição para a nova versão perfeita, você encontrará um prompt para atualizar. Isso garante que todos possam mudar facilmente para a versão aprimorada conforme sua conveniência, aprimorando a compatibilidade e o desempenho.

Capturas de tela do prompt de atualização.


Feedback

Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la por meio da Comunidade de Desenvolvedores e obter conselhos sobre o Stack Overflow.


Início da página