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

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

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

Consulte as notas de versão para obter detalhes.

Geral

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

Azure Boards:

• Integração com o GitHub: melhorias na vinculação a commits, branches e pull requests
• Integração com o GitHub: Mostrar o status da compilação para pipelines YAML
• Aumento do limite dos Planos de Entrega

Azure Repos

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

Azure Pipelines (Pipelines do Azure)

• Visibilidade aprimorada nas dependências das fases do pipeline YAML
• Nova CDN do agente
• O Node 16 será removido dos pacotes de agentes de pipelines-*

Planos de teste do Azure:

• Desativação do registro de ações e mudança para gravação de tela
• Pausa automática em 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, deixaremos de suportar novos registos de aplicações OAuth do Azure DevOps. Este é um primeiro passo em direção à nossa visão de longo prazo de desativar a plataforma Azure DevOps OAuth. Recomendamos que todos os desenvolvedores que criam aplicativos sobre as APIs REST do Azure DevOps explorem a plataforma de identidade da Microsoft e registrem um novo aplicativo Entra .

Todos os aplicativos OAuth do Azure DevOps existentes continuarão funcionando até a aposentadoria oficial da plataforma em 2026. Saiba mais em nosso post no blog aqui.

Indicação de Nome do Servidor (SNI) agora obrigatória para os Serviços de DevOps do Azure

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 para os Serviços de DevOps do Azure.

SNI é uma extensão do 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 suportam SNI e usá-lo por padrão, garantindo uma transição perfeita para a maioria dos usuários. Na verdade, mais de 99.995% do tráfego de clientes que chega aos nossos servidores está pronto para SNI.

No entanto, alguns softwares cliente podem ser incompatíveis com o SNI devido a vários fatores, como bibliotecas de rede desatualizadas, mal configuradas, tempos de execução 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
• Plugins e extensões do IDE (Team Explorer Everywhere)
• Software executado em versões mais antigas do Java que não suportam SNI (Java 6 e anteriores) ou não têm SNI ativado 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_NOME_COMUM_INVÁLIDO
• 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

Você pode validar a compatibilidade SNI do seu sistema chamando o endpoint de status do Azure DevOps, que foi configurado para requerer SNI. Se essa chamada for bem-sucedida, ela indica 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 com o GitHub: melhorias na ligação a confirmações, ramificações e pull requests

Estamos continuamente a melhorar a integração Boards + GitHub para colmatar lacunas de usabilidade e alinhar com a experiência com que está familiarizado no Azure Repos.

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

• Quando uma ramificação do GitHub é vinculada a um item de trabalho, todas as solicitações pull associadas serão automaticamente vinculadas. Não há necessidade de usar manualmente AB#.

• Depois que um pedido de pull for integrado, o commit de integração será automaticamente ligado à tarefa.

• Se a ramificação for eliminada após o pull request ser mesclado, o link da ramificação será removido 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 e atualizadas.

Integração com o GitHub: Mostrar o status da compilação para pipelines YAML

Estamos comprometidos a alcançar a paridade de funcionalidades entre YAML e Classic Pipelines. Um recurso importante ausente era a capacidade de fornecer um link "Integrado na compilação" quando seu 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:

Quando a compilação estiver concluída, o link correspondente aparecerá automaticamente nos itens de trabalho associados, melhorando a história geral de rastreabilidade.

Limite dos Planos de Entrega aumentado

Anteriormente, limitávamos os Planos de Entrega por projeto a 1.000. Com esta 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 de 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 na forma como o NuGet Microsoft.TeamFoundationServer.ExtendedClient se comunica com o serviço.

Se o seu projeto TFVC usa 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 Visual Studio, o administrador de projeto deve abrir Configurações -> Projeto de equipe -> Controle do código-fonte -> Política de check-in e adicionar uma nova política (sem a marca "Obsoleta") com os mesmos parâmetros da antiga:

2. Se estiver a usar uma implementação personalizada de Microsoft.TeamFoundationServer.ExtendedClient para 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 futuras versões do Azure DevOps. Por enquanto, tanto as políticas antigas (obsoletas) como as novas permanecem válidas e funcionais. Para obter informações sobre os Planos para o Futuro, consulte nossa postagem no blog.

Aprimoramento da API GetRepository

Adicionamos creationDate propriedade à resposta de Repositories - Get Repository API retornando a data de criação do repositório. A propriedade está disponível nas versões 7.2-preview API e superiores.

Aprimoramento da API de Consulta de Pull Requests

Introduzimos uma nova Label propriedade na resposta de Pull Request Query - Get API. Agora você pode especificar se deseja incluir rótulos (tags) para solicitações pull relacionadas em cada consulta. Uma nova propriedade Include está disponível - se for definida como Labels, a resposta incluirá etiquetas para os PRs especificados. Se deixadas como null, as etiquetas não serão incluídas. Para evitar erros não intencionais, certifique-se de que NotSet não está explicitamente atribuído - isso resultará em Bad Request.

Exemplo de solicitação de carga útil :

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

Azure Pipelines (Pipelines do Azure)

Aprimoramento na visibilidade das dependências de estágios do pipeline YAML

Os pipelines YAML oferecem 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 ficou claro como os estágios estão conectados. Por exemplo, determinar se CUS3 depende de WUS1 além de WUS2 e WUS3 exigiu revisar o YAML diretamente.

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

Novo Agente CDN

Como o Edgio CDN está a ser descontinuado, a URL do domínio da Edgio https://vstsagentpackage.azureedge.net também será descontinuada. Estamos adicionando uma nova URL https://download.agent.dev.azure.com de domínio suportada pela nova CDN. Certifique-se de adicionar este novo URL de domínio à sua lista de permissões do firewall. Os downloads de pacotes de agentes para agentes auto-hospedados falharão quando a URL de domínio antiga for removida. Consulte o post para obter mais detalhes.

O Node 16 será removido dos pacotes de agentes de pipeline-*

As tarefas do agente podem ser implementadas no PowerShell ou no Node. O agente é fornecido com várias versões do Node para as quais as tarefas podem ser direcionadas.

À 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 estão incluídos com o agente.

Como as versões do Node deixam de estar sob manutenção upstream, algumas tarefas dos Pipelines ainda dependem daquelas. O Azure DevOps atualiza as tarefas suportadas para uma versão suportada do Node. As tarefas de terceiros ainda podem precisar de versões mais antigas do Node para serem executadas.

Para responder a isto, temos dois tipos de pacotes de agentes de pipeline:

Se desejar executar uma tarefa que exija o manipulador de execução do Nó 16 em um agente que não tenha o Nó 16 incluído, você poderá instalar o manipulador de execução inserindo a tarefa NodeTaskRunnerInstaller@0 no pipeline:

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

Planos de teste do Azure

Desativação do registro de ações e mudança para gravação de tela

Nosso cliente de desktop Azure Test Runner depende do PSR (Problem Steps Recorder ), 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 teste de desktop pode não funcionar mais em atualizações futuras.

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

Execução de teste manual com pausa automática

Nunca perca o progresso nas suas execuções de teste com a funcionalidade de pausa automática dos 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. Quer se afaste ou feche a sessão, pode facilmente retomar o seu caso de teste exatamente onde parou, reduzindo o risco de perda de dados e melhorando o 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 diga-nos através do e-mail o que pensa!

Próximos passos

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

Como fornecer feedback

Gostaríamos muito de ouvir o que você pensa sobre esses recursos. Use o menu Ajuda para relatar um problema ou fornecer uma sugestão.

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

Obrigado;

Silviu Andrica