Compartilhar via

Notas de versão do Azure DevOps Server 2022 Atualização 1

| 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 1 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 Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 Patch 4: 11 de junho de 2024

Arquivo SHA-256 Hash
devops2022.1patch4.exe 29012B79569F042E2ED4518CE7216CA521F9435CCD80295B71F734AA60FCD03F

Lançamos o Patch 4 para o Azure DevOps Server 2022 Atualização 1 que inclui uma correção para o seguinte.

  • Correção de um problema em itens wiki e de trabalho em que os resultados da pesquisa não estavam disponíveis para projetos que tinham "I" turco em seu nome para a localidade turca.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 Patch 3: 12 de março de 2024

Arquivo SHA-256 Hash
devops2022.1patch3.exe E7DE45650D74A1B1C47F947CDEF4BF3307C4323D749408EE7F0524C2A04D2911

Lançamos o Patch 3 para o Azure DevOps Server 2022 Atualização 1 que inclui correções para o seguinte.

  • Resolvemos um problema em que o Servidor Proxy parava de funcionar depois de instalar o Patch 2.
  • Correção de um problema de renderização na página de detalhes da extensão que afetava idiomas que não eram inglês.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 Patch 2: 13 de fevereiro de 2024

Arquivo SHA-256 Hash
devops2022.1patch2.exe 59B3191E86DB787F91FDD1966554DE580CA97F06BA9CCB1D747D41A2317A5441

Lançamos o Patch 2 para o Azure DevOps Server 2022, Update 1, que inclui correções para o seguinte.

  • Corrigindo o problema de renderização de página de detalhes na extensão Pesquisa.
  • Corrigido um bug em que o espaço em disco usado pela pasta de cache do proxy era calculado incorretamente e a pasta não era limpa corretamente.
  • CVE-2024-20667: vulnerabilidade de execução remota de código do Azure DevOps Server.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 Patch 1: 12 de dezembro de 2023

Arquivo SHA-256 Hash
devops2022.1patch1.exe 9D0FDCCD1F20461E586689B756E600CC16424018A3377042F7DC3A6EEF096FB6

Lançamos o Patch 1 para o Update 1 do Azure DevOps Server 2022, que inclui correções para o seguinte.

  • Impedir a configuração requested for ao enfileirar uma execução de pipeline.

Data de lançamento do Azure DevOps Server 2022 Atualização 1: 28 de novembro de 2023

Observação

Há dois problemas conhecidos com esta versão:

  1. A versão do Agente não é atualizada depois de atualizar para o Azure DevOps Server 2022.1 e usar o Agente de Atualização na configuração do Pool de Agentes. No momento, estamos trabalhando em um patch para resolver esse problema e compartilharemos atualizações na Comunidade de Desenvolvedores à medida que avançamos. Enquanto isso, você pode encontrar uma solução alternativa para esse problema neste tíquete da Comunidade de Desenvolvedores.
  2. Compatibilidade do Maven 3.9.x. O Maven 3.9.x introduziu alterações significativas com o Azure Artifacts atualizando o transporte padrão do Maven Resolvedor para HTTP nativo do Wagon. Isso causa problemas de autenticação 401 para clientes que usam http, em vez de https. Você pode encontrar mais detalhes sobre esse problema aqui. Como solução alternativa, você pode continuar usando o Maven 3.9.x com a propriedade -Dmaven.resolver.transport=wagon. Essa alteração força o Maven a usar o transporte do Wagon Resolver. Confira a documentação aqui para obter mais detalhes.

O Azure DevOps Server 2022.1 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos no Azure DevOps Server 2022.1 RC2 lançado anteriormente.

Observação

Há um problema conhecido com a compatibilidade do Maven 3.9.x. O Maven 3.9.x introduziu alterações significativas com o Azure Artifacts atualizando o transporte padrão do Maven Resolvedor para HTTP nativo do Wagon. Isso causa problemas de autenticação 401 para clientes que usam http, em vez de https. Você pode encontrar mais detalhes sobre esse problema aqui.

Como solução alternativa, você pode continuar usando o Maven 3.9.x com a propriedade -Dmaven.resolver.transport=wagon. Essa alteração força o Maven a usar o transporte do Wagon Resolver. Confira a documentação aqui para obter mais detalhes.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 RC2: 31 de outubro de 2023

O Azure DevOps Server 2022.1 RC2 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos no Azure DevOps Server 2022.1 RC1 lançado anteriormente.

Observação

Há um problema conhecido com a compatibilidade do Maven 3.9.x. O Maven 3.9.x introduziu alterações significativas com o Azure Artifacts atualizando o transporte padrão do Maven Resolvedor para HTTP nativo do Wagon. Isso causa problemas de autenticação 401 para clientes que usam http, em vez de https. Você pode encontrar mais detalhes sobre esse problema aqui.

Como solução alternativa, você pode continuar usando o Maven 3.9.x com a propriedade -Dmaven.resolver.transport=wagon. Essa alteração força o Maven a usar o transporte do Wagon Resolver. Confira a documentação aqui para obter mais detalhes.

O seguinte foi corrigido com esta versão:

  • Correção de um problema nos feeds locais em que as entradas upstream não estavam resolvendo alterações de nome de exibição.
  • Ocorreu um erro inesperado ao alternar as guias do Código para outra guia na página Pesquisa.
  • Erro ao criar um novo tipo de item de trabalho com Ideógrafos unificados chinês, japonês e coreano (CJK). Um ponto de interrogação foi exibido no log RAW no check-in fechado quando o nome ou os arquivos do projeto da equipe incluíam CJK.
  • Correção de um problema durante a instalação da Pesquisa em que a JVM (Máquina Virtual Java) não podia alocar memória suficiente para o processo de Pesquisa Elástica. O widget de configuração de pesquisa agora usará o JDK (Java Development Kit) que é fornecido junto com o Elasticsearch e, portanto, remove a dependência de qualquer JRE (Java Runtime Environment) pré-instalado no servidor de destino.

Data de lançamento do Azure DevOps Server 2022 Atualização 1 RC1: 19 de setembro de 2023

O Azure DevOps Server 2022.1 RC1 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:

Geral

Todas as APIs REST públicas dão suporte a escopos de PAT granulares

Anteriormente, várias APIs REST do Azure DevOps documentadas publicamente não estavam associadas a escopos (por exemplo, leitura de item de trabalho) que levavam os clientes a usar escopos completos para consumir essas APIs por meio de mecanismos de autenticação não interativos, como PAT (tokens de acesso pessoal). O uso de um token de acesso pessoal de escopo completo aumenta o risco quando ele pode cair nas mãos de um usuário mal-intencionado. Esse é um dos principais motivos pelos quais muitos de nossos clientes não aproveitaram ao máximo as políticas do plano de controle para restringir o uso e o comportamento do PAT.

Agora, todas as APIs REST públicas do Azure DevOps agora estão associadas e dão suporte a um escopo de PAT granular. Se você estiver usando um PAT com escopo completo para autenticar em uma das APIs REST públicas do Azure DevOps, considere migrar para um PAT com o escopo específico aceito pela API para evitar acesso desnecessário. Os escopos de PAT granular com suporte para determinada API REST podem ser encontrados na seção Segurança das páginas de documentação. Além disso, há uma tabela de escopos aqui.

As extensões deveriam exibir seus escopos

Ao instalar extensões em sua coleção do Azure DevOps, você pode examinar as permissões necessárias para a extensão como parte da instalação. No entanto, depois de instaladas, as permissões de extensão não ficam visíveis nas configurações de extensão. Isso tem colocado um desafio para os administradores que precisam executar uma revisão periódica das extensões instaladas. Agora, adicionamos as permissões de extensão às configurações de extensão para ajudá-lo a examinar e tomar uma decisão informada sobre mantê-las ou não.

Criar tokens de acesso pessoal para implantar no Marketplace

Conselhos

Última coluna acessada na página Planos de Entrega

A página do diretório Planos de Entrega fornece uma lista dos planos definidos para seu projeto. Você pode classificar por: Nome, Criado por, Descrição, Última Configuração ou Favoritos. Com essa atualização, adicionamos uma coluna última acessada à página de diretório. Isso fornece visibilidade sobre quando um Plano de Entrega foi aberto pela última vez e examinado. Como resultado, é fácil identificar os planos que não são mais usados e podem ser excluídos.

Gif para demonstração do campo Último Acesso na página Planos de Entrega.

Visualizar todas as dependências em Planos de Entrega

Os Planos de Entrega sempre forneceram a capacidade de ver as dependências entre itens de trabalho. Você pode visualizar as linhas de dependência, uma a uma. Com esta versão, melhoramos a experiência permitindo que você veja todas as linhas de dependências em todos os itens de trabalho na tela. Basta clicar no botão de alternância de dependências no canto superior direito do plano de entrega. Clique nele novamente para desativar as linhas.

Gif para demonstrar a visualização de todas as dependências na página Planos de Entrega.

Novos limites de revisão de item de trabalho

Nos últimos anos, vimos coleções de projetos com ferramentas automatizadas gerarem dezenas de milhares de revisões de item de trabalho. Isso cria problemas de desempenho e usabilidade no formulário do item de trabalho e nas APIs REST de relatório. Para atenuar o problema, implementamos um limite de revisão de item de trabalho de 10.000 para o Serviço de DevOps do Azure. O limite afeta apenas as atualizações usando a API REST, não o formulário do item de trabalho.

Clique aqui para saber mais sobre o limite de revisão e como lidar com isso em suas ferramentas automatizadas.

Aumentar o limite de equipe dos Planos de Entrega de 15 para 20

Os Planos de Entrega permitem exibir vários backlogs e várias equipes em sua coleção de projetos. Anteriormente, você podia exibir 15 listas de pendências de equipe, incluindo uma combinação de pendências e equipes de diferentes projetos. Com esta versão, aumentamos o limite máximo de 15 para 20.

Corrigimos um erro na API Obter Links de Itens de Trabalho do Relatório para retornar o valor correto de remoteUrl para tipos de link System.LinkTypes.Remote.Related. Antes dessa correção, estávamos retornando o nome errado da coleção de projetos e uma ID de projeto ausente.

Criar ponto de extremidade REST para consulta temporária

Vimos várias instâncias de autores de extensão tentando executar consultas não salvas passando a instrução WIQL (Work Item Query Language) por meio da querystring. Isso funciona bem, a menos que você tenha uma instrução WIQL grande que atinja os limites do navegador no comprimento de querystring. Para resolver isso, criamos um novo ponto de extremidade REST para permitir que os autores da ferramenta gerem uma consulta temporária. Usar a ID da resposta a ser passada por meio de querystring elimina esse problema.

Saiba mais na página de documentação da API REST de consultas temporárias.

API de exclusão em lote

Atualmente, a única maneira de remover itens de trabalho da lixeira é usando essa API REST para excluir um de cada vez. Esse pode ser um processo lento e está sujeito à limitação de taxa ao tentar fazer qualquer tipo de limpeza em massa. Em resposta, adicionamos um novo endpoint de API REST com a possibilidade de excluir e/ou destruir itens de trabalho em lote.

@CurrentIteration macro em Planos de Entrega

Com essa atualização, adicionamos suporte para a @CurrentIteration macro para estilos nos Planos de Entrega. Essa macro permitirá que você obtenha a iteração atual do contexto de equipe de cada linha em seu plano.

Gif para demonstração da macro CurrentIteration nos Planos de Entrega.

Lógica de redimensionamento de cartão nos Planos de Entrega

Nem todos usam a data de destino e/ou a data de início ao rastrear Funcionalidades e Épicos. Alguns optam por usar uma combinação de datas e caminho de iteração. Nesta versão, melhoramos a lógica para definir adequadamente as combinações de caminho de iteração e de campo de data, dependendo de como elas estão sendo usadas.

Por exemplo, se a data de destino não estiver sendo usada e você redimensionar o cartão, o novo caminho de iteração será definido em vez de atualizar a data de destino.

Gif para demonstrar o link de cópia de comentários.

Melhorias de atualização em lote

Fizemos várias alterações na versão 7.1 da API de atualização em lote do item de trabalho. Isso inclui pequenas melhorias de desempenho e o tratamento de falhas parciais. Ou seja, se um patch falhar, mas os outros não, os outros serão concluídos com êxito.

Clique aqui para saber mais sobre a API REST de atualização em lote.

API de exclusão em lote

Este novo endpoint da API REST para excluir e/ou destruir itens de trabalho em lote agora está disponível publicamente. Clique aqui para saber mais.

Impedir a edição de campos de listas de seleção compartilháveis

Campos personalizados são compartilhados entre processos. Isso pode criar um problema para campos de lista de seleção porque permitimos que os administradores de processo adicionem ou removam valores do campo. Ao fazer isso, as alterações afetam esse campo em cada processo que o usa.

Para resolver esse problema, adicionamos a capacidade do administrador da coleção de "bloquear" um campo de ser editado. Quando o campo de lista de seleção está bloqueado, o administrador do processo local não pode alterar os valores dessa lista de seleção. Eles só podem adicionar ou remover o campo do processo.

Gif para edição de demonstração de campos de lista de seleção compartilháveis.

Nova permissão salvar comentários

A capacidade de salvar somente comentários de item de trabalho tem sido uma solicitação principal na comunidade de desenvolvedores. Estamos entusiasmados em informá-lo de que implementamos esse recurso. Para começar, vamos examinar o cenário mais comum:

"Quero impedir que alguns usuários editem campos de item de trabalho, mas permitir que eles contribuam para a discussão."

Para fazer isso, você precisa ir para o Caminho da Área de Configuração do Projeto de Configurações >> do Projeto. Em seguida, selecione o caminho de área escolhido e clique em Segurança.

Caminho da área

Observe a nova permissão "Editar comentários de item de trabalho neste nó". Por padrão, a permissão é definida como Não definida. Ou seja, o item de trabalho se comportará exatamente como antes. Para permitir que um grupo ou usuário salve comentários, selecione esse grupo/usuários e altere a permissão para Permitir.

Nova permissão

Quando o usuário abrir o formulário de item de trabalho neste caminho de área, poderá adicionar comentários, mas não conseguirá atualizar nenhum dos outros campos.

Edição de demonstração de campos de lista de seleção compartilháveis.

Esperamos que você ame esse recurso tanto quanto nós. Como sempre, se você tiver comentários ou sugestões, informe-nos.

Relatórios de quadros interativos

Relatórios interativos, localizados no hub Boards, estão acessíveis há vários anos em nossa versão hospedada do produto. Eles substituem os gráficos mais antigos de Fluxo Cumulativo, Velocidade e Burndown de Sprint. Com esta versão, estamos disponibilizando-os.

Para exibir esses gráficos, clique na guia Análise localizada nas páginas Kanban Board, Backlog e Sprints.

Relatórios interativos

Repos

Removendo a permissão "Editar políticas" para o criador de branch

Anteriormente, quando você criou um novo branch, você recebe permissão para editar políticas nesse branch. Com essa atualização, estamos alterando o comportamento padrão para não conceder essa permissão mesmo se a configuração "Gerenciamento de permissões" estiver ativada para o repositório.

Imagem de gerenciamento de permissões.

Você precisará da permissão "Editar políticas" concedida explicitamente (manualmente ou por meio da API REST), por herança de permissões de segurança ou através de associação a um grupo.

Tubulações

Projeto atual definido como escopo padrão para o token de acesso à compilação em pipelines clássicos.

O Azure Pipelines usa tokens de acesso ao trabalho para acessar outros recursos no Azure DevOps em tempo de execução. Um token de acesso ao trabalho é um token de segurança gerado dinamicamente pelo Azure Pipelines para cada trabalho em tempo de execução. Anteriormente, ao criar um novo pipeline clássico, o valor padrão do token de acesso era definido como Coleção de Projetos. Com essa atualização, estamos definindo o escopo de autorização de trabalho para o projeto atual como o padrão ao criar um novo pipeline clássico.

Você pode encontrar mais detalhes sobre tokens de acesso relacionados a trabalhos na documentação Acessar repositórios, artefatos e outros recursos.

Alteração no escopo padrão de tokens de acesso em pipelines de build clássicos

Para melhorar a segurança dos pipelines de build clássicos, ao criar um novo, o escopo de autorização do trabalho de build será Projeto, por padrão. Até agora, costumava ser a Coleção de Projetos. Leia mais sobre tokens de acesso ao trabalho. Essa alteração não afeta nenhum dos pipelines existentes. Isso só afeta os novos pipelines de build clássicos que você cria a partir deste ponto.

Suporte do Azure Pipelines para versões de San Diego, Tóquio &Utah do ServiceNow

O Azure Pipelines tem uma integração existente com o ServiceNow. A integração depende de um aplicativo no ServiceNow e de uma extensão no Azure DevOps. Agora atualizamos o aplicativo para trabalhar com as versões de San Diego, Tokyo &Utah do ServiceNow. Para garantir que essa integração funcione, atualize para a nova versão do aplicativo (4.215.2) do repositório ServiceNow.

Para obter mais informações, consulte a documentação Integrar com o ServiceNow Change Management.

Usar URLs de proxy para integração do GitHub Enterprise

O Azure Pipelines integra-se com o GitHub Enterprise Servers local para executar a integração contínua e os builds de PR. Em alguns casos, o GitHub Enterprise Server está por trás de um firewall e exige que o tráfego seja roteado por meio de um servidor proxy. Para dar suporte a esse cenário, as conexões de serviço do GitHub Enterprise Server no Azure DevOps permitem configurar uma URL de proxy. Anteriormente, nem todo o tráfego do Azure DevOps estava sendo roteado por meio dessa URL de proxy. Com essa atualização, estamos garantindo o roteamento do seguinte tráfego do Azure Pipelines por meio da URL do proxy.

  • Obter ramificações
  • Obter informações de solicitação de pull
  • Relatar status de build

As conexões de serviço do Registro de Contêiner agora podem usar identidades gerenciadas do Azure

Você pode usar uma Identidade Gerenciada atribuída pelo sistema ao criar conexões de serviço do Registro do Docker para o Registro de Contêiner do Azure. Isso permite que você acesse o Registro de Contêiner do Azure usando uma Identidade Gerenciada associada a um agente do Azure Pipelines auto-hospedado, eliminando a necessidade de gerenciar credenciais.

Nova conexão do Serviço de Registro do Docker para alterações nas aprovações

Observação

A Identidade Gerenciada usada para acessar o Registro de Contêiner do Azure precisará da atribuição apropriada do RBAC (Controle de Acesso Baseado em Função) do Azure, por exemplo, função AcrPull ou AcrPush.

Tokens automáticos criados para conexão de serviço do Kubernetes

Desde o Kubernetes 1.24, os tokens não foram mais criados automaticamente ao criar uma nova Conexão de Serviço kubernetes. Adicionamos essa funcionalidade de volta. No entanto, é recomendável usar a conexão do Serviço do Azure ao acessar o AKS, para saber mais sobre as diretrizes de Conexão de Serviço para clientes do AKS usando a postagem no blog de tarefas do Kubernetes.

As tarefas do Kubernetes agora dão suporte ao kubelogin

Atualizamos as tarefas KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 e AzureFunctionOnKubernetes@1 para dar suporte ao kubelogin. Isso permite que você direcione o AKS (Serviço de Kubernetes do Azure) configurado com a integração do Azure Active Directory.

O Kubelogin não está pré-instalado em imagens hospedadas. Para garantir que as tarefas mencionadas acima usem kubelogin, instale-a inserindo a tarefa KubeloginInstaller@0 antes da tarefa que depende dela:

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

Aprimoramentos de experiência em permissões de pipeline

Melhoramos a experiência em relação ao gerenciamento de permissões de pipeline para fazer com que o sistema de permissões lembre-se se um pipeline já havia usado um recurso protegido, como uma conexão de serviço.

No passado, ao marcar "Conceder permissão de acesso a todos os pipelines" durante a criação de um recurso protegido e posteriormente restringir o acesso a esse recurso, seu pipeline precisava de uma nova autorização para utilizá-lo. Esse comportamento era inconsistente com a abertura e o fechamento subsequentes do acesso ao recurso, em que uma nova autorização não era necessária. Isto agora está corrigido.

Novo escopo do PAT para gerenciamento de autorização de pipeline, aprovações e verificações.

Para limitar os danos causados pelo vazamento de um token PAT, adicionamos um novo escopo pat, chamado Pipeline Resources. Você pode usar esse escopo PAT ao gerenciar a autorização de um pipeline usando um recurso protegido, como uma conexão de serviço, ou para gerenciar aprovações e verificações para esse recurso.

Captura de tela mostrando atualizações da API REST do Pipelines.

As seguintes chamadas da API REST dão suporte ao novo escopo PAT da seguinte maneira:

Restringir a abertura de recursos protegidos aos administradores de recursos

Para melhorar a segurança dos recursos que são essenciais para sua capacidade de criar e implantar seus aplicativos com segurança, o Azure Pipelines agora requer a função de administrador do tipo de recurso ao abrir o acesso a um recurso para todos os pipelines.

Por exemplo, uma função geral de Administrador de Conexões de Serviço é necessária para permitir que qualquer pipeline use uma conexão de serviço. Essa restrição se aplica ao criar um recurso protegido ou ao editar sua configuração de segurança.

Além disso, ao criar uma conexão de serviço, caso você não tenha direitos suficientes, a opção Conceder acesso a todos os pipelines é desabilitada.

Conexões de Serviço Além disso, ao tentar abrir o acesso a um recurso existente e não tiver direitos suficientes, você receberá a mensagem Você não está autorizado a abrir o acesso para este recurso.

Permissões de pipelines

Melhorias de segurança da API REST de pipelines

A maioria das APIs REST no Azure DevOps usa tokens PAT com escopo. No entanto, alguns deles exigem tokens PAT completamente definidos. Em outras palavras, você teria que criar um token PAT selecionando "Acesso completo" para usar algumas dessas APIs. Esses tokens representam um risco à segurança, pois podem ser usados para chamar qualquer API REST. Estamos fazendo melhorias no Azure DevOps para remover a necessidade de tokens com escopo completo incorporando cada API REST em um escopo específico. Como parte desse esforço, a API REST para atualizar permissões de pipeline para um recurso agora requer um escopo específico. O escopo depende do tipo de recurso que está sendo autorizado para uso:

  • Code (read, write, and manage) para recursos do tipo repository
  • Agent Pools (read, manage) ou Environment (read, manage) para recursos do tipo queue e agentpool
  • Secure Files (read, create, and manage) para recursos do tipo securefile
  • Variable Groups (read, create and manage) para recursos do tipo variablegroup
  • Service Endpoints (read, query and manage) para recursos do tipo endpoint
  • Environment (read, manage) para recursos do tipo environment

Para editar permissões de pipelines em massa, você ainda precisará de um token PAT com escopo completo. Para saber mais sobre como atualizar as permissões de pipeline para recursos, consulte a documentação permissões de pipeline – Atualizar permissões de pipeline para recursos .

Gerenciamento de acesso refinado para pools de agentes

Os pools de agentes permitem que você especifique e gerencie os computadores nos quais os pipelines são executados.

Anteriormente, se você usou um pool de agentes personalizado, o gerenciamento de quais pipelines podiam acessá-lo era amplo. Você pode permitir que todos os pipelines o usem ou você pode exigir que cada pipeline solicite permissão. Infelizmente, depois que você concedeu a permissão de acesso de um pipeline a um pool de agentes, não foi possível revogá-la usando a interface dos pipelines.

O Azure Pipelines agora fornece um gerenciamento de acesso refinado para pools de agentes. A experiência é semelhante à do gerenciamento de permissões de pipeline para Conexões de Serviço.

Pool de Agentes da FabrikamFiber para Modificações em Aprovações

Impedir que todos os pipelines tenham acesso a recursos protegidos

Ao criar um recurso protegido, como uma conexão de serviço ou um ambiente, você tem a opção de selecionar a caixa de seleção Conceder permissão de acesso a todos os pipelines. Até agora, essa opção era verificada por padrão.

Embora isso torne mais fácil para os pipelines usarem novos recursos protegidos, o inverso é que há um risco de muitos pipelines receberem acidentalmente o direito de acessar os recursos.

Para promover uma opção segura por padrão, o Azure DevOps agora deixa a caixa de seleção desmarcada.

A permissão de acesso a todos os pipelines está desativada por padrão

Capacidade de desabilitar o mascaramento para segredos curtos

O Azure Pipelines oculta segredos nos registros. Os segredos podem ser variáveis marcadas como segredo, variáveis de grupos de variáveis que estão vinculados ao Azure Key Vault ou elementos de uma Conexão de Serviço marcada como segredo pelo provedor de Conexão de Serviço.

Todas as ocorrências de valor secreto são mascaradas. Mascarar segredos curtos, por exemplo, '1', '2', 'Dev' facilita a adivinhação de seus valores, por exemplo, em uma data: 'Jan 3, 202***'
Agora está claro que "3" é um segredo. Nesses casos, talvez você prefira não mascarar completamente o segredo. Se não for possível não marcar o valor como segredo (por exemplo, o valor é obtido do Key Vault), você pode definir o AZP_IGNORE_SECRETS_SHORTER_THAN botão como um valor de até 4.

Tarefa de download do executor de nó

Ao adotar versões de agente que excluem o executor de tarefas do Node 6, você talvez precise ocasionalmente executar tarefas que não foram atualizadas para usar um executor de Node mais recente. Nesse cenário, fornecemos um método para ainda usar tarefas dependentes de runners de Node no fim da vida útil; consulte as diretrizes no blog sobre o executor do Node postagem no blog.

A tarefa abaixo é um método para instalar o executor do Node 6 just-in-time, de modo que uma tarefa antiga ainda pode ser executada:

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

Validação atualizada do executor de nó TFX

Os autores da tarefa usam a ferramenta de empacotamento de extensão (TFX) para publicar extensões. O TFX foi atualizado para executar validações em versões do executor do Node, consulte a postagem no blog de diretrizes do executor do Node.

As extensões que contêm tarefas usando o executor do Node 6 verão este aviso:

Task <TaskName> is dependent on a task runner that is end-of-life and will be removed in the future. Authors should review Node upgrade guidance: https://aka.ms/node-runner-guidance.

Instruções para pré-instalação manual do Node 6 em agentes de pipeline

Se você usar o feed dopipeline- agente, não terá o Nó 6 incluído no agente. Em alguns casos, quando uma tarefa do Marketplace ainda depende do Node 6 e o agente não pode usar a tarefa NodeTaskRunnerInstaller (por exemplo, devido a restrições de conectividade), você precisará pré-instalar o Node 6 independentemente. Para fazer isso, confira as instruções sobre como instalar o executor do Node 6 manualmente.

Registro de alterações de tarefas do pipeline

Agora publicamos alterações nas tarefas de pipeline neste log de alterações. Esta é a lista completa de alterações feitas nas tarefas embutidas do Pipeline. As alterações anteriores foram publicadas retroativamente, de forma que o log de alterações forneça um registro histórico das atualizações de tarefas.

Tarefas de versão usam a API do Microsoft Graph

Atualizamos nossas tarefas de lançamento para usar a API do Microsoft Graph. Isso remove o uso da API AAD Graph de nossas tarefas.

Melhoria no desempenho da tarefa do Windows PowerShell

Você pode usar tarefas para definir a automação em um pipeline. Uma dessas tarefas é a tarefa de utilitário PowerShell@2 que permite executar scripts em PowerShell no seu pipeline. Para usar o script do PowerShell para direcionar um ambiente do Azure, você pode usar a AzurePowerShell@5 tarefa. Alguns comandos do PowerShell que podem imprimir atualizações de progresso, por exemplo Invoke-WebRequest, agora são executados mais rapidamente. A melhoria será mais significativa se você tiver muitos desses comandos em seu script ou quando eles estiverem em execução por muito tempo. Com essa atualização, a propriedade progressPreference das tarefas PowerShell@2 e AzurePowerShell@5 agora está definida como SilentlyContinue por padrão.

Pipelines Agent v3 no .NET 6

O agente do Pipeline foi atualizado para usar o .NET 3.1 Core para o .NET 6 como runtime. Isso apresenta suporte nativo para o Apple Silicon, bem como para o Windows Arm64.

O uso do .NET 6 afeta os requisitos do sistema para o agente. Especificamente, descartamos o suporte para os seguintes Sistemas Operacionais: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Consulte a documentação do software agent versão 3.

Este script pode ser utilizado para identificar pipelines que empregam agentes com sistemas operacionais não suportados.

Importante

Lembre-se de que os agentes em execução em qualquer um dos sistemas operacionais acima não atualizarão mais ou falharão quando distribuirmos o agente baseado no .NET 6.

Especificar a versão do agente na extensão do Agente VM

As VMs do Azure podem ser incluídas em Grupos de Implantação usando uma Extensão de VM. A extensão da VM foi atualizada para especificar opcionalmente a versão do agente desejada a ser instalada:

    "properties": {
      ...
      "settings": {
        ...
        "AgentMajorVersion": "auto|2|3",
        ...
      },
      ...
     }

Novos interruptores para controlar a criação de pipelines clássicos

O Azure DevOps agora permite garantir que sua coleção de projetos use apenas pipelines YAML, desabilitando a criação de pipelines de build clássicos, pipelines de versão clássicos, grupos de tarefas e grupos de implantação. Seus pipelines clássicos existentes continuarão a ser executados e você poderá editá-los, mas não poderá criar novos.

O Azure DevOps agora permite garantir que sua organização use apenas pipelines YAML, desabilitando a criação de pipelines de build clássicos, pipelines de lançamento clássicos, grupos de tarefas e grupos de implantação. Seus pipelines clássicos existentes continuarão a ser executados e você poderá editá-los, mas não poderá criar novos.

Você pode desabilitar a criação de pipelines clássicos no nível da coleção de projetos ou no nível do projeto, ativando as alternâncias correspondentes. Os interruptores podem ser encontrados em Configurações do Projeto -> Pipelines -> Configurações. Há duas alternâncias: uma para pipeline clássico de build e outra para pipeline clássico de lançamento, grupos de implantação e grupos de tarefas.

Desabilitar a criação de pipelines clássicos

O estado do toggle está desligado por padrão, e você precisará de direitos de administrador para alterar o estado. Se o alternador estiver ativado no nível da organização, a desabilitação será aplicada a todos os projetos. Caso contrário, cada projeto será livre para escolher se deseja impor ou não a desabilitação.

Ao desabilitar a criação de pipelines clássicos, as APIs REST relacionadas à criação de pipelines clássicos, grupos de tarefas e grupos de implantação falharão. As APIs REST que criam pipelines YAML funcionarão.

Atualizações no evento de webhook "Alteração de estado na etapa de execução"

Os ganchos de serviço permitem executar tarefas em outros serviços quando eventos acontecem em seu projeto no Azure DevOps, o estado executar estágio alterado é um desses eventos. O evento de alteração de estado do estágio de execução deve conter informações sobre a execução, incluindo o nome do pipeline. Anteriormente, ele incluía apenas informações sobre a ID e o nome da execução. Com essa atualização, fizemos alterações no evento para incluir informações ausentes.

Gancho de serviço para alteração de estado do trabalho

Os ganchos de serviço permitem que você reaja em resposta a eventos relacionados a alterações de estado em suas execuções de pipeline. Até o momento, você podia configurar ganchos de serviço para alterações nos estados de execução e estágio de pipeline.

A partir de agora, você pode configurar ganchos de serviço que disparam quando o estado de uma tarefa na execução do seu pipeline é alterado. A estrutura de carga útil do novo evento é mostrada no exemplo a seguir.

{
    "subscriptionId": "8d91ad83-1db5-4d43-8c5a-9bb2239644b1",
    "notificationId": 29,
    "id": "fcad4962-f3a6-4fbf-9653-2058c304503f",
    "eventType": "ms.vss-pipelines.job-state-changed-event",
    "publisherId": "pipelines",
    "message":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "detailedMessage":
    {
        "text": "Run 20221121.5 stage Build job Compile succeeded.",
        "html": "Run 20221121.5 stage Build job <a href=\"https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088\">Compile</a> succeeded.",
        "markdown": "Run 20221121.5 stage Build job [Compile](https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088) succeeded."
    },
    "resource":
    {
        "job":
        {
            "_links":
            {
                "web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/results?buildId=2710088"
                },
                "pipeline.web":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_build/definition?definitionId=4647"
                }
            },
            "id": "e87e3d16-29b0-5003-7d86-82b704b96244",
            "name": "Compile",
            "state": "completed",
            "result": "succeeded",
            "startTime": "2022-11-21T16:10:28.49Z",
            "finishTime": "2022-11-21T16:10:53.66Z"
        },
        "stage": { ... },
        "run": { ... },
        "pipeline": { ... },
        "repositories": [ ... ]
    },
    "resourceVersion": "5.1-preview.1",
    "createdDate": "2022-11-21T16:11:02.9207334Z"
}

Os eventos de gancho de serviço de alteração de estado de trabalho, estágio e execução agora contêm uma repository propriedade que lista os Repositórios do Azure consumidos pela execução do pipeline. Por exemplo:

"repositories":
[
    {
        "type": "Git",
        "change":
        {
            "author":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "committer":
            {
                "name": "Fabrikam John",
                "email": "john@fabrikamfiber.com",
                "date": "2022-11-11T15:09:21Z"
            },
            "message": "Added Viva support"
        },
        "url": "https://fabrikamfiber@dev.azure.com/fabrikamfiber/fabrikamfiber-viva/_git/fabrikamfiber"
    }
]

Desativar a exibição da última mensagem de confirmação para a execução de um pipeline

Anteriormente, a interface do usuário do Pipelines era usada para mostrar a última mensagem de confirmação ao exibir a execução de um pipeline.

Exemplo da última mensagem de confirmação

Essa mensagem pode ser confusa, por exemplo, quando o código do pipeline YAML reside em um repositório diferente daquele que contém o código que está sendo criado. Recebemos feedback da Comunidade de Desenvolvedores nos pedindo uma maneira de habilitar/desabilitar a anexação da última mensagem de confirmação ao título de cada execução de pipeline.

Com essa atualização, adicionamos uma nova propriedade YAML, chamada appendCommitMessageToRunName, que permite que você faça exatamente isso. Por padrão, a propriedade é definida como true. Quando você defini-lo como false, a execução do pipeline exibirá apenas o BuildNumber.

Exemplo de execução de pipeline com número de build

Exemplo de execução de pipeline com a última mensagem de confirmação

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.

Ícone de visão geral do status de execução do pipeline

Com esta versão, estamos tornando mais fácil saber o status geral de uma execução de pipeline.

Para pipelines YAML que têm muitos estágios, costumava ser difícil saber o status de uma execução de pipeline, ou seja, ele ainda está em execução ou foi concluído. E se terminou, qual é o estado geral: bem-sucedido, fracassado ou cancelado. Corrigimos esse problema adicionando um ícone de visão geral do status de execução.

Ícone de visão geral do status de execução do pipeline

Painel lateral dos estágios do pipeline

Os pipelines YAML podem ter dezenas de estágios e nem todos eles caberão em sua tela. Embora o ícone de visão geral da execução do pipeline informe o estado geral da sua execução, ainda é difícil saber qual estágio falhou ou qual estágio ainda está em execução, por exemplo.

Nesta versão, adicionamos um painel lateral para estágios de pipeline, que permite visualizar rapidamente o estado de todos os seus estágios. Em seguida, você pode clicar em um estágio e acessar diretamente seus logs.

Atualizar fluxos de trabalho

Atualizações da interface do usuário de pipelines

Pesquisar estágios no painel lateral

Facilitamos a localização dos estágios que você está procurando no painel lateral dos estágios. Agora você pode filtrar rapidamente os estágios com base em seu status, por exemplo, executando estágios ou aqueles que exigem intervenção manual. Você também pode pesquisar fases pelo nome.

Atualizar pipelines do AZ

Ações rápidas de estágio

A tela Execuções de um pipeline fornece acesso rápido a todos os estágios de execução. Nesta versão, adicionamos um painel de estágios de onde você pode executar ações para cada estágio. Por exemplo, você pode executar novamente facilmente trabalhos com falha ou repetir todo o estágio. O painel está disponível quando nem todos os estágios se encaixam na interface do usuário, como você pode ver na captura de tela a seguir.

Captura de tela do pipeline com muitos estágios. Quando você clica no sinal '+' na coluna de estágios, o painel de estágios é exibido e, em seguida, você pode executar ações relacionadas aos estágios.

Captura de tela do painel de estágios.

Verifica melhorias na experiência do usuário

Estamos facilitando a leitura de logs de verificações. Os logs de verificação fornecem informações críticas para o sucesso da implantação. Eles podem te informar se você esqueceu de fechar um ticket de item de trabalho ou que você precisa atualizar um ticket no ServiceNow. Anteriormente, saber que uma verificação forneceu informações tão críticas era difícil.

A página de detalhes da execução do pipeline agora mostra o log da última verificação recente. Isso é apenas para verificações que seguem nosso uso recomendado.

Imagem mostrando o log de verificação mais recente. Para evitar aprovações equivocadas, o Azure DevOps mostra as Instruções para aprovadores no painel lateral de aprovações e verificações na página de detalhes de uma execução de pipeline.

Aguardando a imagem de revisão do pipeline.

Desabilitar uma verificação

Tornamos os testes de depuração menos tediosos. Às vezes, uma invocação de Função do Azure ou de API REST não funciona corretamente, e você precisa corrigi-la. Anteriormente, era necessário excluir essas verificações para impedir que elas bloqueassem erroneamente uma implantação. Depois de corrigir a verificação, você tinha que adicioná-la de volta e configurá-la corretamente, certificando-se de que todos os cabeçalhos necessários estão definidos ou de que os parâmetros de consulta estão corretos. Isso é entediante.

Agora, você pode simplesmente desabilitar uma verificação. A checagem desabilitada não será executada em avaliações subsequentes do conjunto de checagens.

Desabilite uma imagem de verificação. Depois de corrigir a verificação errônea, você pode simplesmente habilitá-la.

Habilite uma verificação através da imagem.

Recursos consumidos e parâmetros de modelo na API Rest de Execuções de Pipelines

A API REST de Execuções de Pipeline expandida agora retorna mais tipos de artefatos utilizados em uma execução de pipeline e os parâmetros usados para iniciar essa execução. Aprimoramos a API para retornar os recursos container e os parâmetros de modelo pipeline usados em uma execução de pipeline. Agora você pode, por exemplo, gravar verificações de conformidade que avaliam os repositórios, contêineres e outras execuções de pipeline usadas por um pipeline.

Aqui está um exemplo do novo corpo da resposta.

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

Suporte ao modelo de disponibilidade geral no editor yaml

Os templates são um recurso comumente usado em pipelines YAML. Eles são uma maneira fácil de compartilhar trechos de pipeline. Eles também são um mecanismo poderoso para verificar ou impor segurança e governança por meio de seu pipeline.

O Azure Pipelines dá suporte a um editor YAML, o que pode ser útil ao editar seu pipeline. No entanto, o editor não deu suporte a modelos até agora. Os autores de pipelines YAML não puderam obter suporte do intellisense ao usar um modelo. Os autores de modelo não puderam usar o editor yaml. Nesta versão, estamos adicionando suporte para modelos no editor yaml.

Ao editar seu arquivo YAML principal do Azure Pipelines, você pode incluir ou estender um modelo. Quando você digitar o nome do modelo, será solicitado que você valide seu modelo. Depois de validado, o editor yaml entende o esquema do modelo, incluindo os parâmetros de entrada.

Atualizações da API REST de pipelines

Após a validação, você pode escolher navegar pelo modelo. Você poderá fazer alterações no modelo usando todos os recursos do editor yaml.

Há limitações conhecidas:

  • Se o modelo tiver parâmetros necessários que não são fornecidos como entradas no arquivo YAML principal, a validação falhará e solicitará que você forneça essas entradas. Em uma experiência ideal, a validação não deve ser bloqueada e você deve ser capaz de preencher os parâmetros de entrada usando o intellisense.
  • Você não pode criar um novo modelo a partir do editor. Você só pode usar ou editar modelos existentes.

Nova variável de sistema predefinida

Introduzimos uma nova variável de sistema predefinida, chamada Build.DefinitionFolderPath, cujo valor é o caminho da pasta de uma definição de pipeline de build. A variável está disponível em pipelines de build clássicos e YAML.

Por exemplo, se o pipeline estiver hospedado dentro da pasta FabrikamFiber\Chat no Azure Pipelines, então o valor de Build.DefinitionFolderPath é FabrikamFiber\Chat.

Adicionar suporte para a função de divisão de cadeia de caracteres em expressões de modelo YAML

Os pipelines YAML fornecem maneiras convenientes de reduzir a duplicação de código, como percorrer each o valor de uma lista ou a propriedade de um objeto.

Às vezes, o conjunto de itens a serem iterados é representado como uma cadeia de caracteres. Por exemplo, quando a lista de ambientes a serem implantados é definida pela cadeia de caracteres integration1, integration2.

Enquanto ouvimos seus comentários da Comunidade de Desenvolvedores, ouvimos que você queria uma função de cadeia split de caracteres em expressões de modelo YAML.

Agora, você pode split uma cadeia de caracteres e iterar sobre each suas subcadeias de caracteres.

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Expressões de modelo na definição de recursos do repositório

Adicionamos suporte para expressões de template ao definir a propriedade ref de um recurso repository em um pipeline YAML. Esse foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Existem situações em que você deseja que o pipeline faça o checkout de diferentes branches do mesmo recurso de repositório.

Por exemplo, digamos que você tenha um fluxo de trabalho que crie seu próprio repositório e, para isso, ele precisa obter uma biblioteca de um repositório de recursos. Além disso, digamos que você queira que seu pipeline faça check-out do mesmo branch de biblioteca que ele está usando. Por exemplo, se o pipeline for executado no branch main, ele deverá extrair o branch main do repositório da biblioteca. Se os pipelines forem executados no dev branch, ele deverá fazer check-out do branch de dev biblioteca.

Até hoje, você precisava especificar explicitamente o branch para fazer check-out e alterar o código do pipeline sempre que o branch for alterado.

Agora, você pode usar expressões de template para escolher a ramificação de um recurso de repositório. Veja o seguinte exemplo de código YAML a ser usado para as ramificações não principais do seu pipeline:

resources:
  repositories:
    - repository: library
      type: git
      name: FabrikamLibrary
      ref: ${{ variables['Build.SourceBranch'] }}

steps:
- checkout: library
- script: echo ./build.sh
- script: echo ./test.sh

Ao executar o pipeline, você pode especificar a ramificação para fazer checkout para o repositório library.

Especificar a versão de um modelo a ser estendida no momento da fila de compilação.

Os modelos representam uma ótima maneira de reduzir a duplicação de código emelhorar a segurança dos pipelines.

Um caso de uso popular é armazenar modelos em seu próprio repositório. Isso reduz o acoplamento entre um modelo e os pipelines que o estendem e facilita a evolução do modelo e dos pipelines de forma independente.

Considere o exemplo a seguir, no qual um modelo é usado para monitorar a execução de uma lista de etapas. O código do modelo está localizado no Templates repositório.

# template.yml in repository Templates
parameters:
- name: steps
  type: stepList
  default: []

jobs:
- job:
  steps:
  - script: ./startMonitoring.sh
  - ${{ parameters.steps }}
  - script: ./stopMonitoring.sh

Digamos que você tenha um pipeline YAML que estenda esse modelo, localizado no repositório FabrikamFiber. Até hoje, não era possível especificar a ref propriedade do recurso de templates repositório dinamicamente ao usar o repositório como fonte de modelo. Isso significava que você tinha que alterar o código do pipeline se quisesse que seu pipeline: para estender um modelo de uma ramificação diferente; para estender um modelo da mesma ramificação que seu pipeline, independentemente da ramificação em que você executou seu pipeline.

Com a introdução de expressões de modelo na definição de recursos do repositório, você pode escrever o pipeline da seguinte maneira:

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ variables['Build.SourceBranch'] }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: echo ./build.sh
      - script: echo ./test.sh

Ao fazer isso, o pipeline estenderá o modelo na mesma ramificação na qual o pipeline é executado, para que você possa assegurar que as ramificações do pipeline e do modelo sempre correspondam. Ou seja, se você executar o pipeline em uma ramificação dev, ele estenderá o modelo especificado pelo template.yml arquivo no dev branch do templates repositório.

Ou você pode escolher, em tempo de fila de construção, qual ramo do repositório de modelo usar, escrevendo o código YAML a seguir.

parameters:
  - name: branch
    default: main

resources:
  repositories:
    - repository: templates
      type: git
      name: Templates
      ref: ${{ parameters.branch }}

extends:
  template: template.yml@templates
  parameters:
    steps:
      - script: ./build.sh
      - script: ./test.sh

Agora, você pode fazer com que o pipeline no branch main estenda um modelo de branch dev em uma execução e estenda um modelo de branch main em outra execução, sem alterar o código do pipeline.

Ao especificar uma expressão de modelo para a ref propriedade de um recurso de repositório, você pode usar parameters e variáveis predefinidas do sistema, mas não pode usar variáveis definidas pela interface do usuário do YAML ou pipelines.

Expressões de modelo na definição de recurso de contêiner

Adicionamos suporte para expressões de modelo ao definir as propriedades e endpoint as volumesportsoptionspropriedades de um container recurso em um pipeline YAML. Esse foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Agora, você pode escrever pipelines YAML como os seguintes.

parameters:
  - name: endpointName    
    default: AzDOACR
    type: string

resources:
  containers:
    - container: linux
      endpoint: ${{ parameters.endpointName }}
      image: fabrikamfiber.azurecr.io/ubuntu:latest

jobs:
- job:
  container: linux
  steps:
  - task: CmdLine@2
    inputs:
      script: 'echo Hello world'

Você pode usar parameters. e variables. em suas expressões de modelo. Para variáveis, você só pode usar as definidas no arquivo YAML, mas não aquelas definidas na interface do usuário do Pipelines. Se você redefinir a variável, por exemplo, usando comandos de log do agente, ela não terá nenhum efeito.

Melhorias de builds agendadas

Corrigimos um problema que fazia com que as informações de agendamento de um pipeline se corrompessem e impediam o carregamento do pipeline. Isso aconteceu, por exemplo, quando o nome do ramo excedeu uma certa quantidade de caracteres.

Mensagem de erro aprimorada ao não carregar pipelines

O Azure Pipelines fornece vários tipos de gatilhos para configurar como o pipeline é iniciado. Uma maneira de rodar um pipeline é usando triggers programados. Às vezes, as informações de Execução Agendada de um pipeline são corrompidas e podem fazer com que uma carga falhe. Anteriormente, estávamos exibindo uma mensagem de erro enganosa, alegando que o pipeline não foi encontrado. Com essa atualização, resolvemos esse problema e estamos retornando uma mensagem de erro informativa. Daqui para frente, você receberá a mensagem semelhante a: os dados de agendamento de build serão corrompidos se um pipeline não for carregado.

Não sincronizar marcas ao buscar um repositório Git

A tarefa de check-out usa a --tags opção ao buscar o conteúdo de um repositório Git. Isso faz com que o servidor busque todas as marcas, bem como todos os objetos apontados por essas marcas. Isso aumenta o tempo necessário para executar a tarefa em um pipeline, especialmente se você tiver um grande repositório com muitas tags. Além disso, a tarefa de check-out sincroniza marcas mesmo quando você habilita a opção de busca superficial, possivelmente derrotando sua finalidade. Para reduzir a quantidade de dados buscados ou extraídos de um repositório Git, agora adicionamos uma nova opção à tarefa para controlar o comportamento das marcas de sincronização. Essa opção está disponível em pipelines clássicos e YAML.

Esse comportamento pode ser controlado do arquivo YAML ou da interface do usuário.

Para optar por não sincronizar as marcas por meio do arquivo YAML, adicione a fetchTags: false ao processo de checkout. Quando a opção fetchTags não é especificada, ela é a mesma que se fetchTags: true for usada.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Se você quiser alterar o comportamento dos pipelines YAML existentes, talvez seja mais conveniente definir essa opção na interface do usuário em vez de atualizar o arquivo YAML. Para navegar até a interface do usuário, abra o editor YAML para o pipeline, selecione Gatilhos, depois Processo e, finalmente, a etapa de Checkout.

Se você especificar essa configuração no arquivo YAML e na interface do usuário, o valor especificado no arquivo YAML terá precedência.

Para todos os novos pipelines que você criar (YAML ou Clássico), as tags ainda são sincronizadas por padrão. Essa opção não altera o comportamento dos pipelines existentes. As marcas ainda serão sincronizadas nesses pipelines, a menos que você altere explicitamente a opção mencionada, conforme descrito acima.

Artefatos

Permissões de feed padrão atualizadas

As contas do Serviço de Build da Coleção de Projetos agora terão a função colaborador por padrão quando um novo feed do Azure Artifacts com escopo de coleção de projetos for criado, em vez da função colaborador atual.

Anteriormente, você podia ver pacotes upstream se tivesse uma cópia do feed. O ponto de dor era que você não podia procurar pacotes que estão disponíveis no upstream e que ainda não foram salvos no feed. Agora, você pode pesquisar por pacotes upstream disponíveis com a nova interface de usuário do feed.

Agora, o Azure Artifacts fornece uma interface do usuário que permite pesquisar pacotes em suas fontes upstream e salvar versões de pacotes no feed. Isso se alinha à meta da Microsoft de melhorar nossos produtos e serviços.

Reportagem

Mostrar o pai no widget de resultados da consulta

O Widget de Resultados da Consulta agora dá suporte ao nome do pai e a um link direto para esse pai.

Criar tokens de acesso pessoal para implantar no Marketplace

Copiar Painel

Com esta versão, estamos incluindo o Painel de Cópia.

Imagem com painel de controle

Data do Último Acesso dos Painéis e Modificados Por

Um dos desafios de permitir que as equipes criem vários dashboards é o gerenciamento e a limpeza dos desatualizados e não utilizados. Saber quando um dashboard foi visitado ou modificado pela última vez é uma parte importante para entender quais deles podem ser removidos. Nesta versão, incluímos duas novas colunas na página do diretório Dashboards. A Data do Último Acesso acompanhará quando o painel foi visitado mais recentemente. Modificado por rastreia quando o painel foi editado pela última vez e por quem.

As informações modificadas por também serão exibidas na própria página do painel.

Visualização do Painel

Esperamos que esses novos campos ajudem os administradores do projeto a entender o nível de atividade para os dashboards tomarem uma decisão educada se eles devem ser removidos ou não.

As visões de análise agora estão disponíveis

O recurso Exibições de Análise está em estado de prévia há um longo período em nossa versão hospedada do produto. Com esta versão, estamos felizes em anunciar que esse recurso agora está disponível para todas as coleções de projetos.

Na navegação, exibições de análise foram movidas da aba Visão Geral para a aba Quadros.

Exibição de análise na navegação de placas.

Uma exibição de Análise fornece uma maneira simplificada de especificar os critérios de filtro para um relatório do Power BI com base em dados do Analytics. Se você não estiver familiarizado com as Exibições de Análise, aqui está uma documentação para você se atualizar:

O widget de Solicitação de Pull para vários repositórios agora está disponível

Estamos entusiasmados em anunciar que o widget pull request para vários repositórios está disponível no Azure DevOps Server 2022.1. Com esse novo widget, você pode exibir sem esforço pull requests de até 10 repositórios diferentes em uma única lista simplificada, tornando mais fácil do que nunca acompanhar suas pull requests.

Widget de múltiplos repositórios para GA

Ticket de sugestão da comunidade

Introdução resolvida conforme concluída em gráficos de burndown e burnup

Entendemos a importância de refletir com precisão o progresso da equipe, incluindo itens resolvidos conforme concluído nos gráficos. Com uma opção de alternância simples, agora você pode optar por exibir itens resolvidos conforme concluído, fornecendo um verdadeiro reflexo do estado de burndown da equipe. Esse aprimoramento permite um acompanhamento e planejamento mais precisos, capacitando as equipes a tomar decisões informadas com base no progresso real. Experimente maior transparência e melhores insights com os gráficos de burndown e burnup atualizados no Reporting.

Gif para demonstração resolvida como concluída em gráficos de burn-down e burn-up.

Wiki

Suporte para tipos de diagrama adicionais em páginas wiki

Atualizamos a versão dos gráficos de sereia usados nas páginas wiki para 8.13.9. Com essa atualização, agora você pode incluir os seguintes diagramas e visualizações em suas páginas wiki do Azure DevOps:

  • Fluxograma
  • Diagramas de sequência
  • Gráficos de Gantt
  • Gráficos de setores
  • Diagramas de requisito
  • Diagramas de estado
  • Percurso do Usuário

Diagramas que estão no modo experimental, como Relação de Entidade e Git Graph, não estão incluídos. Para obter mais informações sobre os novos recursos, consulte as notas de versão do Mermaid.

Comentários

Adoraríamos ouvir sua opinião! 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