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

| Comunidade de Desenvolvedores | Requisitos de Sistema e Compatibilidade | Termos de Licença | Blog de DevOps | 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 Azure DevOps Server, consulte Requisitos do Servidor de DevOps do Azure.

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

A atualização direta para o Azure DevOps Server 2022 Atualização 1 é suportada pelo Azure DevOps Server 2019 ou 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 Instalação para obter mais informações.

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

Lançamos o Patch 4 para o Azure DevOps Server 2022 Atualização 1 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 no seu nome para a localização turca.

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

Lançamos o Patch 3 para o Azure DevOps Server 2022 Update 1 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 em inglês.

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

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 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 foi calculado incorretamente e a pasta não foi limpa corretamente.
• CVE-2024-20667: Vulnerabilidade de execução remota de código do Azure DevOps Server.

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

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

• Impedir que se configure requested for ao enfileirar uma execução de pipeline.

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

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

Azure DevOps Server 2022 Atualização 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 no Azure DevOps Server 2022.1 RC1 lançado anteriormente.

O seguinte foi corrigido com esta versão:

• Corrigido um problema em feeds locais em que as entradas upstream não estavam resolvendo alterações de nome de exibição.
• Ocorreu um erro inesperado ao mudar do separador Código para outro separador na página de pesquisa.
• 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íam CJK.
• Corrigido um problema durante a instalação do Search em que a Java Virtual Machine (JVM) 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 é fornecido 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 Atualização 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:

• Todas as APIs REST públicas suportam escopos PAT granulares
• Coluna Último Acessado na página Planos de Entrega
• Visualizar todas as dependências nos Planos de Entrega
• @CurrentIteration macro em Planos de Entrega
• Projeto atual definido como escopo padrão para token de acesso de compilação em pipelines clássicos
• Mostrar pai no widget Resultados da Consulta
• Copiar painel
• Suporte para tipos de diagramas adicionais em páginas wiki
• ligações de serviço do Registo de Contentores agora podem usar identidades geridas do Azure

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

• Geral
• Painéis
• Repositórios
• Pipelines
• Artefatos
• Elaboração de Relatórios
• Wiki

Geral

Todas as APIs REST públicas suportam 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 dão suporte a um escopo granular da PAT. Se você estiver usando uma PAT de escopo completo para autenticar em uma das APIs REST públicas do Azure DevOps, considere migrar para uma PAT com o escopo específico aceito pela API para evitar acesso desnecessário. O(s) âmbito(s) granular(es) da PAT suportado(s) para uma determinada API REST pode ser encontrado na secção Segurança das páginas de documentação. Além disso, há uma tabela de escopos aqui.

As extensões devem exibir os 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.

Conselhos

Coluna de Último Acesso na página de 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.

Visualize todas as dependências nos Planos de Delivery

Os Planos de Entrega sempre forneceram a capacidade de ver as dependências entre os 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 comutação de dependências no canto superior direito do teu plano de entrega. Clique nele novamente para desligar 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 com o desempenho e a 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 equipa de Planos de Entrega de 15 para 20

Os Planos de Entrega permitem visualizar várias listas de pendências e várias equipes em toda a sua coleção de projetos. Anteriormente, você podia visualizar 15 listas de pendências de equipe, incluindo uma mistura de listas de pendências e equipes de projetos diferentes. Com esta libertação, aumentámos o limite máximo de 15 para 20.

Corrigido erro na API de Obtenção de Ligações de Itens de Trabalho de Relatório

Corrigimos um bug na API Get de Obtenção de Links de Itens de Trabalho do Relatório para devolver o valor correto de remoteUrl para System.LinkTypes.Remote.Related tipos de ligação. Antes dessa correção, estávamos retornando o nome de coleção de projeto errado e uma ID de projeto ausente.

Criar um ponto de extremidade REST para consultas temporárias

Vimos vários exemplos de autores de extensões tentando executar consultas não guardadas ao passar a instrução WIQL (Work Item Query Language) através do parâmetro da cadeia de consulta. Isso funciona bem, a menos que você tenha uma instrução WIQL grande que atinja os limites do navegador no comprimento querystring. Para resolver isso, criamos um novo ponto de extremidade REST para permitir que os autores de ferramentas 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 massa

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 restrições de velocidade ao tentar fazer qualquer tipo de limpeza maciça. Em resposta, adicionámos um novo endpoint da API REST para eliminar e/ou destruir itens de trabalho em massa.

@CurrentIteration macro em Planos de Entrega

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

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.

Melhorias nas atualizações 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 massa

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

Impedir a edição de campos de listas de opções compartilháveis

Os campos personalizados são compartilhados entre processos. Isso pode criar um problema para os campos da lista de opções, pois permitimos que os administradores do processo adicionem ou removam valores do campo. Ao fazer isso, as alterações afetam esse campo em todos os processos que o utilizam.

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

Nova permissão para salvar comentários

A capacidade de salvar apenas comentários de itens 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, é necessário ir para Configurações do Projeto > Configuração do Projeto > Caminho da Área. Em seguida, selecione o caminho da área de escolha e clique em Segurança.

Observe a nova permissão "Editar comentários do 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 abre 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 tiver algum feedback ou sugestão, por favor informe-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 diagramas de Fluxo Cumulativo, diagramas de Velocidade e diagramas de Burndown de Sprint. Com esta versão, disponibilizamo-los.

Para visualizar esses gráficos, clique na aba Análise nas páginas do Quadro Kanban, de Backlog e de Sprints.

Repositórios

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

Anteriormente, quando você criava uma nova ramificação, você recebia permissão para editar políticas nessa ramificação. Com essa 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.

Precisará da permissão “Editar políticas” concedida explicitamente (manualmente ou através da API REST) através da herança de permissões de segurança ou através de uma associação a um grupo.

Tubulações

O projeto atual é definido como escopo padrão para o token de acesso de compilação nas pipelines clássicas.

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 a trabalho é um token de segurança gerado dinamicamente pelos Pipelines do Azure 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 tarefas na documentação de repositórios, artefatos e outros recursos do Access.

Alteração no escopo padrão dos 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 de trabalho de compilação será Project, por padrão. Até agora, costumava ser Project Collection. Leia mais sobre Tokens de acesso a empregos. Esta alteração não afeta nenhum dos gasodutos existentes. Isso afeta apenas os novos pipelines de build clássico que você criar a partir de agora.

Suporte do Azure Pipelines para versões de San Diego, Tóquio ou 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 funcionar com as versões de San Diego, Tóquio ou 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 com os Servidores Empresariais do GitHub locais para executar a integração contínua e compilações de RP. Em alguns casos, o GitHub Enterprise Server está protegido por um firewall e requer que o tráfego seja roteado através 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 passar pela URL de proxy:

• Obter filiais
• Obter informações de solicitação pull
• Status da compilação do relatório

As conexões de serviço do Registro de Contêiner agora podem usar as Identidades Gerenciadas do Azure

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

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 Kubernetes. Nós adicionamos essa funcionalidade de volta. No entanto, é recomendável usar a conexão do Serviço do Azure ao acessar o AKS, para saber mais, consulte as diretrizes de Conexão de Serviço para clientes do AKS usando a postagem do blog de tarefas do Kubernetes.

As tarefas do Kubernetes agora suportam kubelogin

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

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

Experimente melhorias nas permissões de pipeline

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

No passado, se você marcasse "Conceder permissão de acesso a todos os pipelines" quando criava um recurso protegido, mas depois restringia 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, onde uma nova autorização não era necessária. Este problema foi corrigido.

Novo escopo da PAT para gerir autorização de pipeline e aprovações e controlos

Para limitar os danos causados pela fuga de um token PAT, adicionámos um novo âmbito PAT, denominado Pipeline Resources. Você pode usar esse escopo da 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 de API REST suportam o novo escopo da PAT da seguinte maneira:

• Atualizar um escopo de suporte de aprovação Pipeline Resources Use
• Gerenciar verificações suporta escopo Pipeline Resources Use and Manage
• Atualizar permissões de pipeline para recursos oferece suporte ao escopo Pipeline Resources Use and Manage
• Autorizar Recursos de Definição suporta o escopo Pipeline Resources Use and Manage
• Autorizar recursos do projeto suporta o escopo Pipeline Resources Use and Manage

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 exige a função de administrador do tipo recurso ao abrir o acesso a um recurso para todos os pipelines.

Por exemplo, uma função geral do Administrador de Ligações de Serviço é necessária para permitir que qualquer pipeline utilize uma ligação de serviço. Esta restrição aplica-se ao criar um recurso protegido ou ao editar a 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.

Melhorias de Segurança na API REST de Pipelines

A maioria das APIs REST no Azure DevOps utiliza tokens PAT com escopo. No entanto, alguns deles exigem tokens PAT com escopo completo. Por outras palavras, teria de criar um token PAT selecionando "Acesso total" para poder utilizar algumas destas APIs. Esses tokens representam um risco de segurança, uma vez que 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 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 as permissões de pipeline para recursos, consulte a documentação Permissões de Pipeline - Atualizar Permissões de Pipeline para Recursos.

Gerenciamento de acesso refinado para pools de agentes

Os pools de agentes permitem especificar e gerenciar as máquinas nas quais seus pipelines são executados.

Anteriormente, se tu usavas um pool de agentes personalizado, o gerenciamento de quais pipelines podiam aceder a ele era pouco detalhado. Você pode permitir que todos os pipelines o usem ou pode exigir que cada pipeline peça permissão. Infelizmente, ao conceder uma permissão de acesso de pipeline a um pool de agentes, não era possível revogá-la através da interface de utilizador dos pipelines.

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

Impedir que todos os pipelines tenham acesso a recursos protegidos.

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

Embora isso facilite o uso de novos recursos protegidos pelos pipelines, o inverso é que favorece a concessão acidental de direitos a demasiados pipelines para acederem ao recurso.

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

Capacidade de desativar o mascaramento para segredos de curta duração

O Azure Pipelines mascara segredos em logs. Os segredos podem ser variáveis marcadas como secretas, variáveis de grupos de variáveis vinculadas ao Cofre de Chaves do Azure ou elementos de uma Conexão de Serviço marcada como secreta 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 os seus valores, por exemplo, numa 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 secreto (por exemplo, o valor é retirado do Cofre da Chave), você pode definir o AZP_IGNORE_SECRETS_SHORTER_THAN botão para um valor de até 4.

Tarefa de download do executante de nó

Ao adotar versões de agente que excluem o executor de tarefas do Nó 6 , você pode ter uma necessidade ocasional de executar tarefas que não foram atualizadas para usar um executor de Nó mais recente. Para este cenário, fornecemos um método para ainda utilizar tarefas dependentes de runners de Node em fim de vida, consulte o artigo do blog sobre orientação para runners de Node.

A tarefa abaixo é um método para instalar o executor 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 executante de nós 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 Node runner, consulte a postagem do blog Node runner guidance.

As extensões que contêm tarefas usando o executor 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.js 6 em agentes de Pipeline

Se você usar o pipeline- feed do agente, não terá o Nó 6 incluído no agente. Nalguns casos, quando uma tarefa do Marketplace ainda está dependente do Nó 6 e o agente não consegue utilizar a tarefa NodeTaskRunnerInstaller (por exemplo, devido a restrições de conectividade), precisará de pré-instalar o Nó 6 independente. Para o conseguir, consulte as instruções sobre como instalar o Node 6 runner manualmente.

Registro de alterações das tarefas do pipeline

Agora, publicamos as alterações às tarefas de pipeline neste registo de alterações. Esta contém a lista completa das alterações feitas às tarefas de pipeline integradas. Publicámos retroativamente as alterações anteriores, pelo que o registo de alterações fornece um registo 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 da tarefa do Windows PowerShell

Você pode usar tarefas para definir 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 esta atualização, a propriedade progressPreference das tarefas PowerShell@2 e AzurePowerShell@5 agora é definida como SilentlyContinue por defeito.

Agente de Canalizações v3 no .NET 6

O agente de pipeline foi atualizado para usar o .NET Core 3.1 para o .NET 6 como ambiente 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.

Este script pode ser usado para identificar pipelines que usam agentes com sistemas operativos sem suporte.

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

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 desejada do agente a ser instalada:

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

Novas opções de alternância 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 compilação clássicos, pipelines de versão clássicos, grupos de tarefas e grupos de implantação. Os seus pipelines clássicos existentes continuarão a ser executados e poderás editá-los, mas não poderás criar novos.

O Azure DevOps agora permite garantir que sua organização use apenas pipelines YAML, desabilitando a criação de pipelines de compilação clássicos, pipelines de versão clássicos, grupos de tarefas e grupos de implantação. Os seus pipelines clássicos existentes continuarão a ser executados e poderás editá-los, mas não poderás 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. Os alternadores encontram-se em Project / Project Settings -> Pipelines -> Settings. Há duas alternâncias: uma para pipelines de compilação clássicos e outra para pipelines de lançamento clássicos, grupos de implantação e grupos de tarefas.

O estado de alternância está desativado por padrão, e você precisará de direitos de administrador para alterar o estado. Se o alternador estiver ligado ao nível organizacional, a desativação aplica-se a todos os projetos. Caso contrário, cada projeto é livre para escolher se aplica ou não a inabilitação.

Quando a desativação da criação de pipelines clássicos é imposta, 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 "Alteração do estado de execução do estágio" no gancho de serviço

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 alteração do estado da fase de execução deve conter detalhes 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 esta atualização, fizemos alterações no evento para incluir informações ausentes.

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

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

A partir de agora, você pode configurar ganchos de serviço que são acionados quando o estado de um trabalho na execução do pipeline muda. A estrutura de carga útil do novo evento é mostrada no exemplo a seguir.

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

Os eventos de integração contínua de execução, estado e alteração de estado de trabalho agora contêm uma propriedade repository que lista os repositórios do Azure consumidos pela execução da pipeline. Por exemplo:

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

Desativar a exibição da última mensagem de commit durante a execução de um pipeline

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

Essa mensagem pode ser confusa, por exemplo, quando o código do seu pipeline YAML vive em um repositório diferente daquele que contém o código que está criando. Ouvimos o seu feedback da Comunidade de Desenvolvedores solicitando-nos uma forma de ativar/desativar a inclusã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, a propriedade é definida como true. Quando definido para false, a execução do pipeline irá exibir apenas o BuildNumber.

Aumento dos limites de uso dos Pipelines do Azure para alinhar com o tamanho máximo de 4 MB dos modelos do Azure Resource Manager (ARM).

Você pode usar a tarefa Implantação de Modelo do Azure Resource Manager para criar a infraestrutura do Azure. Em resposta aos seus comentários, aumentamos o limite de integração do Azure Pipelines de 2 MB para 4 MB. Isso se alinhará com os modelos ARM tamanho máximo de 4 MB resolvendo restrições de tamanho durante a integração de modelos grandes.

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

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

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

Painel lateral de estágios de tubulação

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

Nesta versão, adicionámos um painel lateral com fases do pipeline que permite ver rapidamente o estado de todos os estágios. Você pode então clicar numa etapa e acessar diretamente os seus registos.

Pesquisar estágios no painel lateral

Tornámos mais fácil encontrar os estágios que procuras no painel lateral dos estágios. Agora você pode filtrar rapidamente os estágios com base em seu status, por exemplo, estágios em execução ou aqueles que exigem intervenção manual. Você também pode pesquisar estágios pelo nome.

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

Verifica as melhorias na experiência do usuário

Estamos a facilitar a leitura dos registos de verificações. Os logs de verificação fornecem informações críticas para o sucesso da implantação. Eles podem dizer-te se te esqueceste de fechar um ticket de item de trabalho ou se precisas de atualizar um ticket no ServiceNow. Anteriormente, saber que uma verificação fornecia informações tão críticas era difícil.

Agora, a página de detalhes da execução do pipeline mostra o log de verificação mais recente. Isto é apenas para verificações que seguem as nossas recomendações de uso.

Desativar uma verificação

Fizemos com que as verificações de depuração fossem menos entediantes. Às vezes, uma verificação Invoke Azure Function ou Invoke REST API não funciona corretamente e você precisa corrigi-la. Anteriormente, você tinha que excluir essas verificações, para evitar que elas bloqueassem erroneamente uma implantação. Depois de corrigir a verificação, você teve que adicioná-la de volta 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 desabilitada não será executada em avaliações subsequentes do conjunto de verificação.

Recursos consumidos e parâmetros de modelo na API Rest Pipelines Runs

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. Melhorámos a API para retornar os recursos container e os parâmetros de modelo pipeline usados numa execução do pipeline. Agora, por exemplo, você pode escrever verificações de conformidade que avaliam os repositórios, contêineres e outras execuções de processos usadas por um pipeline.

Aqui está um exemplo do novo conteúdo 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. São uma maneira fácil de partilhar segmentos de pipeline. Eles também são um mecanismo poderoso para verificar ou aplicar a segurança e a governança através do 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 através 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.

Após a validação, podes optar por navegar pelo modelo. Você será capaz de 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 tanto em pipelines YAML como em pipelines clássicos de compilação.

Por exemplo, se o pipeline estiver alojado na pasta FabrikamFiber\Chat 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 looping pelo each valor de uma lista ou propriedade de um objeto.

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

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

Agora, tu podes split uma string e iterar sobre each das 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 recursos do repositório

Adicionámos suporte para expressões de template ao definir a ref propriedade de um repository recurso num 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, imagina que tens um pipeline que constrói o seu próprio repositório e, para isso, precisa obter 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 está usando. Por exemplo, se a pipeline for executada na ramificação main, deverá fazer checkout da ramificação main do repositório da biblioteca. Se os pipelines forem executados na dev ramificação, ela deverá verificar a ramificação da dev biblioteca.

Até hoje, era necessário especificar explicitamente a branch para fazer a verificação e alterar a lógica do pipeline sempre que a branch mudasse.

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

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

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

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

Especifique a versão de um modelo a ser estendido no tempo de espera 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 template Templates 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 estenda esse modelo, localizado no repositório FabrikamFiber. Até hoje, não era possível especificar a ref propriedade do recurso do repositório dinamicamente ao usar o repositório como fonte do templates modelo. Isso significava que você tinha que alterar o código do pipeline se quisesse: estender um modelo de uma ramificação diferente, estender um modelo a partir do mesmo nome de ramificação que o seu pipeline, independentemente da ramificação em que executou o 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 seu pipeline estenderá o template na mesma ramificação em que o pipeline é executado, para que possa garantir que as ramificações do pipeline e do template coincidam sempre. Ou seja, se tu executares o teu pipeline num branch dev, ele estenderá o template especificado pelo arquivo template.yml no branch dev do repositório templates.

Ou você pode escolher, em tempo de fila de compilação, qual ramificação de 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 de ramificação dev em uma execução e estenda um modelo de 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, pode-se usar variáveis parameters e do sistema predefinidas, mas não se pode usar variáveis definidas pela interface do utilizador do YAML ou Pipelines.

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

Adicionámos suporte para expressões de modelo ao definir as propriedades endpoint, volumes, ports e options de um recurso container num pipeline YAML. Este foi um recurso altamente solicitado pela nossa Comunidade de Desenvolvedores.

Agora, podes escrever pipelines YAML como os que se seguem.

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 as 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 agendamento de um pipeline ficassem corrompidas e o pipeline não carregasse. Isso foi causado, por exemplo, quando o nome da ramificação excedia um certo número de caracteres.

Mensagem de erro melhorada quando ocorre falha ao carregar pipelines

O Azure Pipelines fornece vários tipos de gatilhos para configurar como o seu pipeline começa. 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 fazer com que uma carga falhe. Anteriormente, estávamos exibindo uma mensagem de erro enganosa, alegando que o pipeline não foi encontrado. Com essa atualização, resolvemos esse problema e estamos retornando uma mensagem de erro informativa. No futuro, você receberá uma mensagem como: Os dados do cronograma de compilação estão corrompidos se um pipeline falhar em carregar.

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

A tarefa de checkout usa a --tags opção na busca do conteúdo de um repositório Git. Isso faz com que o servidor busque 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 checkout sincroniza tags mesmo quando se ativa a opção de busca superficial, possivelmente comprometendo a 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 da sincronização de tags. Esta opção está disponível tanto em pipelines clássicos como em YAML.

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

Para todos os novos pipelines criados (YAML ou Classic), as tags ainda são sincronizadas por padrão. Esta 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.

Artefatos

Permissões de feed padrão atualizadas

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

Nova interface de utilizador para pesquisa de pacotes upstream

Anteriormente, era possível 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 pesquisar pacotes upstream disponíveis com a nova interface de 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. Isto está alinhado com o objetivo da Microsoft de melhorar os nossos produtos e serviços.

Elaboração de Relatórios

Mostrar pai no widget Resultados da Consulta

O Widget Resultados da Consulta agora suporta o nome do pai e um link direto para esse pai.

Copiar Dashboard

Com esta versão, estamos incluindo Copy Dashboard.

Data de último acesso e modificação dos painéis por

Um dos desafios de permitir que as equipas criem vários dashboards é a gestão e limpeza dos desatualizados e não utilizados. Saber quando um painel 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. Data do último acesso rastreará quando o painel foi visitado mais recentemente. Modificado por rastreia quando o painel foi editado pela última vez e por quem.

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

Esperamos que esses novos campos ajudem os administradores de projeto a entender o nível de atividade dos painéis para tomar uma decisão informada se 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 este lançamento, temos o prazer de anunciar que este recurso já está disponível para todas as coleções de projetos.

Na navegação, as visualizações do Google Analytics foram movidas da guia Visão geral para a guia Painéis .

Uma Vista do Analytics fornece uma forma simplificada de especificar os critérios de filtro para um relatório do Power BI baseado nos dados do Analytics. Se você não estiver familiarizado com as Visualizações do Google Analytics, aqui está uma documentação para você se atualizar:

• Sobre as visualizações do Google Analytics
• Criar uma vista do Analytics no Azure DevOps
• Gerir vistas do Analytics
• Criar um relatório do Power BI com uma vista predefinida do Analytics
• Ligar-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 este novo widget, você pode visualizar facilmente solicitações 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 pull.

Bilhete de sugestão da comunidade

Apresentando a categoria 'resolvido' como 'finalizado' em gráficos de burndown e burnup

Entendemos a importância de refletir com precisão o progresso da equipe, incluindo nos gráficos os itens resolvidos como concluídos. 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 nos Relatórios.

Plataforma Wiki

Suporte para tipos de diagramas 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 circulares
• Diagramas de requisitos
• Diagramas de estado
• Percurso do Utilizador

Os diagramas que estão no 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 mermaid release notes.

Comentários

Gostaríamos muito de ouvir a sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo através da Comunidade de Desenvolvedores e obter conselhos no Stack Overflow .