Notas de versão do servidor do Azure DevOps

| Comunidade de Desenvolvedores | Requisitos do Sistema e Compatibilidade | Termos de Licença | Blog do 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 do Azure DevOps Server, consulte Azure DevOps Server Requirements.

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

A atualização direta para o Servidor do Azure DevOps tem suporte 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 o Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.

Data de lançamento do servidor do Azure DevOps: 9 de dezembro de 2025

O Azure DevOps Server RTW é um pacote cumulativo de correções de bugs e alterações para dar suporte ao SQL Server 2025. Ele inclui todos os recursos no Azure DevOps Server RC lançado anteriormente.

Você pode instalar diretamente o Azure DevOps Server ou atualizar do Azure DevOps Server 2022, 2020, 2019 ou Team Foundation Server 2015 ou mais recente.

Resumo das novidades no Azure DevOps Server RTW

• Alterações de localização mescladas.
• Alterações para dar suporte ao SQL Server 2025.
• Foi corrigido um problema em que nomes longos de repositório ou branch excediam o controle de menu suspenso na configuração do widget Code Tile na página de Dashboards.
• Corrigido o problema em que o estado de PR do GitHub era salvo incorretamente como Fechado para solicitações de pull mescladas e não mescladas ao usar webhooks. O sistema agora depende do indicador booleano mesclado na carga útil do webhook para registrar com precisão o estado correto no banco de dados.
• Correção de um problema de propriedade recursiva que fazia com que o Visual Studio travasse durante os cenários de vinculação do WIT (Work Item Tracking).
• Resolvido um problema em que a página Pool de Agentes em Configurações de Coleção lançava um erro e falhava ao carregar quando o Analytics estava em pausa ou desabilitado. A página agora é carregada corretamente, independentemente do status do Analytics.

Data de lançamento do Azure DevOps Server RC: 7 de outubro de 2025

Resumo das novidades no Azure DevOps Server RC

O Azure DevOps Server apresenta os recursos que lançamos anteriormente em nossa versão hospedada do produto. Você pode ir para seções individuais para ver todos os novos recursos para cada serviço:

• Geral
• Quadros
• Repos
• Pipelines
• #Planos de Teste
• Relatório
• Wiki

Geral

Copiar bloco de código para a área de transferência

Em resposta aos seus comentários na Comunidade de Desenvolvedores, introduzimos um botão Copiar para o portapapéis para todos os blocos de código no markdown processado. Esse aprimoramento está disponível em páginas Wiki, visualizações de arquivo markdown em repositórios, discussões e descrições de solicitação de pull e discussões de item de trabalho.

Permissão de Planos de Entrega adicionada

Como parte de nossos aprimoramentos de segurança contínuos, introduzimos uma nova permissão no nível do projeto Gerenciar Planos de Entrega. Essa alteração foi implementada para impedir o acesso não intencional de leitura/gravação para usuários no grupo Leitores.

Boards

Links AB# em solicitações de pull do GitHub

Como parte de nossos aprimoramentos contínuos na integração Azure Boards + GitHub, temos o prazer de apresentar um novo recurso que simplifica a forma como os links AB# são exibidos. Com essa atualização, os links AB# agora aparecem diretamente na seção Desenvolvimento das solicitações de pull do GitHub, facilitando o acesso a itens de trabalho vinculados sem pesquisar descrições ou comentários.

Esses links só aparecerão quando AB# for incluído na descrição da solicitação de pull. Se você vincular diretamente de um item de trabalho, eles não serão exibidos na seção Desenvolvimento. Além disso, remover o link AB# da descrição o remove do controle de desenvolvimento.

Melhorias na pesquisa do repositório do GitHub

Melhoramos o processo de conexão de um projeto do Azure DevOps a uma organização do GitHub, especialmente benéfico para aqueles com milhares de repositórios. Anteriormente, você poderia ter enfrentado desafios como erros de tempo limite e longos tempos de espera. Essa atualização otimiza a experiência de pesquisa e seleção, eliminando o risco de erros de tempo limite e tornando o processo de conexão mais suave e eficiente.

Integração do GitHub: mostrar o status de build para pipelines YAML

Estamos comprometidos com a obtenção de paridade de recursos entre Pipelines YAML e Clássicos. Um dos principais recursos ausentes foi a capacidade de fornecer um link "Integrado no build" quando o repositório está hospedado no GitHub. Com nossa versão mais recente, resolvemos essa lacuna adicionando uma opção nas configurações de pipeline do YAML para você verificar:

Depois que o build for concluído, o link correspondente aparecerá automaticamente nos itens de trabalho associados, melhorando a história de rastreabilidade geral.

Suporte à API REST para conectar os repositórios do GitHub

Estamos introduzindo novos pontos de extremidade da API REST que permitem automatizar a adição e a remoção de repositórios do GitHub em seus projetos do Azure DevOps. Além disso, aumentamos o limite de repositório por conexão de 500 para 2.000 ao usar esses endpoints.

Esses pontos de extremidade incluem:

• Listando conexões atuais
• Listando repositórios conectados
• Adicionando e removendo repositórios

Também fornecemos um código de exemplo para ajudá-lo a começar.

Alteração para excluir caminhos de área e de iteração

Excluir uma área ou caminho de iteração pode causar interrupções. Ele pode mover itens de trabalho para um novo caminho e pode fazer com que as equipes percam o acesso a seus quadros e listas de pendências. Apesar de avisos e instruções, os caminhos às vezes são excluídos sem que se compreenda completamente as consequências. Para resolver isso, alteramos o comportamento: os caminhos de área e iteração agora só poderão ser excluídos se não forem mais usados por itens de trabalho.

Gerenciamento de marcas aprimorado no formulário de item de trabalho

O gerenciamento de marcas no Azure Boards foi aprimorado para fornecer uma experiência mais simplificada. As marcas excluídas não aparecem mais na lista sugerida em formulários de item de trabalho, garantindo que apenas as marcas ativas sejam exibidas.

Suporte a imagem aprimorado em comentários de item de trabalho

Melhoramos nosso suporte para colar imagens em comentários de item de trabalho. Agora você pode colar imagens diretamente de fontes como Microsoft Teams, emails e documentos do Word na seção de discussão de um item de trabalho

Limite de comentários em item de trabalho na API REST

Para aprimorar a segurança, um novo limite foi definido sobre o número de comentários que podem ser adicionados aos itens de trabalho por meio da API REST. Cada item de trabalho agora dá suporte a um máximo de 1.000 comentários por meio da API. Essa restrição se aplica exclusivamente à API REST, e os usuários ainda podem adicionar comentários manualmente por meio da interface da Web, mesmo além do limite de 1.000 comentários.

O limite dos planos de entrega foi aumentado

Aumentamos o número máximo de Planos de Entrega por projeto de 1.000 para 1.500.

Repos

Nova configuração para desabilitar a criação de repositórios do TFVC

Nos últimos anos, nenhum recurso novo foi adicionado ao TFVC (Controle de Versão do Team Foundation) porque o Git se tornou o sistema de controle de versão preferencial no Azure Repos. Todas as melhorias recentes na segurança, desempenho e acessibilidade foram feitas exclusivamente para repositórios Git, levando a um declínio contínuo no uso do TFVC. Embora alguns ainda dependam do TFVC e não pretendamos remover esse conjunto de recursos, planejamos eliminar gradualmente o TFVC para novos projetos e coleções de projetos, bem como para projetos que atualmente não usam TFVC.

Como parte dessa transição, estamos introduzindo uma nova configuração para "Desabilitar a criação de repositórios TFVC", que afetará apenas a criação de novos repositórios TFVC e não afetará os existentes.

Suporte à IU de submódulos do Git

Muitas equipes usam ativamente submódulos git para organizar sua base de código. Estamos entusiasmados em compartilhar que adicionamos suporte a submódulos Git no Hub de Arquivos. Agora você pode navegar instantaneamente até um repositório de submódulos com apenas um único clique, exatamente para o commit específico referenciado no seu superprojeto. Quando usado como um submódulo, há suporte para os seguintes serviços Git: Azure Repos, GitHub, GitLab e Bitbucket. Há suporte para vários formatos de URL especificados no arquivo .gitmodules, incluindo HTTPS absoluto, SSH e URLs relativas.

Novo painel "Integridade e uso" no hub de arquivos repositório

À medida que os repositórios Git crescem, eles acumulam confirmações, blobs e outros dados, o que pode aumentar a carga na infraestrutura do Azure DevOps, afetando o desempenho e a experiência do usuário. Manter um repositório íntegro é fundamental para garantir desempenho e confiabilidade consistentes.

Para dar suporte a isso, agora monitoramos vários fatores, como tamanho do repositório, frequência de confirmação, conteúdo e estrutura. Se o repositório começar a sobrecarregar a infraestrutura, você poderá receber uma notificação com recomendações de ação corretiva. Ao gerenciar a integridade do repositório, você pode evitar interrupções e garantir operações tranquilas.

Para verificar a integridade do repositório, acesse Azure Repos, > Arquivos e escolha "Integridade e uso" no menu de reticências para acessar o painel Integridade e uso do repositório.

Configurar branches de destino para solicitações de pull

Gerenciar várias ramificações em um repositório pode ser um desafio, especialmente ao criar novas solicitações de pull. Com o novo recurso Configurar Branches de Destino para Solicitações de Pull, agora você pode especificar uma lista de branches de destino preferenciais, garantindo que as sugestões de solicitação de pull sejam mais precisas e relevantes. Isso ajuda a simplificar seu fluxo de trabalho e reduz as chances de segmentar a ramificação errada. Para usar esse recurso, crie um arquivo .azuredevops/pull_request_targets.yml no branch padrão do repositório. Este arquivo YAML deve conter uma lista intitulada pull_request_targets com os nomes de ramos ou prefixos que correspondem aos ramos candidatos. Por exemplo:

pull_request_targets:
  - main
  - release/*
  - feature/*

Nessa configuração, o branch principal é priorizado, mas branches começando com versão/ou recurso/ também serão considerados quando apropriado. A configuração é aplicada nos seguintes cenários:

• Sugestões de pull request: depois de fazer push de um branch para o Azure DevOps, a página de Repos pode sugerir a criação de um pull request a partir desse branch, escolhendo dinamicamente o branch de destino.
• URL da Solicitação de Pull: ao navegar diretamente para a página de criação da solicitação de pull usando um parâmetro sourceRef, mas omitindo o parâmetro targetRef, o Azure DevOps seleciona um branch de destino com base nessa escolha dinâmica.

É recomendável incluir apenas branches protegidos por políticas de solicitação de pull para garantir a consistência no histórico do primeiro pai da confirmação de dica.

Suporte a diagramas de sereia no arquivo markdown

Os arquivos Markdown que contêm a sintaxe mermaid agora serão renderizados como diagramas dentro de visualizações de arquivos no navegador de arquivos repos e em solicitações de pull. Isso pode ajudá-lo a adicionar documentação mais rica aos seus repositórios.

Pesquisar solicitações de pull por título na página de listagem de PR

A página de listagem de solicitações de pull agora inclui um filtro por título de PR, facilitando a localização de solicitações de pull específicas.

Checkout esparso para Repositórios do Azure

O comando git sparse-checkout agora tem suporte na tarefa de check-out do YAML, juntamente com o filtro de clone parcial, para melhorar o desempenho do check-out do repositório. Você pode usar as propriedades sparseCheckoutDirectories e sparseCheckoutPatterns.

A configuração de sparseCheckoutDirectories habilita o modo cone, em que o processo de checkout usa a correspondência de diretório. Como alternativa, você pode definir sparseCheckoutPatterns, o que ativa o modo não cone, permitindo uma correspondência de padrões mais complexa.

Se ambas as propriedades estiverem definidas, o agente inicializará o modo cone com sincronização de diretórios. Se nenhuma propriedade for especificada na tarefa de checkout, o processo de checkout esparso será desabilitado. Qualquer problema encontrado durante a execução do comando resulta na falha da tarefa de checkout. Exemplo YAML para modo cone de checkout esparso:

    checkout: repo
    sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy

   checkout: repo
   sparseCheckoutPatterns: /* !/img 

Você pode encontrar o agente na página de versões.

Tornar as políticas entre repositórios diferenciadoras de maiúsculas e minúsculas

Anteriormente, a pré-visualização do candidato a branch para políticas de repositório cruzado exibia resultados de forma insensível a maiúsculas e minúsculas, apesar da correspondência de branch diferenciar maiúsculas de minúsculas. Essa inconsistência criou um possível desalinhamento, pois dava a impressão de que certas áreas estavam protegidas quando não estavam. Para resolver esse problema, atualizamos a visualização do padrão de branch para se alinhar com o comportamento que diferencia maiúsculas de minúsculas do aplicativo de política.

Antes:

Depois:

Alterações nas políticas de check-in do TFVC

Nova versão (19.254) do pacote NuGet Microsoft.TeamFoundationServer.ExtendedClient

O pacote NuGet Microsoft.TeamFoundationServer.ExtendedClient foi atualizado com novas classes e métodos de política TFVC.

Alterações na política

Estamos fazendo alterações na forma como as políticas de check-in do TFVC são armazenadas no Azure DevOps, o que também significa atualizações de como o NuGet Microsoft.TeamFoundationServer.ExtendedClient se comunica com o serviço. Se o projeto TFVC usar políticas de check-in, migre essas políticas para o novo formato. Há duas maneiras de fazer isso:

1. Usando o Visual Studio.

Aviso

Consequências perigosas de uma ação.: verifique se você atualizou o Visual Studio para a versão mais recente antes de continuar (VS 2022, O VS 2019 e o VS 2017 com as versões mínimas 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 são compatíveis com as novas políticas).

Para criar novas políticas usando o administrador do projeto do Visual Studio, abra Configurações –> Projeto de Equipe –> Controle do Código-Fonte –> Política de Check-in e adicione uma nova política (sem a marca "Obsoleta") com os mesmos parâmetros que o antigo:

2. Se você estiver usando a implementação personalizada de Microsoft.TeamFoundationServer.ExtendedClient para se comunicar com o servidor, siga o guia de migração. A migração é necessária para manter o check-in do TFVC compatível com as versões futuras do Azure DevOps. Por enquanto, as políticas antigas (obsoletas) e novas permanecem válidas e funcionais. Para obter informações sobre os Planos Futuros, consulte nossa postagem no blog.

Aprimoramento da API GetRepository

Adicionamos a propriedade creationDate à resposta de Repositórios – Get Repository API, que retorna a data de criação do repositório. A propriedade está disponível nas versões de API 7.2 e posteriores.

Aprimoramento da API de consulta de pull requests

Introduzimos uma nova propriedade Label na resposta da Consulta de Solicitação de Pull – Obter API. Agora você pode especificar se deve incluir rótulos (marcas) para solicitações de pull relacionadas em cada consulta. Uma nova propriedade "Include" está disponível — se definida como "Labels", a resposta incluirá os rótulos das PRs especificadas. Se forem deixados como nulos, os rótulos não serão incluídos. Para evitar erros não intencionais, verifique se NotSet não está atribuído explicitamente , isso resultará em Solicitação Incorreta.

Exemplo de conteúdo da solicitação:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Pipelines

O TFX valida se uma tarefa está usando um executor de Nó de Fim de Vida

Os autores de tarefas usam o TFX para publicar extensões. O TFX foi atualizado para realizar validações em outras versões do Node runner.

As extensões que contêm tarefas utilizando uma versão do executador de Node que chegou ao fim de vida (EOL) (até e incluindo o Node 16) receberão este aviso:

Task < TaskName > depende de um executor de tarefas que chegou ao fim de sua vida útil e será removido no futuro. Os autores devem examinar as diretrizes de atualização do Node: https://aka.ms/node-runner-guidance

Acessar o Barramento de Serviço do Azure nos Pipelines usando a autenticação do Microsoft Entra ID

Agora você pode usar autenticação do Microsoft Entra ID para acessar o Barramento de Serviço do Azure no Azure Pipelines. Isso permite que você aproveite o RBAC do Azure para controle de acesso refinado.

As identidades que acessam o Barramento de Serviço do Azure precisam receber uma das funções internas do Azure para o Barramento de Serviço do Azure no Barramento de Serviço acessado.

tarefa PublishToAzureServiceBus@2

As novas tarefas de PublishToAzureServiceBus@2 podem ser configuradas usando uma conexão de serviço do Azure. Crie uma conexão de serviço do Azure e preencha as propriedades serviceBusQueueName e serviceBusNamespace da nova tarefa:

- task: PublishToAzureServiceBus@2
  inputs:
    azureSubscription: my-azure-service-connection
    serviceBusQueueName: my-service-bus-queue
    serviceBusNamespace: my-service-bus-namespace
    useDataContractSerializer: false
    messageBody: |
      {
        "foo": "bar"
      }

Tarefas do servidor

Tarefas de servidor personalizado (sem agente) que usam a execução do ServiceBus podem especificar uma Conexão de Serviço do Azure como EndpointId e omitir ConnectionString. Consulte a criação de tarefas do servidor.

O TFX valida se uma tarefa está usando um executor de Nó de Fim de Vida

Os autores de tarefas usam o TFX para publicar extensões. O TFX foi atualizado para realizar validações em outras versões do Node runner.

As extensões que contêm tarefas utilizando uma versão do executador de Node que chegou ao fim de vida (EOL) (até e incluindo o Node 16) receberão este aviso:

Task < TaskName > depende de um executor de tarefas que chegou ao fim de sua vida útil e será removido no futuro. Os autores devem examinar as diretrizes de atualização do Node: https://aka.ms/node-runner-guidance

As tarefas que usam uma versão final do Executor de nós para executar emitem avisos

As tarefas de pipeline que dependem de uma versão do Node.js não mantida começarão a receber avisos: a tarefa TaskName depende de uma versão do Node.js (10) que chegou ao fim de sua vida útil. Entre em contato com o proprietário da extensão para obter uma versão atualizada da tarefa. Os mantenedores de tarefas devem examinar as diretrizes de atualização do Node: https://aka.ms/node-runner-guidance para suprimir esses avisos, você pode definir uma variável de ambiente ou de pipeline no nível do pipeline (job) ou da tarefa. Por exemplo:

variables:
  AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false

DockerCompose@0 usa o Docker Compose v2 no modo de compatibilidade v1

O Docker Compose v1 atingirá seu fim de vida útil e será removido dos Agentes Hospedados em 24 de julho de 2024. Atualizamos a tarefa DockerCompose@0 para usar o Docker Compose v2 no modo de compatibilidade v1 se o Docker Compose v1 não estiver disponível no agente.

No entanto, o modo de compatibilidade não resolve todos os problemas de compatibilidade. Veja Migrar para Compose V2. Alguns usuários precisarão de mais tempo para atualizar seus projetos do Docker Compose para compatibilidade do Docker Compose v2. Nesses casos, siga estas instruções para usar a tarefa DockerComposeV0 com docker-compose v1. OBSERVAÇÃO: Este guia é baseado na documentação autônoma do Install Compose. Use docker-compose v1 no Windows. Adicione a etapa do PowerShell ao pipeline para baixar o docker-compose v1.29.2 e usá-lo com a tarefa DockerComposeV0 no Windows.

variables:
    dockerComposePath: C:\docker-compose

steps:
- powershell: |
    mkdir -f $(dockerComposePath)
    # GitHub now requires TLS1.2. In PowerShell, run the following
    [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
    Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: '**/docker-compose.yml'
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
    dockerComposePath: /tmp/docker-compose

steps:
- bash: |
    sudo mkdir $(dockerComposePath)
    sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
    sudo chmod 755 $(dockerComposePath)/docker-compose
  displayName: Download docker-compose
- task: DockerCompose@0
  inputs:
    containerregistrytype: 'Azure Container Registry'
    dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
    action: 'Run a Docker Compose command'
    dockerComposeCommand: 'run'
    dockerComposePath: $(dockerComposePath)/docker-compose

Test Plans

Extensão de Teste e Comentários no Manifesto V3

Estamos entusiasmados em anunciar uma nova atualização para a extensão de Teste e Comentários do Azure DevOps para Chrome e Edge. Esta atualização faz a transição de nossa implementação do Manifesto V2 para a V3, de acordo com o cronograma de descontinuação do Google para o Manifesto V2. Embora os principais recursos da extensão permaneçam inalterados, a atualização aprimora a segurança e o desempenho.

Para obter mais detalhes, confira nossa postagem recente no blog sobre essa atualização. Extensão de teste e feedback no Manifest V3

Azure Test Runner versão 1.2.2

Os Planos de Teste do Azure lançaram uma correção na 1.2.2 para um problema recente nos Planos de Teste em que o ATR (Azure Test Runner) apresentou falhas de inicialização no Chrome versão 130. Esse problema surgiu devido ao suporte adicionado do Chrome para URLs de esquema não especiais, que afetaram o fluxo de usuário do ATR. Com essa atualização, o bug de regressão é resolvido e a funcionalidade atr é restaurada. Para obter mais detalhes sobre esse bug de regressão, visite este rastreador de problemas no Chromium.

Incentivamos você a usar o aplicativo Web para recursos aprimorados. Se você encontrar recursos ausentes no aplicativo Web, adoraremos ouvir de você. Compartilhe seus comentários conosco!

Integração sem problemas do pipeline de build para execução de casos de teste

Simplificamos o processo de execução do caso de teste integrando perfeitamente as configurações do pipeline de build. As definições de compilação e as IDs definidas no nível do plano de teste agora se propagam automaticamente para o Web Runner, eliminando a necessidade de configuração manual a cada vez. Essa melhoria economiza tempo e aumenta a eficiência, permitindo que você se concentre em tarefas mais críticas.

Restaurar planos de teste excluídos e conjuntos de testes usando a API REST

Restaure facilmente planos de teste excluídos e conjuntos de testes com novas APIs de autoatendimento. Estamos introduzindo APIs GET e PATCH que permitem que você pesquise planos ou conjuntos de testes excluídos e os restaure junto com seus itens filho, sem precisar de auxílio do suporte ao cliente. Com essas APIs, você pode recuperar rapidamente itens de trabalho de teste excluídos acidentalmente, reduzindo o tempo de inatividade e melhorando a produtividade. Embora os artefatos de execução não sejam restaurados, todos os planos de teste, suítes de teste e casos de teste relacionados podem ser trazidos de volta à sua área de trabalho com facilidade. Esse recurso de autoatendimento oferece maior controle sobre o gerenciamento de testes e simplifica o processo de restauração, tornando-o mais rápido e eficiente para recuperar ativos de teste críticos.

Exportar casos de teste com colunas personalizadas no XLSX

Agora você pode exportar casos de teste com colunas personalizadas no XLSX. Com base em seus comentários, 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.

Novos recursos de classificação no diretório do Test Plans

O diretório Planos de Teste agora oferece opções de classificação aprimoradas! Com essa atualização, você pode organizar rapidamente cada coluna alfanumericamente, fornecendo uma maneira simplificada de localizar e acessar seus dados.

Desfazer etapa de teste no runner da Web e de desktop

Assuma o controle sobre a execução do caso de teste com a nova opção "Desfazer". Você pode reverter facilmente os status da etapa de teste com um simples clique duplo, proporcionando mais flexibilidade e controle durante as execuções de teste. Não é mais necessário reiniciar casos de teste para corrigir cliques acidentais—basta desfazer e seguir com o fluxo de trabalho sem interrupção.

Também estamos introduzindo melhorias de navegação e acessibilidade amigáveis ao teclado para garantir que esse recurso funcione perfeitamente para todos os usuários, incluindo aqueles que dependem de tecnologias adaptativas. Esse aprimoramento ajuda você a economizar tempo, reduzir a frustração e manter o foco na execução de testes com eficiência.

Publicar os aprimoramentos da tarefa de resultados da cobertura de código v2

Com esta versão, estamos incluindo várias melhorias na tarefa v2:

• Suporte expandido para vários formatos de cobertura de código, incluindo: .coverage,.covx,.covb,.cjson,.xml,.lcov e pycov1.

• Geração de um arquivo cjson abrangente (e um relatório de cobertura de código) que contém informações detalhadas de cobertura de código, como nomes de arquivo, linhas cobertas/não cobertas etc.

Suporte para cobertura diferente (cobertura de PR): v2 pode gerar comentários de PR de cobertura diferente para vários idiomas no mesmo pipeline.

Agora, a tarefa v2 dá suporte à tarefa Verificação de Qualidade de Build, que não tinha suporte na tarefa v1.

Suporte aos pipelines YAML no Test Plans

Além dos pipelines clássicos, agora você pode usar seus pipelines YAML ao configurar seus Planos de Teste ou executar testes automatizados a partir dos Planos de Teste.

Essa solicitação foi priorizada com base nos seguintes tíquetes de sugestão da Comunidade de Desenvolvedores.

• Permitir que o pipeline YAML seja usado nas configurações do plano de teste

• Executar testes automatizados dos Planos de Teste do Azure usando o pipeline YAML

Reportagem

Dados de colunas cumulativos disponíveis na lista de pendências

Atualizamos as colunas cumulativas para mostrar os mais recentes dados disponíveis. Anteriormente, essas colunas podiam aparecer em branco para itens de trabalho atualizados com frequência, causando confusão. Você também verá um carimbo de data/hora indicando quando os dados foram atualizados pela última vez. Embora algum atraso no processamento no Analytics seja normal, essas melhorias visam fornecer transparência e uma experiência mais suave ao trabalhar com colunas de agregação.

Wiki

Aprimorar a colagem de conteúdo com base em HTML no Wikis

Facilitamos a colagem de conteúdo baseado em HTML em Wikis. Agora, elementos HTML como links, listas, tabelas, imagens, planilhas do Excel, mensagens do Microsoft Teams, emails e consultas do Azure Data Explorer são convertidos automaticamente em sintaxe Markdown para uma edição mais suave.