Partilhar via

Notas de versão do Azure DevOps Server 2022 Update 1

  • Artigo

| Comunidade | de desenvolvedores Requisitos do sistema e termos | de licença de compatibilidade | DevOps Blog | SHA-256 Hashes |

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 Servidor de DevOps do Azure, consulte Requisitos do Servidor de DevOps do Azure.

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

A atualização direta para o Azure DevOps Server 2022 Update 1 tem suporte no Azure DevOps Server 2019 ou no Team Foundation Server 2015 ou mais recente. Se sua 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.

Azure DevOps Server 2022 Update 1 Patch 4 Data de lançamento: 11 de junho de 2024

Arquivo Hash SHA-256
devops2022.1patch4.exe 3A17B4F973A6FA4DE5D0B30C6C87B3C18C885620C683FA1032EC4F6BDB2DA4FB

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

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

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

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

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

  • Resolvido um problema em que o servidor proxy parou de funcionar após a instalação do patch 2.
  • Corrigido um problema de renderização na página de detalhes da extensão que afetava idiomas que não eram o inglês.

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

Arquivo Hash SHA-256
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 de pesquisa.
  • Corrigido um bug em que o espaço em disco usado pela pasta de cache de proxy era calculado incorretamente e a pasta não era limpa corretamente.
  • CVE-2024-20667: Vulnerabilidade de execução remota de código do Servidor de DevOps do Azure.

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

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

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

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

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

Observação

Há dois problemas conhecidos com esta versão:

  1. A versão do Agente não é atualizada após a atualização para o Azure DevOps Server 2022.1 e o uso do Update Agent na configuração do Pool de Aagentes. 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 com Maven 3.9.x. O Maven 3.9.x introduziu alterações significativas com os Artefatos do Azure atualizando o transporte padrão do Maven Resolver 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 mudança força a Maven a usar o Wagon Resolver Transport. Confira a documentação aqui para mais detalhes.

O Azure DevOps Server 2022.1 é um acúmulo de correções de bugs. Ele inclui todos os recursos do 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 os Artefatos do Azure atualizando o transporte padrão do Maven Resolver 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 mudança força a Maven a usar o Wagon Resolver Transport. Confira a documentação aqui para mais detalhes.

Azure DevOps Server 2022 Update 1 RC2 Data de lançamento: 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 do 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 os Artefatos do Azure atualizando o transporte padrão do Maven Resolver 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 mudança força a Maven a usar o Wagon Resolver Transport. Confira a documentação aqui para mais detalhes.

O seguinte foi corrigido com esta versão:

  • Corrigido um problema em feeds locais em que as entradas upstream não estavam resolvendo as alterações de nome de exibição.
  • Ocorreu um erro inesperado ao alternar guias de Código para outra guia na página Pesquisar.
  • Erro ao criar um novo tipo de item de trabalho com ideógrafos unificados chineses, japoneses e coreanos (CJK). Um ponto de interrogação foi exibido no log RAW no check-in fechado quando o nome do projeto de equipe ou os arquivos incluíram CJK.
  • Corrigido um problema durante a instalação da Pesquisa em que a JVM (Java Virtual Machine) não conseguia alocar memória suficiente para o processo do Elastic Search. O widget de configuração de pesquisa agora usará o Java Development Kit (JDK) que é empacotado com o Elastic Search e, portanto, remove a dependência de qualquer Java Runtime Environment (JRE) pré-instalado no servidor de destino.

Azure DevOps Server 2022 Update 1 RC1 Data de lançamento: 19 de setembro de 2023

O Azure DevOps Server 2022.1 RC1 inclui muitos recursos novos. Alguns dos destaques incluem:

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

Geral

Todas as APIs REST públicas oferecem suporte a escopos 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 tokens de acesso pessoal (PAT). Usar um token de acesso pessoal de escopo completo aumenta o risco quando eles podem cair nas mãos de um usuário mal-intencionado. Esta é uma das principais razões pelas 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 oferecem suporte a um escopo PAT granular. Se você estiver usando um PAT de escopo completo para se 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. O(s) escopo(s) PAT granular(es) suportado(s) para uma determinada API REST pode ser encontrado na seção Segurança das páginas de documentação. Além disso, há uma tabela de escopos aqui.

As extensões devem exibir seus escopos

Ao instalar extensões em sua coleção de DevOps do Azure, você pode revisar as permissões de que a extensão precisa como parte da instalação. No entanto, uma vez instalados, as permissões de extensão não são visíveis nas configurações de extensão. Isso representou um desafio para os administradores que precisam realizar 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 revisar e tomar uma decisão informada sobre mantê-las ou não.

Criar tokens de acesso pessoais para implantar no Marketplace

Boards

Coluna Último Acesso na página Planos de Entrega

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

Gif para demonstrar o campo Último Acesso na página Planos de Entrega.

Visualize todas as dependências dos 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 seu plano de entrega. Clique nele novamente para desativar as linhas.

Gif para demonstração visualizar 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 itens de trabalho. Isso cria problemas de desempenho e usabilidade no formulário de 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 que usam a API REST, não o formulário de item de trabalho.

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

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

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

Corrigimos um bug na API Get Get de links de item de trabalho de relatório para retornar o valor remoteUrl correto para System.LinkTypes.Remote.Related tipos de link. Antes dessa correção, estávamos retornando o nome de coleção de projeto errado e uma ID de projeto ausente.

Criar ponto de extremidade REST de 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) pela cadeia de caracteres query. Isso funciona bem, a menos que você tenha uma instrução WIQL grande que atinja os limites do navegador no comprimento da cadeia de caracteres de consulta. Para resolver isso, criamos um novo ponto de extremidade REST para permitir que os autores da ferramenta gerem uma consulta temporária. Usar o id da resposta para passar via 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. Este pode ser um processo lento e está sujeito a limitação de taxa ao tentar fazer qualquer tipo de limpeza em massa. Em resposta, adicionamos um novo ponto de extremidade da API REST para excluir e/ou destruir itens de trabalho em lote.

@CurrentIteration macro em Planos de Entrega

Com esta atualização, adicionamos suporte para a @CurrentIteration macro para estilos em 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 demonstrar a macro CurrentIteration em Planos de Entrega.

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

Nem todos usam a data de destino e/ou a data de início ao rastrear recursos 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 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 demo copiar comentários link.

Melhorias na atualização em lote

Fizemos várias alterações na versão 7.1 da API de atualização em lote de 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 sucesso.

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

API de exclusão em lote

Esse novo ponto de extremidade 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 demonstração de edição de campos de lista de seleção compartilháveis.

Nova permissão para salvar comentários

A capacidade de salvar apenas comentários de item de trabalho tem sido uma das principais solicitações na comunidade de desenvolvedores. Estamos entusiasmados em informá-lo de que implementamos esse recurso. Para começar, vamos analisar 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 Configurações > do Projeto Caminho da Área de Configuração > do Projeto. Em seguida, selecione o caminho da área de escolha e clique em Segurança.

Caminho de Á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 definido. Ou seja, o item de trabalho se comportará exatamente como antes. Para permitir que um grupo ou usuários salvem comentários, selecione esse grupo/usuários e altere a permissão para Permitir.

Nova Permissão

Quando o usuário abre o formulário de item de trabalho no caminho dessa área, ele poderá adicionar comentários, mas não poderá atualizar nenhum dos outros campos.

Edição de demonstração de campos compartilháveis da lista de opções.

Esperamos que você ame esse recurso tanto quanto nós. Como sempre, se você tiver algum feedback ou sugestões, por favor, avise-nos.

Relatórios de quadros interativos

Os 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 Diagrama de Fluxo Cumulativo, Velocidade e Burndown de Sprint. Com esta versão, estamos disponibilizando-os.

Para exibir esses gráficos, clique no local da guia Análise nas páginas Quadro Kanban, Lista de Pendências e Sprints.

Relatórios Interativos

Repos

Removendo a permissão "Editar políticas" para o criador da ramificação

Anteriormente, quando você criava uma nova ramificação, recebíamos permissão para editar políticas nessa ramificação. Com esta atualização, estamos alterando o comportamento padrão para não conceder essa permissão, mesmo que a configuração "Gerenciamento de permissões" esteja 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ão de segurança ou por meio de associação de grupo.

Pipelines

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

O Azure Pipelines usa tokens de acesso a 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 para o token de acesso era definido como Project Collection. Com esta atualização, estamos definindo o escopo de autorização de trabalho para o projeto atual como padrão ao criar um novo pipeline clássico.

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

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

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

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

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

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

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

O Azure Pipelines integra-se aos GitHub Enterprise Servers locais para executar a integração contínua e compilações de relações públicas. Em alguns casos, o GitHub Enterprise Server está atrás de um firewall e requer 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 que roteamos o seguinte tráfego do Azure Pipelines para passar pela URL do proxy:

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

As conexões do serviço Registro de Contêiner agora podem usar as 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 autohospedado, eliminando a necessidade de gerenciar credenciais.

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

Observação

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

Tokens automáticos criados para a Conexão de Serviço do Kubernetes

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

As tarefas do Kubernetes agora suportam kubelogin

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

O Kubelogin não está pré-instalado em imagens hospedadas. Para garantir que as tarefas acima mencionadas usem kubelogin, instale-o 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 se lembre se um pipeline já havia usado um recurso protegido, como uma conexão de serviço.

No passado, se você tiver verificado "Conceder permissão de acesso a todos os pipelines" ao criar um recurso protegido, mas, em seguida, você restringiu o acesso ao recurso, seu pipeline precisava de uma nova autorização para usar o recurso. 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. Isso agora foi corrigido.

Novo Escopo do PAT para gerenciar autorização de pipeline e 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 pipeline usando um recurso protegido, como uma conexão de serviço, ou para gerenciar aprovações e verificações desse recurso.

API REST de pipelines Atualizações

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

Restringir a abertura de recursos protegidos a 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 e você não tiver direitos suficientes, a opção Conceder permissão de acesso a todos os pipelines será desabilitada.

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

Permissões de pipelines

Aprimoramentos 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 com escopo completo. Em outras palavras, você teria que criar um token PAT selecionando 'Acesso total' para usar algumas dessas APIs. Esses tokens representam um risco de segurança, pois podem ser usados para chamar qualquer API REST. Temos feito 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 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 especificar e gerenciar as máquinas nas quais os pipelines são executados.

Anteriormente, se você usava um pool de agentes personalizado, o gerenciamento de quais pipelines podem acessá-lo era de grão grosso. Você pode permitir que todos os pipelines o usem ou pode exigir que cada pipeline peça permissão. Infelizmente, depois de conceder uma permissão de acesso de pipeline a um pool de agentes, você não poderá revogá-la usando a interface do usuário de 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 FabrikamFiber para alterações em aprovações

Impedir a concessão de acesso a recursos protegidos a todos os pipelines

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

Embora isso facilite o uso de novos recursos protegidos pelos dutos, o inverso é que favorece a concessão acidental de muitos dutos do direito de acessar o recurso.

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

Conceder permissão de acesso a todos os pipelines é desativado por padrão

Capacidade de desabilitar a máscara para segredos curtos

O Azure Pipelines mascara segredos em logs. Os segredos podem ser variáveis marcadas como segredo, variáveis de grupos de variáveis 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' torna mais fácil adivinhar seus valores, por exemplo, em uma data: 'Jan 3, 202***'
Agora está claro que "3" é um segredo. Nesses casos, você pode preferir não mascarar o segredo completamente. Se não for possível não marcar o valor como segredo (por exemplo, o valor é obtido de 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 , talvez você tenha uma necessidade ocasional de executar tarefas que não foram atualizadas para usar um executor de Nó mais recente. Para esse cenário, fornecemos um método para ainda usar tarefas dependentes de executores de Fim da Vida Útil do Nó, consulte a postagem no blog de diretrizes do executor de nó.

A tarefa abaixo é um método para instalar o executor do Node 6 just-in-time, para que uma tarefa antiga ainda possa 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 de nó.

As extensões que contêm tarefas que usam 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 Nó 6 em agentes de pipeline

Se você usar o feed do agente, não terá o pipeline- 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.

Log de alterações de tarefas de pipeline

Agora publicamos alterações nas tarefas de pipeline neste log de alterações. Isso contém a lista completa de alterações feitas em tarefas internas 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.

As 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 do AAD Graph de nossas tarefas.

Melhoria do desempenho de tarefas do Windows PowerShell

Você pode usar tarefas para definir a automação em um pipeline. Uma dessas tarefas é a PowerShell@2 tarefa do utilitário que permite executar scripts do PowerShell em 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 é mais significativa se você tiver muitos desses comandos em seu script ou quando eles forem de longa execução. Com essa atualização, a progressPreferencePowerShell@2 propriedade das tarefas e AzurePowerShell@5 agora é definida como SilentlyContinue por padrão.

Agente de pipelines v3 no .NET 6

O agente de pipeline foi atualizado para usar o .NET 3.1 Core para o .NET 6 como seu tempo de execução. Isso introduz suporte nativo para Apple Silicon, bem como Windows Arm64.

O uso do .NET 6 afeta os requisitos do sistema para o agente. Especificamente, abandonamos 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.

Esse script pode ser usado para identificar pipelines que usam agentes com sistemas operacionais sem suporte.

Importante

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

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

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

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

Novas alternâncias para controlar a criação de pipelines clássicos

O Azure DevOps agora permite que você garanta que sua coleção de projetos use apenas pipelines YAML, desabilitando a criação de pipelines de compilação clássicos, pipelines de versão clássica, 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 que você garanta que sua organização use apenas pipelines YAML, desabilitando a criação de pipelines de compilação clássicos, pipelines de versão clássica, 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 de coleção de projeto ou no nível de projeto, ativando as alternâncias correspondentes. As alternâncias podem ser encontradas em Project / Project Settings -> Pipelines -> Settings. Há duas alternâncias: uma para pipelines de compilação clássicos e outra para pipelines de versão clássica, grupos de implantação e grupos de tarefas.

Desabilitar a criação de pipelines clássicos

O estado de alternância está desativado por padrão e você precisará de direitos de administrador para alterar o estado. Se a alternância estiver ativada no nível da organização, a desabilitação será imposta para todos os projetos. Caso contrário, cada projeto é livre para escolher se quer impor ou não a desativação.

Quando a desativação da criação de pipelines clássicos for imposta, as APIs REST relacionadas à criação de pipelines clássicos, grupos de tarefas e grupos de implantação falharão. APIs REST que criam pipelines YAML funcionarão.

Atualizações para o evento de gancho de serviço "Estado do estágio de execução alterado"

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

Desabilitar a exibição da última mensagem de confirmação para uma execução de pipeline

Anteriormente, a interface do usuário de 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 vive em um repositório diferente daquele que contém o código que está sendo criado. Ouvimos seus comentários da Comunidade de desenvolvedores nos pedindo uma maneira de ativar/desativar a anexação da mensagem de confirmação mais recente ao título de cada execução de pipeline.

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

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

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

Limites de Pipeline do Azure aumentados para alinhar com o tamanho máximo de modelo do Azure Resource Manager (ARM) de 4 MB.

Você pode usar a tarefa Implantação de Modelo do Gerenciador de Recursos do Azure 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 dos modelos ARM de 4 MB , resolvendo restrições de tamanho durante a integração de modelos grandes.

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

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 concluído. E se terminar, qual é o estado geral: bem-sucedido, com falha ou cancelado. Corrigimos esse problema adicionando um ícone de visão geral status execução.

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

Painel lateral dos estágios do pipeline

Os pipelines YAML podem ter dezenas de estágios, e nem todos caberão na 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 de estágios de pipeline que permite que você veja rapidamente o estado de todos os seus estágios. Você pode então clicar em um palco e ir diretamente para seus logs.

Pipelines de atualização

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 de estágios. Agora você pode filtrar rapidamente estágios com base em seu status, por exemplo, executando estágios ou aqueles que exigem intervenção manual. Você também pode pesquisar estágios pelo nome.

Atualizar pipelines do AZ

Executar ações rápidas

A tela Execuções de um pipeline oferece 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 facilmente trabalhos com falha ou executar novamente 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 estágios, o painel estágios aparece e, em seguida, você pode executar ações de palco.

Captura de tela do painel de estágios.

Verifica melhorias na experiência do usuário

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

Agora, a página de detalhes de execução do pipeline mostra o log de verificação mais recente. Isso é apenas para verificações que seguem nosso uso recomendado.

Imagem mostrando o log de verificação mais recente.Para evitar Aprovações aprovadas por engano, o Azure DevOps mostra as Instruções aos aprovadores no painel lateral 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 as verificações de depuração menos tediosas. Às vezes, uma verificação Invoke Azure Function ou Invoke REST API não funciona corretamente e você precisa corrigi-la. Anteriormente, era necessário excluir essas verificações para evitar que elas bloqueassem erroneamente uma implantação. Depois de corrigir a verificação, você tinha que adicioná-la novamente e configurá-la corretamente, certificando-se de que todos os cabeçalhos necessários estão definidos ou os parâmetros de consulta estão corretos. Isso é tedioso.

Agora, você pode simplesmente desativar uma verificação. A verificação desativada não será executada nas avaliações subsequentes do conjunto de verificação.

Desative uma imagem de verificação. Depois de corrigir a verificação errada, você pode simplesmente ativá-la.

Habilite uma imagem de verificação.

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

A API REST estendida Pipelines Runs agora retorna mais tipos de artefatos usados por uma execução de pipeline e os parâmetros usados para disparar essa execução. Aprimoramos a API para retornar os container recursos e pipeline os parâmetros de modelo usados em uma execução de pipeline. Agora você pode, por exemplo, escrever 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 de 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 modelos 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 aplicar a segurança e a governança por meio de seu pipeline.

O Azure Pipelines dá suporte a um editor YAML, que pode ser útil ao editar seu pipeline. No entanto, o editor não suportava modelos até agora. Os autores de pipelines YAML não puderam obter assistência por meio do intellisense ao usar um modelo. Os autores do modelo não puderam fazer uso do 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. Ao digitar o nome do modelo, você será solicitado a validá-lo. Uma vez validado, o editor YAML entende o esquema do modelo, incluindo os parâmetros de entrada.

API REST de pipelines Atualizações

Após a validação, você pode optar por navegar até o modelo. Você poderá fazer alterações no modelo usando todos os recursos do editor YAML.

Existem 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 intellisense.
  • Não é possível 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 compilação. A variável está disponível em pipelines de compilação YAML e clássico.

Por exemplo, se seu pipeline estiver alojado FabrikamFiber\Chat na pasta no Azure Pipelines, 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 o looping pelo each valor de uma lista ou 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 para implantar é definida pela cadeia de caracteres integration1, integration2.

Ao ouvirmos seus comentários da Comunidade de desenvolvedores, ouvimos que você queria uma função de cadeia de caracteres split nas expressões de modelo YAML.

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

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 recurso do repositório

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

Existem casos de uso em que você deseja que seu pipeline faça check-out de diferentes ramificações do mesmo recurso de repositório.

Por exemplo, digamos que você tenha um pipeline que cria seu próprio repositório e, para isso, ele precisa fazer check-out de uma biblioteca de um repositório de recursos. Além disso, digamos que você queira que seu pipeline verifique a mesma ramificação da biblioteca que ele mesmo está usando. Por exemplo, se o main pipeline for executado na ramificação, ele deverá fazer check-out main da ramificação do repositório da biblioteca. Se os pipelines forem executados na dev ramificação, ela deverá fazer check-out da ramificação da dev biblioteca.

Até hoje, você tinha que especificar explicitamente a ramificação para fazer check-out e alterar o código do pipeline sempre que a ramificação for alterada.

Agora, você pode usar expressões de modelo para escolher a ramificação de um recurso de repositório. Consulte o exemplo a seguir de código YAML a ser usado para as ramificações não principais do 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 check-out do library repositório.

Especificar a versão de um modelo a ser estendida no tempo de fila de compilação

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

Um caso de uso popular é abrigar 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 Templates modelo está localizado no 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 estende esse modelo, localizado no repositório FabrikamFiber. Até hoje, não era possível especificar a reftemplates propriedade do recurso do 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 o pipeline: estender um modelo de uma ramificação diferente estender um modelo do mesmo nome de ramificação que seu pipeline, independentemente de qual ramificação você executou seu pipeline

Com a introdução de expressões de modelo na definição de recursos do repositório, você pode escrever seu 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, seu pipeline estenderá o modelo na mesma ramificação que a ramificação na qual o pipeline é executado, para que você possa garantir que as ramificações do pipeline e do modelo sempre correspondam. Ou seja, se você executar seu pipeline em uma ramificação dev, ele estenderá o modelo especificado pelo template.yml arquivo na dev ramificação do templates repositório.

Ou você pode escolher, no momento da fila de compilação, qual ramificação do repositório de modelo usar, escrevendo o seguinte código YAML.

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 seu pipeline na ramificação main estenda um modelo da ramificação dev em uma execução e estenda um modelo da ramificação 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 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 endpointpropriedades , volumesports, e options de um container recurso em um pipeline YAML. Este foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Agora, você pode escrever pipelines YAML como o seguinte.

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 Pipelines. Se você redefinir a variável, por exemplo, usando comandos de log do agente, ela não terá nenhum efeito.

Melhorias nas compilações agendadas

Corrigimos um problema que fazia com que as informações de programação de um pipeline ficassem corrompidas e o pipeline não carregasse. Isso foi causado, por exemplo, quando o nome da ramificação excedeu um certo número de caracteres.

Mensagem de erro aprimorada ao não carregar pipelines

O Azure Pipelines fornece vários tipos de gatilhos para configurar a forma como o pipeline será iniciado. Uma maneira de executar um pipeline é usando gatilhos agendados. Às vezes, as informações de Execução Agendada de um pipeline ficam corrompidas e podem causar falha em uma carga. 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. No futuro, você receberá a mensagem semelhante a: Os dados da agenda de compilação serão corrompidos se um pipeline falhar ao carregar.

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

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

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

Para desativar a sincronização das tags por meio do arquivo YAML, adicione a fetchTags: false etapa de check-out. Quando a fetchTags opção não é especificada, é 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 Triggers, depois Process (Processo) e, em seguida, a etapa Check-out.

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 criados (YAML ou Classic), as tags ainda são sincronizadas por padrão. Essa opção não altera o comportamento dos pipelines existentes. As tags ainda serão sincronizadas nesses pipelines, a menos que você altere explicitamente a opção conforme descrito acima.

Artifacts

Permissões de feed padrão atualizadas

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

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

Os Artefatos do Azure agora fornecem uma interface de usuário que permite pesquisar pacotes em suas fontes upstream e salvar versões de pacotes em seu feed. Isso está alinhado com o objetivo da Microsoft de melhorar nossos produtos e serviços.

Reporting

Mostrar pai no widget Resultados da Consulta

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

Criar tokens de acesso pessoais para implantar no Marketplace

Copiar painel

Com esta versão, estamos incluindo o Copy Dashboard.

Imagem com cópia do Dashboard

Data do Último Acesso dos Painéis e Modificado por

Um dos desafios de permitir que as equipes criem vários painéis é 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 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 faixas 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.

Pré-visualização do Dashboard

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

As visualizações do Google Analytics já estão disponíveis

O recurso Visualizações do Google Analytics está em um estado de visualização por um longo período de tempo em nossa versão hospedada do produto. Com esta versão, temos o prazer de anunciar que este recurso agora está disponível para todas as coleções de projetos.

Na navegação, as exibições de Análise foram movidas da guia Visão geral para a guia 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 do Analytics, aqui está uma documentação para que você seja pego:

O widget Pull Request para vários repositórios já está disponível

Temos o prazer de 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 solicitações de pull de até 10 repositórios diferentes em uma única lista simplificada, tornando mais fácil do que nunca ficar por dentro de suas solicitações de pull.

Widget de vários repositórios para GA

Tíquete de sugestão da comunidade

Introdução ao resolvido como concluído em gráficos de burndown e burnup

Entendemos a importância de refletir com precisão o progresso da equipe, incluindo os itens resolvidos conforme preenchidos nos gráficos. Com uma opção de alternância simples, agora você pode optar por exibir os itens resolvidos como concluídos, 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 em Relatórios.

Gif para demonstração resolvido como concluído 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 pizza
  • Diagramas de requisitos
  • Diagramas de estado
  • Percurso do Usuário

Diagramas que estão em modo experimental, como Entity Relationship e Git Graph, não estão incluídos. Para obter mais informações sobre os novos recursos, consulte as notas de versão da sereia.

Comentários

Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la através da Comunidade de desenvolvedores e obter conselhos sobre estouro de pilha.

Início da página