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

---

| | Developer Community Recursosdelicença | de compatibilidade | erequisitos de sistema DevOps blog | SHA-256 Hashes |

---

Neste artigo, você encontrará informações sobre a versão mais recente para Azure DevOps Server.

Para saber mais sobre como instalar ou atualizar uma implantação de Azure DevOps Server, confira Azure DevOps Server Requisitos.

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

A atualização direta para o Azure DevOps Server Atualização 1 de 2022 tem suporte do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2013 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para o Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.

---

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

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

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

• Resolvido 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 Patch 2 da Atualização 1 do Azure DevOps Server 2022: 13 de fevereiro de 2024

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

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

• Correção do problema de renderização da 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: Azure DevOps Server vulnerabilidade de execução remota de código.

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

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

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

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

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

Observação

Há dois problemas conhecidos com esta versão:

1. A versão do Agent não é atualizada após a atualização para o Azure DevOps Server 2022.1 e o uso do Agente de Atualização na configuração do Pool de Agentes. No momento, estamos trabalhando em um patch para resolve esse problema e compartilharemos atualizações no Developer Community à medida que avançamos. Enquanto isso, você pode encontrar uma solução alternativa para esse problema neste tíquete Developer Community.
2. Compatibilidade do Maven 3.9.x. O Maven 3.9.x introduziu alterações interruptivas com o Azure Artifacts atualizando o transporte padrão do Resolvedor do Maven 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 Resolvedor de Vagões. Confira a documentação aqui para obter mais detalhes.

Azure DevOps Server 2022.1 é um acúmulo 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 interruptivas com o Azure Artifacts atualizando o transporte padrão do Resolvedor do Maven 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 Resolvedor de Vagões. Confira a documentação aqui para obter mais detalhes.

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

Azure DevOps Server RC2 2022.1 é um acúmulo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server RC1 2022.1 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 interruptivas com o Azure Artifacts atualizando o transporte padrão do Resolvedor do Maven 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 Resolvedor de Vagões. Confira a documentação aqui para obter mais detalhes.

O seguinte foi corrigido com esta versão:

• Correção de um problema em feeds locais em que as entradas de 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 Pesquisar.
• Erro ao criar um novo tipo de item de trabalho com Ideografias Unificadas em chinês, japonês e coreano (CJK). Um ponto de interrogação foi exibido no log RAW no marcar fechado quando o nome ou os arquivos do projeto da equipe incluíam CJK.
• Corrigido 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 é agrupado com o Elastic Search e, portanto, remove a dependência de qualquer JRE (Java Runtime Environment) pré-instalado no servidor de destino.

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

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

• Todas as APIs REST públicas dão suporte a escopos de PAT granulares
• Coluna Last Accessed na página Planos de Entrega
• Visualizar todas as dependências nos Planos de Entrega
• macro @CurrentIteration nos Planos de Entrega
• Projeto atual definido como escopo padrão para o token de acesso de build em pipelines clássicos
• Mostrar Pai no Widget de Resultados da Consulta
• Copiar Painel
• Suporte para tipos de diagrama adicionais em páginas wiki
• As conexões de serviço do Registro de Contêiner agora podem usar identidades gerenciadas do Azure

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

• Geral
• Boards
• Repos
• Pipelines
• Artefatos
• Relatórios
• Wiki

---

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 chegar nas mãos de um usuário mal-intencionado. Essa é uma das main razões pelas quais muitos de nossos clientes não aproveitaram ao máximo as políticas do painel 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 de 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 granulares com suporte para uma 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 devem 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 representou 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 revisar e tomar uma decisão informada sobre mantê-las ou não.

Boards

Coluna Last Accessed na página Planos de Entrega

A página 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 do 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.

Visualizar todas as dependências nos 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 por 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.

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 do Azure DevOps. O limite afeta apenas as atualizações usando 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 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á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 combinação de listas de pendências e equipes de projetos diferentes. Com esta versão, aumentamos o limite máximo de 15 para 20.

Correção de bug na API obter links de item de trabalho de relatório

Corrigimos um bug na API obter 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 errado da coleção de projetos 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) 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. O uso da 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 limpo 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 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.

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 Recursos e Epics. 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.

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

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

Os 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 é 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.

Nova permissão salvar comentários

A capacidade de salvar apenas comentários de item de trabalho tem sido uma solicitação principal na comunidade de desenvolvedores. Estamos felizes 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 Configurações > do Projeto Caminho da Área de Configuração > do Projeto. Em seguida, selecione o caminho de área escolhido e clique em Segurança.

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ários salvem comentários, selecione esse grupo/usuários e altere a permissão para Permitir.

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

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 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.

Repos

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

Anteriormente, quando você criou um branch, você recebeu permissão para editar políticas nesse branch. 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.

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 o token de acesso de build 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 do trabalho como o projeto atual como o padrão ao criar um pipeline clássico.

Você pode encontrar mais detalhes sobre tokens de acesso ao trabalho na documentação Repositórios de acesso, 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á Project, por padrão. Até agora, costumava ser Coleção de Projetos. Leia mais sobre Tokens de acesso ao trabalho. Essa alteração não afeta nenhum dos pipelines existentes. Ele afeta apenas os novos pipelines de build clássicos que você cria a partir desse 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, Tóquio & 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 builds de PR. Em alguns casos, o GitHub Enterprise Server está atrá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 que encaminhamos o seguinte tráfego do Azure Pipelines para percorrer a URL do proxy:

• Obter branches
• 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 Registro de Contêiner do Azure. Isso permite que você acesse 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.

Observação

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

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

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

As tarefas do Kubernetes agora dão suporte ao kubelogin

Atualizamos as tarefas de KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 e AzureFunctionOnKubernetes@1 para dar suporte ao 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 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 para 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" quando criou um recurso protegido, mas depois restringiu o acesso ao recurso, seu pipeline precisava de uma nova autorização para usar o recurso. Esse comportamento era inconsistente com o acesso subsequente de abertura e fechamento ao recurso, em que uma nova autorização não era necessária. Isso agora foi corrigido.

Novo escopo 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 para esse recurso.

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

• Atualizar um escopo de suporte de aprovaçãoPipeline Resources Use
• Gerenciar Verificações dá suporte ao escopo Pipeline Resources Use and Manage
• Atualizar permissões de pipeline para recursos dá suporte ao escopo Pipeline Resources Use and Manage
• Autorizar recursos de definição dá suporte ao escopo Pipeline Resources Use and Manage
• Autorizar Recursos do Projeto dá suporte ao escopo Pipeline Resources Use and Manage

Restringir a abertura de recursos protegidos para 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 Connections de Serviços é 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 tem direitos suficientes, a opção Conceder permissão de acesso a todos os pipelines é desabilitada .

Além disso, ao tentar abrir o acesso a um recurso existente e não tiver direitos suficientes, você obterá um Não está autorizado a abrir o acesso a essa mensagem de recurso.

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 com escopo completo. Em outras palavras, você teria que criar um token PAT selecionando "Acesso completo" para usar algumas dessas APIs. Esses tokens representam um risco de 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 as 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 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 podem acessá-lo era refinado. Você pode permitir que todos os pipelines o usem ou você pode exigir que cada pipeline solicite permissão. Infelizmente, depois que você concedeu uma permissão de acesso de pipeline a um pool de agentes, não foi possível revogá-lo 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 o Service Connections.

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

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 era verificada por padrão.

Embora isso torne mais fácil para os pipelines usarem novos recursos protegidos, o inverso é que ele favorece a concessão acidental de muitos pipelines o direito de acessar o recurso.

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

Capacidade de desabilitar o mascaramento para segredos curtos

O Azure Pipelines mascara segredos nos logs. 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 marcados 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, 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ê poderá 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 Nó 6 , talvez seja necessário 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, portanto, uma tarefa antiga ainda pode ser executada:

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

Validação atualizada do executor de nó TFX

Os autores de tarefas 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 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.

Log de alterações de tarefa 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 o Microsoft API do Graph

Atualizamos nossas tarefas de versão para usar o microsoft API do Graph. Isso remove o uso do API do Graph do AAD de nossas tarefas.

melhoria no desempenho da tarefa 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 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 progressPreference propriedade das PowerShell@2 tarefas e AzurePowerShell@5 agora é definida SilentlyContinue como 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 runtime. Isso apresenta suporte nativo para Apple Silicon, bem como Windows Arm64.

O uso do .NET 6 afeta os requisitos do sistema para o agente. Especificamente, removemos 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 depois que distribuirmos o agente baseado no .NET 6.

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

As VMs do Azure podem ser incluídas em Grupos de Implantação usando uma Extensão de VM. A extensão de VM foi atualizada para especificar opcionalmente a versão desejada do agente 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 garantir que sua coleção de projetos 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.

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 do projeto ou no nível do projeto, ativando as alternâncias correspondentes. As alternâncias podem ser encontradas em Configurações do Projeto/Projeto –> Pipelines –> Configurações. Há duas alternâncias: uma para pipelines de build clássicos e outra para pipelines de lançamento clássicos, grupos de implantação e grupos de tarefas.

O estado de alternâncias 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 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 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 de estado do estágio de execução alterado 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.

Desabilitar a exibição do último mensagem do commit para uma execução de pipeline

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

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á criando. Ouvimos seus comentários da Developer Community nos pedindo uma maneira de habilitar/desabilitar o acréscimo dos mensagem do commit mais recentes ao título de cada execução de pipeline.

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

Aumento dos limites do Azure Pipeline para se alinhar ao tamanho máximo do modelo do ARM (Azure Resource Manager) de 4 MB.

Você pode usar a tarefa implantação de modelo de Resource Manager 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 do ARM de 4 MB resolvendo restrições de tamanho durante a integração de modelos grandes.

Ícone de visão geral da execução de 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 tiver terminado, qual é o estado geral: bem-sucedido, com falha ou cancelado. Corrigimos esse problema adicionando uma execução status ícone de visão geral.

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 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. Em seguida, você pode clicar em um estágio e acessar diretamente seus logs.

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 seus status, por exemplo, executando estágios ou aqueles que exigem intervenção manual. Você também pode pesquisar estágios pelo nome.

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 do qual você pode executar ações para cada estágio. Por exemplo, você pode executar novamente trabalhos com falha facilmente 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.

Quando você clica no sinal '+' na coluna de estágios, o painel de estágios é exibido e, em seguida, você pode executar ações de estágio.

Verifica os aprimoramentos da experiência do usuário

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

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

Para evitar aprovações aprovadas erroneamente, o Azure DevOps mostra as Instruções para aprovadores no painel lateral Aprovações e verificações na página de detalhes de uma execução de pipeline.

Desabilitar um marcar

Tornamos as verificações de depuração menos tediosas. Às vezes, um marcar invocar a API REST ou Invocar função do Azure não funciona corretamente e você precisa corrigi-lo. Anteriormente, era necessário excluir essas verificações para impedir que elas bloqueassem erroneamente uma implantação. Depois de corrigir o marcar, você precisou adicioná-lo novamente e configurá-lo corretamente, verificando se todos os cabeçalhos necessários estão definidos ou se os parâmetros de consulta estão corretos. Isso é entediante.

Agora, você pode simplesmente desabilitar um marcar. A marcar desabilitada não será executada nas avaliações subsequentes do pacote de marcar.

Depois de corrigir a marcar errônea, basta habilitá-la.

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

A API REST de Execuções de Pipelines estendida 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 e os parâmetros de modelo 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 modelos são um recurso comumente usado em pipelines YAML. Eles são uma maneira fácil de compartilhar snippets 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 assistência por meio 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. Ao digitar o nome do modelo, você será solicitado a validar seu modelo. Depois de validado, o editor yaml entende o esquema do modelo, incluindo os parâmetros de entrada.

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.

Há limitações conhecidas:

• Se o modelo tiver parâmetros necessários que não são fornecidos como entradas no arquivo YAML main, 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.
• Não é possível criar um novo modelo 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 na FabrikamFiber\Chat pasta no Azure Pipelines, o valor de Build.DefinitionFolderPath será FabrikamFiber\Chat.

Adicionar suporte para 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 fazer loop por meio each do valor de uma lista ou propriedade de um objeto.

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

Conforme ouvimos seus comentários do Developer Community, 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 recurso do repositório

Adicionamos suporte para expressões de modelo ao definir a ref propriedade de um repository recurso em um pipeline YAML. Esse foi um recurso altamente solicitado por nossa Developer Community.

Existem casos de uso quando você deseja que o pipeline marcar diferentes branches do mesmo recurso de repositório.

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

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

Agora, você pode usar expressões de modelo para escolher o branch de um recurso de repositório. Confira o seguinte exemplo de código YAML a ser usado para os branches não main 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 o branch para marcar para o library repositório.

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

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 é hospedar 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ê precisava alterar o código do pipeline se quisesse que seu pipeline: estender um modelo de um branch diferente estender um modelo do mesmo nome de branch que o pipeline, independentemente de qual branch 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, o pipeline estenderá o modelo no mesmo branch que o branch no qual o pipeline é executado, para que você possa garantir que os branches do pipeline e do modelo sempre correspondam. Ou seja, se você executar o pipeline em um branch 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 build, qual branch de 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 seu pipeline no branch main estenda um modelo de branch dev em uma execução e estenda um modelo do 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 variáveis predefinidas do sistema e , 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 endpointpropriedades , volumes, portse options de um container recurso em um pipeline YAML. Esse foi um recurso altamente solicitado por nossa Developer Community.

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 aquelas definidas no arquivo YAML, mas não aquelas definidas na interface do usuário de Pipelines. Se você redefinir a variável, por exemplo, usando comandos de log do agente, ela não terá nenhum efeito.

Aprimoramentos de builds agendados

Corrigimos um problema que fazia com que as informações de agendamento de um pipeline ficassem corrompidas e o pipeline não fosse carregado. Isso foi causado, por exemplo, quando o nome do branch excedeu um determinado número de caracteres.

Mensagem de erro aprimorada ao falhar ao 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 são corrompidas e podem causar uma falha na 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. 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 sincronize marcas ao buscar um repositório Git

A tarefa de check-out usa --tags a opção para 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 marcas. 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.

YAML

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

Para recusar a sincronização das marcas por meio do arquivo YAML, adicione a fetchTags: false à etapa de check-out. 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 de 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 do pipeline, selecione Gatilhos e, em seguida, Processar e, em seguida, a etapa 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.

Clássico

Para recusar a sincronização das marcas, desmarque a caixa de seleção Sincronizar marcas na etapa obter fontes.

Para todos os novos pipelines criados (YAML ou Clássico), as marcas ainda são sincronizadas por padrão. Essa opção não altera o comportamento de pipelines existentes. As marcas 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 Build de 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.

Nova interface do usuário para upstream pesquisa de pacotes

Anteriormente, você podia ver upstream pacotes 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 pacotes de upstream disponíveis com a nova interface do usuário do feed.

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

Relatórios

Mostrar Pai no Widget de Resultados da Consulta

O Widget resultados da consulta agora dá suporte ao nome do pai e a um link direto para esse pai.

Copiar Painel

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

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 uma dashboard foi visitada ou modificada pela última vez é uma parte importante para entender quais podem ser removidas. Nesta versão, incluímos duas novas colunas na página do diretório Dashboards. A Data do Último Acesso acompanhará quando a dashboard foi visitada mais recentemente. Modificado por faixas quando o dashboard foi editado pela última vez e por quem.

As informações modificadas por também serão exibidas na própria página 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 exibições de análise já estão disponíveis

O recurso Exibições de Análise 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, estamos felizes em anunciar que esse 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 .

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:

• Sobre exibições do Analytics
• Criar uma exibição de Análise no Azure DevOps
• Gerenciar exibições do Analytics
• Criar um relatório do Power BI com uma exibição padrão do Analytics
• Conectar-se ao Analytics com o Conector de Dados do Power BI

O widget pull request para vários repositórios já 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 solicitações de pull de até 10 repositórios diferentes em uma única lista simplificada, tornando mais fácil do que nunca ficar em cima de suas solicitações de pull.

Tíquete de sugestão da comunidade

Introdução resolvida conforme concluído 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 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 no Reporting.

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 a 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 requisito
• Diagramas de estado
• Jornada 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 sobre a versão da sereia.

---

Comentários

Adoraríamos ouvir sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo por meio de Developer Community e obter conselhos sobre o Stack Overflow.

---

Parte superior da página