Atualizações de serviço e melhorias de integração do Azure DevOps

Para ajudar a garantir que seu ambiente do Azure DevOps permaneça seguro, estamos fazendo atualizações de serviço importantes. Isso inclui o fim do suporte para novos registros de aplicativo OAuth a partir de abril de 2025, embora os aplicativos existentes continuem funcionando até a desativação completa em 2026. Além disso, a SNI (Indicação de Nome do Servidor) será necessária para todas as conexões HTTPS a partir de 23 de abril de 2025, juntamente com as atualizações das políticas de check-in do TFVC no Azure Repos.

Juntamente com essas atualizações, estamos entusiasmados em anunciar as melhorias mais recentes em nossa integração do Azure Boards + GitHub, facilitando a vinculação de ramificação, solicitações pull e confirmações aos itens de trabalho. Além disso, o Pipelines agora fornece maior visibilidade das dependências de estágio YAML, ajudando as equipes a gerenciar fluxos de trabalho mais complexos com eficiência aprimorada.

Confira as notas sobre a versão para obter detalhes.

Geral

• Nenhum novo aplicativo OAuth do Azure DevOps a partir de abril de 2025
• A SNI (Indicação de Nome do Servidor) agora é obrigatória para o Azure DevOps Services

Quadros do Azure:

• Integração do GitHub: melhorias na vinculação a commits, branches e solicitações pull
• Integração do GitHub: mostrar o status de build para pipelines YAML
• Limite de Planos de Entrega aumentado

Azure Repos

• Alterações nas políticas de check-in do TFVC
• Aprimoramento da API GetRepository
• Aprimoramento da API de consulta de pull requests

Azure Pipelines

• Visibilidade aprimorada das dependências do estágio de pipeline do YAML
• Novo Agente CDN
• O nó 16 será removido dos pipelines-* Pacotes de agentes de pipeline

Planos de teste do Azure:

• Descontinuação do registro em log de ação e mudança para gravação de tela
• Pausar automaticamente a execução de teste manual

Geral

Nenhum novo aplicativo OAuth do Azure DevOps a partir de abril de 2025

A partir de abril de 2025, não há mais suporte para novos registros de aplicativos OAuth do Azure DevOps. Este é um primeiro passo em direção à nossa visão de longo prazo de desativar a plataforma OAuth do Azure DevOps. Recomendamos que todos os desenvolvedores que criam aplicativos com base nas APIs REST do Azure DevOps explorem a plataforma de identidade da Microsoft e registrem um novo aplicativo Entra .

Todos os aplicativos OAuth existentes do Azure DevOps continuarão funcionando até a desativação oficial da plataforma em 2026. Saiba mais em nossa postagem no blog aqui.

A SNI (Indicação de Nome do Servidor) agora é obrigatória para o Azure DevOps Services

A partir de 23 de abril de 2025, exigiremos a Indicação de Nome do Servidor (SNI) em todas as conexões HTTPS de entrada com o Azure DevOps Services.

O SNI é uma extensão para o protocolo TLS que permite que os clientes especifiquem o nome do host ao qual estão se conectando. Todos os navegadores modernos e software cliente dão suporte ao SNI e o usam por padrão, garantindo uma transição perfeita para a maioria dos usuários. Na verdade, mais de 99,995% do tráfego dos clientes que chega aos nossos servidores é compatível com SNI.

No entanto, alguns softwares cliente podem ser incompatíveis com o SNI devido a vários fatores, como bibliotecas de rede desatualizadas, bibliotecas de rede configuradas incorretamente, runtimes ou sistemas operacionais. Problemas também podem surgir de proxies ou firewalls NGFW. As seguintes ferramentas usadas com o Azure DevOps podem ser afetadas por problemas de SNI:

• Clientes Git
• Plug-ins e extensões IDE (Team Explorer Everywhere)
• Software em execução em versões java mais antigas que não dão suporte ao SNI (Java 6 e anterior) ou não têm o SNI habilitado por padrão (algumas versões do Java 7 e 8)
• Versões antigas do navegador (consulte https://caniuse.com/sni)

Os problemas de SNI geralmente se manifestam por erros de conexão, como:

• ERR_SSL_PROTOCOL_ERROR, ERR_CERT_COMMON_NAME_INVALID
• javax.net.ssl.SSLHandshakeException, javax.net.ssl.SSLException
• Não foi possível estabelecer uma relação de confiança para o canal seguro SSL/TLS

É possível validar a compatibilidade de SNI do seu sistema chamando o URL de status do Azure DevOps, que configuramos para exigir SNI. Se essa chamada for bem-sucedida, ela indicará que o host, incluindo seu sistema operacional e ambiente de rede, é compatível com SNI. Para obter instruções detalhadas sobre como testar, visite nossa postagem no blog.

Azure Boards

Integração do GitHub: melhorias na vinculação a commits, branches e solicitações pull

Estamos aprimorando continuamente a integração de Boards + GitHub para fechar lacunas de usabilidade e alinhar-se com a experiência com a qual você está familiarizado no Azure Repos.

Com essa atualização, introduzimos várias melhorias para simplificar como ramificações, solicitações pull e confirmações estão vinculadas a itens de trabalho:

• Quando um branch do GitHub está vinculado a um item de trabalho, todas as solicitações de pull associadas agora serão vinculadas automaticamente. Não é necessário usar o AB#manualmente.

• Depois que uma solicitação de pull for mesclada, a confirmação de mesclagem será vinculada automaticamente ao item de trabalho.

• Se a ramificação for excluída depois que a solicitação pull for mesclada, a vinculação da ramificação será removida automaticamente do item de trabalho.

Essas melhorias facilitam o acompanhamento do progresso do desenvolvimento e a manutenção de associações de itens de trabalho limpas atualizadas.

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.

O limite dos planos de entrega foi aumentado

Anteriormente, limitamos os Planos de Entrega por projeto a 1.000. Com essa atualização, aumentamos o máximo de Planos de Entrega por projeto para 1.500. Você pode saber mais sobre como adicionar e editar Planos de Entrega na documentação aqui.

Azure Repos

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

Nova versão (19.255.0-preview) 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.

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 para Microsoft.TeamFoundationServer.ExtendedClient 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 uma propriedade creationDate à resposta de Repositórios – Obter a data de criação do repositório retornando a API do Repositório. A propriedade está disponível nas versões 7.2-preview de API e superiores.

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 Rótulos, a resposta incluirá os rótulos para as PRs especificadas. Se deixado como null, os rótulos não serão incluídos. Para evitar erros não intencionais, certifique-se de que NotSet não foi atribuído explicitamente - isso resultará em Bad Request.

Exemplo de conteúdo da solicitação:

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

Azure Pipelines

Visibilidade aprimorada das dependências do estágio de pipeline do YAML

Os pipelines YAML fornecem flexibilidade para gerenciar fluxos de trabalho complexos, mas visualizar dependências de estágio tem sido um desafio, especialmente em implantações de várias regiões.

Nem sempre foi claro como os estágios estão conectados. Por exemplo, determinar se CUS3 depende do WUS1, além de WUS2 e WUS3, é necessário examinar o YAML diretamente.

Com esse sprint, as dependências de estágio agora são exibidas quando um estágio é expandido, fornecendo insights imediatos sobre a ordem de execução e os requisitos upstream.

Novo Agente CDN

Como a CDN do Edgio está sendo desativada, a URL de domínio pertencente ao Edgio https://vstsagentpackage.azureedge.net também será desativada. Estamos adicionando uma nova URL https://download.agent.dev.azure.com de domínio compatível com a nova CDN. Adicione essa nova URL de domínio à sua lista de permissões de firewall. Os downloads do pacote do agente para agentes auto-hospedados falharão quando a URL de domínio antiga for removida. Consulte a postagem para obter mais detalhes.

O nó 16 será removido dos pipelines-* Pacotes de agentes de pipeline

As tarefas do agente podem ser implementadas no PowerShell ou no Node. O agente vem com várias versões do Node.js que as tarefas podem direcionar.

À medida que novas versões do Nó são lançadas, as tarefas são atualizadas para usar novas versões do Nó. Os tempos de execução são incluídos no agente.

À medida que as versões do Node.js saem da janela de manutenção upstream, algumas tarefas de Pipelines ainda dependem dele. O Azure DevOps atualiza as tarefas com suporte para uma versão suportada do Node. Tarefas de terceiros ainda podem precisar de versões mais antigas do Nó para serem executadas.

Para acomodar isso, temos dois tipos de pacotes de agentes do Pipeline:

Se você quiser executar uma tarefa que exija o manipulador de execução do Nó 16 em um agente que não tenha o Nó 16 empacotado, instale o manipulador de execução inserindo a tarefa NodeTaskRunnerInstaller@0 em seu pipeline:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Azure Test Plans

Descontinuação do registro em log de ação e mudança para gravação de tela

Nosso cliente do Azure Test Runner da área de trabalho depende do PSR ( Gravador de Etapas de Problema ), uma ferramenta introduzida no Windows 7 que agora está sendo preterida em versões mais recentes do Windows. Como resultado, a funcionalidade de log de ações em nosso executor de testes da área de trabalho pode deixar de funcionar em futuras atualizações.

Para garantir o acompanhamento de teste ininterrupto, recomendamos alternar para a gravação de tela em nosso executor web, Test &Feedback Extension, que fornece uma maneira moderna e confiável de capturar e gerenciar as etapas de teste. Se você precisar de assistência para fazer a transição para a Extensão de Teste &Comentários, entre em contato com nossa equipe de suporte.

Pausar automaticamente a execução de teste manual

Nunca perca o progresso nas suas execuções de teste com a pausa automática na execução de casos de teste. Esse novo recurso pausa automaticamente a execução do caso de teste se o trabalho for interrompido, garantindo que o progresso parcial seja salvo sem a necessidade de uma pausa manual. Se você se afastar ou fechar a sessão, poderá retomar facilmente o caso de teste exatamente de onde parou, reduzindo o risco de perda de dados e melhorando seu fluxo de trabalho. Ao simplificar o processo de pausa e retomada, a pausa automática ajuda você a manter o foco nos testes sem se preocupar em perder seu progresso. Experimente e deixe-nos saber por email o que você pensa!

Próximas etapas

Vá até o Azure DevOps e dê uma olhada.

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre essas características. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

Você também pode receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigado

Silviu Andrica