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

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

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

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

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

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

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

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

• Corrigido um problema no wiki e nos itens de trabalho em que os resultados da pesquisa não estavam disponíveis para projetos que tinham "I" turco em seu nome para a localidade 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 Azure DevOps Server 2022 Atualização 1 que inclui correções para o seguinte.

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

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

Lançamos o Patch 2 para Azure DevOps Server 2022 Atualização 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 do proxy era calculado incorretamente e a pasta não era limpa corretamente.
• CVE-2024-20667: vulnerabilidade de execução remota de código do Azure DevOps Server.

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

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

• Impedir a configuração 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

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

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

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 alternar guias do Código para outra guia na página Pesquisar.
• Erro ao criar um novo tipo de item de trabalho com Ideogramas Unificados Chinês, Japonês e Coreano (CJK). Um ponto de interrogação era 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 da pesquisa em que a Java Virtual Machine (JVM) não conseguia alocar memória suficiente para o processo de pesquisa elástica. 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

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

• Todas as APIs REST públicas dão suporte a escopos PAT granulares
• Coluna Último acesso na página Planos de entrega
• Visualize todas as dependências dos Planos de Entrega
• @CurrentIteration macro em Planos de Entrega
• Projeto atual definido como escopo padrão para token de acesso de build em pipelines clássicos
• Mostrar pai no widget de resultados da consulta
• Copiar painel
• Suporte para tipos de diagramas 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 pular para seções individuais para ver todos os novos recursos de cada serviço:

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

Geral

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

Anteriormente, várias APIs REST do Azure DevOps documentadas publicamente não eram 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 eles podem cair nas mãos de um usuário mal-intencionado. Esse é um dos principais motivos pelos quais muitos de nossos clientes não aproveitaram ao máximo as políticas do plano de controle para restringir o uso e o comportamento do PAT.

Agora, todas as APIs REST públicas do Azure DevOps agora estão associadas e dão suporte a um escopo PAT granular. Se você estiver usando um PAT com escopo completo para se autenticar em uma das APIs REST públicas do Azure DevOps, considere migrar para um PAT com o escopo específico aceito pela API para evitar acesso desnecessário. Os escopos PAT granulares suportados 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 que a extensão precisa como parte da instalação. No entanto, uma vez instaladas, as permissões de extensão não ficam visíveis nas configurações da 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.

Boards

Coluna Último acesso na página Planos de entrega

A página do diretório Planos de Entrega fornece uma lista dos planos definidos para o seu projeto. Você pode classificar por: Nome, Criado por, Descrição, Última configuração ou Favoritos. Com essa 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 dos Planos de Entrega

Os Planos de Entrega sempre forneceram a capacidade de ver as dependências entre itens de trabalho. Você pode visualizar as linhas de dependência, uma a uma. Com esta versão, melhoramos a experiência, permitindo que você veja todas as linhas de dependências em todos os itens de trabalho na tela. Basta clicar no botão de alternância de dependências no canto superior direito do seu plano de entrega. Clique 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 com 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 Azure DevOps Service. 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 ele em suas ferramentas automatizadas.

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

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

Corrigido bug na API de Obtenção de 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 da cadeia de caracteres de consulta. Para resolver isso, criamos um novo endpoint REST para permitir que os autores da ferramenta gerem uma consulta temporária. Usar o id da resposta para passar via querystring elimina esse problema.

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

API de exclusão em lote

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

@CurrentIteration macro em Planos de entrega

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

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

Nem todo mundo usa 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.

Aprimoramentos de atualização em lote

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

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

API de exclusão em lote

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

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

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

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

Nova permissão para salvar comentários

A capacidade de salvar apenas comentários de item de trabalho tem sido uma das principais solicitações na comunidade de desenvolvedores. Temos o prazer de informar que implementamos esse recurso. Para começar, vamos revisar o cenário mais comum:

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

Para fazer isso, você precisa ir para Configurações > do projeto Caminho da área de configuração > do projeto. Em seguida, selecione o caminho da área de sua escolha 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 algum comentário ou sugestão, 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 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 da ramificação

Anteriormente, quando você criava um novo branch, recebia 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 token de acesso de build em pipelines clássicos

O Azure Pipelines usa tokens de acesso de 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 novos pipelines clássicos, o valor padrão para o token de acesso era definido como Coleção de Projetos. Com essa atualização, estamos definindo o escopo de autorização de trabalho para o projeto atual como o padrão ao criar um novo pipeline clássico.

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

Alteração no escopo padrão de tokens de acesso em pipelines de 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 Project Collection. 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 deste ponto.

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

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

Para obter mais informações, consulte a documentação Integrar com o Gerenciamento de Alterações do ServiceNow.

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

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

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

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

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

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

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

As tarefas do Kubernetes agora oferecem suporte ao kubelogin

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

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

 - task: KubeloginInstaller@0

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

Aprimoramentos de experiência em permissões de pipeline

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

No passado, se você tiver verificado "Conceder permissão de acesso a todos os pipelines" ao criar um recurso protegido, mas, em seguida, você restringiu o acesso ao recurso, seu pipeline precisava de uma nova autorização para usar o recurso. Esse comportamento era inconsistente com a abertura e o fechamento subsequentes do acesso ao recurso, em que uma nova autorização não era necessária. Isso agora foi corrigido.

Novo Escopo do PAT para gerenciar autorização de pipeline e aprovações e verificações

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

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

• Atualizar um escopo de suporte à 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 a administradores de recursos

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

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

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

Melhorias de segurança da API REST do Pipelines

A maioria das APIs REST no Azure DevOps usa tokens PAT com escopo. No entanto, alguns deles exigem tokens PAT com escopo total. Em outras palavras, você teria que criar um token PAT selecionando 'Acesso total' para usar algumas dessas APIs. Esses tokens representam um risco de segurança, pois podem ser usados para chamar qualquer API REST. Temos feito melhorias no Azure DevOps para remover a necessidade de tokens com escopo completo, incorporando cada API REST em um escopo específico. Como parte desse esforço, a API REST para atualizar as permissões de pipeline de 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 seus pipelines são executados.

Anteriormente, se você usasse um pool de agentes personalizado, o gerenciamento de quais pipelines podem acessá-lo era de baixa granularidade. Você pode permitir que todos os pipelines o usem ou exigir que cada pipeline peça permissão. Infelizmente, depois de conceder uma permissão de acesso de pipeline a um pool de agentes, você não poderá revogá-la usando a interface do usuário de pipelines.

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

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, esta opção estava marcada por padrão.

Embora isso facilite o uso de novos recursos protegidos pelos pipelines, 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 desmarcada.

Capacidade de desabilitar a máscara para segredos curtos

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

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

Tarefa de download do executor de nó

Ao adotar versões de agente que excluem o executor de tarefas do Node 6 , talvez você tenha uma necessidade ocasional de executar tarefas que não foram atualizadas para usar um executor de Nó mais recente. Para esse cenário, fornecemos um método para ainda usar tarefas dependentes de executores de Fim da Vida Útil do Nó, consulte a postagem no blog de diretrizes do executor de nó.

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

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

Validação atualizada do executor de nó TFX

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

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

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

Instruções para pré-instalação manual do Nó 6 em agentes de tubulação

Se você usar o feed do pipeline- 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 tarefas de pipeline

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

As tarefas de versão usam a API do Microsoft Graph

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

Melhoria no desempenho de tarefas do Windows PowerShell

Você pode usar tarefas para definir a automação em um pipeline. Uma dessas tarefas é a PowerShell@2 tarefa de 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 estiverem em execução longa. Com essa atualização, a progressPreference PowerShell@2 propriedade das tarefas e AzurePowerShell@5 agora é definida como SilentlyContinue por padrão.

Agente de Pipelines v3 no .NET 6

O agente de Pipeline foi atualizado para usar o .NET 3.1 Core para o .NET 6 como seu runtime. 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, descartamos o suporte para os seguintes sistemas operacionais: CentOS 6, Fedora 29-33, Linux Mint 17-18, Red Hat Enterprise Linux 6. Consulte a documentação do software do Agente versão 3.

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

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

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

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

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

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

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

Você pode desabilitar a criação de pipelines clássicos no nível da coleção de projetos ou no nível do projeto, ativando as alternâncias correspondentes. As alternâncias podem ser encontradas em Projeto / Configurações do 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ância está desativado por padrão e você precisará de direitos de administrador para alterar o estado. Se a alternância estiver ativada no nível da organização, a desabilitação será imposta a todos os projetos. Caso contrário, cada projeto é livre para escolher se deseja impor ou não a desativação.

Quando a desabilitação da criação de pipelines clássicos for imposta, as APIs REST relacionadas à criação de pipelines clássicos, grupos de tarefas e grupos de implantação falharão. 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 que você execute 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 Executar alteração do estado do estágio deve conter informações sobre a execução, incluindo o nome do pipeline. Anteriormente, ele incluía apenas informações sobre o id e o nome da execução. Com esta atualização, fizemos alterações no evento para incluir informações ausentes.

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

Anteriormente, a interface do usuário 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 pipeline YAML reside em um repositório diferente daquele que contém o código que ele está criando. Ouvimos seus comentários da Comunidade de Desenvolvedores nos pedindo uma maneira de habilitar/desabilitar a adição da mensagem de confirmação mais recente 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, essa propriedade é definida como true. Quando você o define como false, a execução do pipeline exibirá apenas o BuildNumber.

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

Você pode usar a tarefa de Implantação de Modelo do Azure Resource Manager para criar a infraestrutura do Azure. Em resposta aos seus comentários, aumentamos o limite de integração do Azure Pipelines de 2 MB para 4 MB. Isso se alinhará com o tamanho máximo 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 do pipeline status

Com esta versão, estamos facilitando o conhecimento do status geral de uma execução de pipeline.

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

Painel lateral de estágios de tubulação

Os pipelines YAML podem ter dezenas de estágios e nem todos cabem na 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. Você pode clicar em um estágio e ir diretamente para seus logs.

Pesquisar estágios no painel lateral

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

Preparar ações rápidas

A tela Execuções de um pipeline fornece acesso rápido a todos os estágios de execuções. Nesta versão, adicionamos um painel de estágios de onde você pode executar ações para cada estágio. Por exemplo, você pode facilmente executar novamente trabalhos com falha ou executar novamente todo o estágio. O painel está disponível quando nem todos os estágios cabem 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 facilitando a leitura dos registros de verificação. Os logs de verificações fornecem informações críticas para o sucesso da implantação. Eles podem informar se você esqueceu de fechar um tíquete de item de trabalho ou se precisa atualizar um tíquete no ServiceNow. Anteriormente, saber que um cheque 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. Isso é apenas para verificações que seguem nosso uso recomendado.

Desabilitar uma verificação

Tornamos as verificações de depuração menos tediosas. Às vezes, uma verificação Invocar Função do Azure ou Invocar API REST não funciona corretamente e você precisa corrigi-la. Anteriormente, você precisava excluir essas verificações, para evitar que elas bloqueassem erroneamente uma implantação. Depois de corrigir a verificação, você teve que adicioná-la novamente e configurá-la corretamente, certificando-se de que todos os cabeçalhos necessários estejam definidos ou que os parâmetros de consulta estejam 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ções.

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

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

Aqui está um exemplo do novo corpo 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 trechos de pipeline. Eles também são um mecanismo poderoso para verificar ou impor segurança e governança por meio de seu pipeline.

O Azure Pipelines dá suporte a um editor YAML, que pode ser útil ao editar seu pipeline. No entanto, o editor não suportava modelos até agora. Os autores de pipelines YAML não puderam obter assistência por meio do intellisense ao usar um modelo. Os autores de predefinições não podiam 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 seu modelo, você será solicitado a validá-lo. 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.

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 o 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 build. A variável está disponível em pipelines de build YAML e clássicos.

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

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

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, você pode split uma string e iterar sobre each suas substrings.

variables:
  environments: integration1, integration2

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

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

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

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

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

Até hoje, você tinha que especificar explicitamente o branch a ser verificado e alterar o código do pipeline sempre que o branch for alterado.

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

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

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

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

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

Os modelos representam uma ótima maneira de reduzir a duplicação de código e melhorar 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 estende 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 que seu pipeline: estendesse um modelo de um branch diferente estendesse um modelo do mesmo nome de branch do pipeline, independentemente de qual branch você executou o pipeline

Com a introdução de expressões de modelo na definição de recurso 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 seu pipeline em uma ramificação dev, ele estenderá o modelo especificado pelo template.yml arquivo na ramificação dev do templates repositório.

Ou você pode escolher, no tempo de fila de compilação, qual ramificação do repositório de modelos 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 do 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, mas não pode usar variáveis definidas pela interface do usuário do YAML ou do 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. Este foi um recurso altamente solicitado por nossa Comunidade de Desenvolvedores.

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

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

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

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

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

Melhorias de builds agendados

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

Mensagem de erro aprimorada ao 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 falha de carregamento. Anteriormente, estávamos exibindo uma mensagem de erro enganosa, alegando que o pipeline não foi encontrado. Com esta atualização, resolvemos esse problema e estamos retornando uma mensagem de erro informativa. No futuro, você receberá a mensagem semelhante a: Os dados do cronograma de build serão corrompidos se um pipeline não for carregado.

Não sincronizar tags 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 tags. Além disso, a tarefa de checkout sincroniza tags mesmo quando você habilita a opção de busca superficial, possivelmente anulando seu propósito. 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 tags de sincronização. Essa opção está disponível em pipelines clássicos e 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 que você cria (YAML ou Classic), as tags ainda são sincronizadas por padrão. Essa opção não altera o comportamento dos pipelines existentes. As tags ainda serão sincronizadas nesses pipelines, a menos que você altere explicitamente a opção conforme descrito acima.

Artifacts

Permissões de feed padrão atualizadas

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

Nova interface de usuário para pesquisa de pacotes upstream

Anteriormente, você podia ver pacotes upstream se tivesse uma cópia do feed. O ponto problemático era que você não podia pesquisar 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 do usuário do feed.

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

Relatório

Mostrar pai no widget de resultados da consulta

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

Copiar painel

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

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

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

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

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 vistas de exibição do Analytics agora estão disponíveis

O recurso Visualizações do Google Analytics está em um estado de visualização há um longo período de tempo em nossa versão hospedada do produto. Com esta versão, temos o prazer de 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 agora está disponível

Temos o prazer de anunciar que o widget Solicitação de Pull para vários repositórios está disponível em Azure DevOps Server 2022.1. Com esse novo widget, você pode exibir sem esforço solicitações de pull de até 10 repositórios diferentes em uma única lista simplificada, tornando mais fácil do que nunca ficar por dentro de suas solicitações de pull.

Tíquete de sugestão da comunidade

Apresentando resolvido como concluído em gráficos de burndown e burnup

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

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 de pizza
• Diagramas de requisitos
• Diagramas de estado
• Percurso do Usuário

Os diagramas que estão no modo experimental, como Relacionamento de Entidade e Gráfico Git, não estão incluídos. Para obter mais informações sobre os novos recursos, consulte as notas de versão da sereia.

Comentários

Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la por meio da Comunidade de Desenvolvedores e obter conselhos sobre o Stack Overflow.