Notas de versão do Azure DevOps Server 2020

| Developer Community System Requirements | License Terms | DevOps Blog | SHA-1 Hashes

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

Para saber mais sobre como instalar ou atualizar uma implantação de Azure DevOps Server, confira Requisitos de Azure DevOps Server. Para baixar produtos do Azure DevOps, visite a página Downloads do Azure DevOps Server.

A atualização direta para o Azure DevOps Server 2020 tem suporte do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para o Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps localmente.

---

Atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020

Azure DevOps Server 2020 apresenta um novo modelo de retenção de execução de pipeline (build) que funciona com base nas configurações no nível do projeto.

Azure DevOps Server 2020 lida com a retenção de build de forma diferente, com base nas políticas de retenção no nível do pipeline. Determinadas configurações de política levam à exclusão de execuções de pipeline após a atualização. As execuções de pipeline que foram retidas manualmente ou são retidas por uma versão não serão excluídas após a atualização.

Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020.

data de lançamento do Patch 6 da atualização 0.2 do Azure DevOps Server 2020: 14 de novembro de 2023

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• Estendeu a lista de caracteres permitidos das tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas de shell.

Observação

Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente as tarefas.

Instalar patches

Importante

Lançamos atualizações para o agente do Azure Pipelines com o Patch 4 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 4, recomendamos que você instale essas atualizações antes de instalar o Patch 6. A nova versão do agente após a instalação do Patch 4 será a 3.225.0.

Configurar o TFX

1. Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.

Atualizar tarefas usando TFX

Arquivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Baixe e extraia Tasks20231103.zip.
2. Altere o diretório para os arquivos extraídos.
3. Execute os seguintes comandos para carregar as tarefas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Requisitos de pipeline

Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true deve ser definida em pipelines que usam as tarefas afetadas.

• No clássico:

  Defina a variável na guia variável no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

data de lançamento do Patch 5 da atualização 0.2 do Azure DevOps Server 2020: 10 de outubro de 2023

Importante

Lançamos atualizações para o agente do Azure Pipelines com o Patch 4 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 4, recomendamos que você instale essas atualizações antes de instalar o Patch 5. A nova versão do agente após a instalação do Patch 4 será a 3.225.0.

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• Correção de um bug em que a identidade do "Proprietário da Análise" aparece como Identidade Inativa em computadores de atualização de patch.

data de lançamento do Patch 4 da atualização 0.2 do Azure DevOps Server 2020: 12 de setembro de 2023

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• CVE-2023-33136: Azure DevOps Server vulnerabilidade de execução remota de código.
• CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.

Importante

Implante o patch em um ambiente de teste e verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.

Observação

Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente o agente e as tarefas.

Instalar patches

1. Baixe e instale o patch 4 do Azure DevOps Server 2020 Atualização 0.2.

Atualizar o agente do Azure Pipelines

1. Baixe o agente de: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
2. Use as etapas descritas na documentação de agentes auto-hospedados do Windows para implantar o agente.  

Observação

O AZP_AGENT_DOWNGRADE_DISABLED deve ser definido como "true" para impedir que o agente seja rebaixado. No Windows, o comando a seguir pode ser usado em um prompt de comando administrativo, seguido por uma reinicialização. setx AZP_AGENT_DOWNGRADE_DISABLED true /M

Configurar o TFX

1. Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.

Atualizar tarefas usando TFX

1. Baixe e extraia Tasks_20230825.zip.
2. Altere o diretório para os arquivos extraídos.
3. Execute os seguintes comandos para carregar as tarefas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Requisitos de pipeline

Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true deve ser definida em pipelines que usam as tarefas afetadas.

• No clássico:

  Defina a variável na guia variável no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

data de lançamento do Patch 3 da atualização 0.2 do Azure DevOps Server 2020: 8 de agosto de 2023

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• Corrigido um bug que interferia no envio de pacotes por push durante a atualização de 2018 ou anterior.

data de lançamento do Patch 2 da atualização 0.2 do Azure DevOps Server 2020: 13 de junho de 2023

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• Corrigido um bug que interferia no envio de pacotes por push durante a atualização de 2018 ou anterior.

data de lançamento do Patch 1 da atualização 0.2 do Azure DevOps Server 2020: 18 de outubro de 2022

Lançamos um patch para Azure DevOps Server atualização 0.2 de 2020 que inclui correções para o seguinte.

• Resolva o problema com identidades do AD recém-adicionadas que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
• Correção de um problema com o filtro Solicitado por Membro do Grupo nas configurações do web hook.
• Correção de erro de builds de marcar fechado quando as configurações da organização para pipeline tinham o escopo de autorização de trabalho configurado como Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de não lançamento.

data de lançamento do Azure DevOps Server 2020.0.2: 17 de maio de 2022

Azure DevOps Server 2020.0.2 é um acúmulo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020.0.2 ou atualizar do Azure DevOps Server 2020 ou do Team Foundation Server 2013 ou mais recente.

Observação

A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 2020.0.2 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

Esta versão inclui correções para o seguinte:

• Não é possível ignorar a fila de build usando o botão "Executar próximo". Anteriormente, o botão "Executar próximo" era habilitado apenas para administradores de coleção de projetos.

• Revogue todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário for desabilitada.

Azure DevOps Server 2020.0.1 Data de lançamento do Patch 9: 26 de janeiro de 2022

Lançamos um patch para Azure DevOps Server 2020.0.1 que inclui correções para o seguinte.

• Email notificações não foram enviadas ao usar o @mention controle em um item de trabalho.
• Corrija TF400813 erro ao alternar contas. Esse erro ocorreu quando foi atualizado do TFS 2018 para o Azure DevOps Server 2020.0.1.
• Correção do problema com a página de resumo visão geral do projeto falhando ao carregar.
• Melhoria na sincronização de usuários do Active Directory.
• Resolvido a vulnerabilidade do Elasticsearch removendo a classe jndilookup dos binários log4j.

Etapas de instalação

1. Atualize o servidor com o Patch 9.
2. Verifique o valor do Registro em HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1).
3. Execute o comando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update conforme fornecido no arquivo leiame. Ele pode retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização está executando novas tentativas até que ela seja concluída.

Observação

Se Azure DevOps Server e Elasticsearch estiverem instalados em computadores diferentes, siga as etapas descritas abaixo.

1. Atualize o servidor com o Patch 9..
2. Verifique o valor do Registro em HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1).
3. Copie o conteúdo da pasta chamada zip, localizada na C:\Program Files\{TFS Version Folder}\Search\zip pasta de arquivos remotos Elasticsearch.
4. Execute Configure-TFSSearch.ps1 -Operation update no computador do servidor Elasticsearch.

Hash SHA-256: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

data de lançamento do Patch 8 do Azure DevOps Server 2020.0.1: 15 de dezembro de 2021

O patch 8 para Azure DevOps Server 2020.0.1 inclui correções para o seguinte.

• Problema de localização para estados de layout de itens de trabalho personalizados.
• Problema de localização no modelo de notificação por email.
• Problema com logs de console sendo truncados quando há vários links idênticos em uma linha.
• Problema com a avaliação de regras NOTSAMEAS quando várias regras NOTSAMEAS foram definidas para um campo.

data de lançamento do Patch 7 do Azure DevOps Server 2020.0.1: 26 de outubro de 2021

O Patch 7 para Azure DevOps Server 2020.0.1 inclui correções para o seguinte.

• Anteriormente, Azure DevOps Server só podia criar conexões com o GitHub Enterprise Server. Com esse patch, os administradores do projeto podem criar conexões entre Azure DevOps Server e repositórios no GitHub.com. Você pode encontrar essa configuração na página de conexões do GitHub em Configurações do Projeto.
• Resolva o problema com o widget do Plano de Teste. O relatório de execução de teste estava mostrando um usuário incorreto nos resultados.
• Correção do problema com a página de resumo visão geral do projeto falhando ao carregar.
• Correção do problema com emails que não estão sendo enviados para confirmar a atualização do produto.

data de lançamento do Patch 6 do Azure DevOps Server 2020.0.1: 14 de setembro de 2021

O patch 6 para Azure DevOps Server 2020.0.1 inclui correções para o seguinte.

• Correção da falha de download/upload do Artifacts.
• Resolva o problema com dados inconsistentes dos Resultados do Teste.

Azure DevOps Server 2020.0.1 Data de lançamento do Patch 5: 10 de agosto de 2021

O Patch 5 para Azure DevOps Server 2020.0.1 inclui correções para o seguinte.

• Correção do erro de interface do usuário da definição de build.
• Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.
• Correção do problema com trabalhos de entrega de email para alguns tipos de item de trabalho.

Azure DevOps Server 2020.0.1 Data de lançamento do Patch 4: 15 de junho de 2021

O Patch 4 para Azure DevOps Server 2020.0.1 inclui correções para o seguinte.

• Correção do problema com a importação de dados. A importação de dados estava demorando muito para clientes que têm muitos casos de teste obsoletos. Isso ocorreu devido a referências que aumentaram o tamanho da tbl_testCaseReferences tabela. Com esse patch, removemos referências a casos de teste obsoletos para ajudar a acelerar o processo de importação de dados.

data de lançamento do Patch 3 do Azure DevOps Server 2020.0.1: 11 de maio de 2021

Lançamos um patch para Azure DevOps Server 2020.0.1 que corrige o seguinte.

• Dados inconsistentes de Resultados de Teste ao usar Microsoft.TeamFoundation.TestManagement.Client.

Se você tiver Azure DevOps Server 2020.0.1, instale Azure DevOps Server Patch 3 2020.0.1.

Verificando a instalação

• Opção 1: execute devops2020.0.1patch3.exe CheckInstall, devops2020.0.1patch3.exe é o arquivo baixado do link acima. A saída do comando dirá que o patch foi instalado ou que não está instalado.

• Opção 2: verifique a versão do seguinte arquivo: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 é instalado c:\Program Files\Azure DevOps Server 2020 no por padrão. Depois de instalar o patch 3 do Azure DevOps Server 2020.0.1, a versão será 18.170.31228.1.

Azure DevOps Server 2020.0.1 Data de lançamento do Patch 2: 13 de abril de 2021

Observação

Se você tiver Azure DevOps Server 2020, primeiro atualize para Azure DevOps Server 2020.0.1 . Uma vez no 2020.0.1, instale o Azure DevOps Server 2020.0.1 Patch 2

Lançamos um patch para Azure DevOps Server 2020.0.1 que corrige o seguinte.

• CVE-2021-27067: Divulgação de informações
• CVE-2021-28459: elevação de privilégio

Para implementar correções para esse patch, você precisará seguir as etapas listadas abaixo para instalação geral de patch, AzureResourceGroupDeploymentV2 e instalações de tarefa AzureResourceManagerTemplateDeploymentV3 .

Instalação geral de patch

Se você tiver Azure DevOps Server 2020.0.1, instale Azure DevOps Server patch 2020.0.1.

Verificando a instalação

• Opção 1: execute devops2020.0.1patch2.exe CheckInstall, devops2020.0.1patch2.exe é o arquivo baixado do link acima. A saída do comando dirá que o patch foi instalado ou que não está instalado.

• Opção 2: verifique a versão do seguinte arquivo: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. Azure DevOps Server 2020.0.1 é instalado c:\Program Files\Azure DevOps Server 2020 no por padrão. Depois de instalar o patch 2 do Azure DevOps Server 2020.0.1, a versão será 18.170.31123.3.

Instalação da tarefa AzureResourceGroupDeploymentV2

Observação

Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows

Instalar

1. Extraia o pacote AzureResourceGroupDeploymentV2.zip para uma nova pasta no computador. Por exemplo: D:\tasks\AzureResourceGroupDeploymentV2.

2. Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) de acordo com seu computador.

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso completo e copie-o. Esse token de acesso pessoal será usado ao executar o comando tfx login .

5. Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o Token de acesso pessoal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Execute o comando a seguir para carregar a tarefa no servidor. Use o caminho do arquivo .zip extraído da etapa 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Instalação da tarefa AzureResourceManagerTemplateDeploymentV3

Observação

Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows

Instalar

1. Extraia o pacote AzureResourceManagerTemplateDeploymentV3.zip para uma nova pasta no computador. Por exemplo:D:\tasks\AzureResourceManagerTemplateDeploymentV3.

2. Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) conforme apropriado para seu computador.

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso completo e copie-o. Esse token de acesso pessoal será usado ao executar o comando tfx login .

5. Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o Token de acesso pessoal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Execute o comando a seguir para carregar a tarefa no servidor. Use o caminho do arquivo .zip extraído da etapa 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

data de lançamento do Patch 1 do Azure DevOps Server 2020.0.1: 9 de fevereiro de 2021

Lançamos um patch para Azure DevOps Server 2020.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• Resolver o problema relatado neste tíquete de comentários Developer Community | O botão Novo Caso de Teste não está funcionando
• Inclua correções lançadas com o Patch 2 do Azure DevOps Server 2020.

data de lançamento do Patch 3 do Azure DevOps Server 2020: 9 de fevereiro de 2021

Lançamos um patch para Azure DevOps Server 2020 que corrige o seguinte. Confira a postagem no blog para saber mais.

• Resolver o problema relatado neste tíquete de comentários Developer Community | O botão Novo Caso de Teste não está funcionando

data de lançamento do Azure DevOps Server 2020.0.1: 19 de janeiro de 2021

Azure DevOps Server 2020.0.1 é um acúmulo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020.0.1 ou atualizar de uma instalação existente. As versões com suporte para atualização são Azure DevOps Server 2020, Azure DevOps Server 2019 e Team Foundation Server 2012 ou mais recente.

Essa versão inclui correções para os seguintes bugs:

• Resolva um problema de atualização do Azure DevOps Server 2019 em que o proxy do Git pode parar de funcionar após a atualização.
• Correção da exceção System.OutOfMemoryException para coleções não ENU antes do Team Foundation Server 2017 ao atualizar para o Azure DevOps Server 2020. Resolve o problema relatado neste tíquete de comentários Developer Community.
• Falha de manutenção causada por Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll ausentes. Resolve o problema relatado neste tíquete de comentários Developer Community.
• Correção do erro de nome de coluna inválido no Analytics durante a atualização para Azure DevOps Server 2020. Resolve o problema relatado neste tíquete de comentários Developer Community.
• XSS armazenado ao exibir etapas de caso de teste nos resultados do caso de teste.
• Falha na etapa de atualização durante a migração de pontos resulta em dados para o TCM.

data de lançamento do Patch 2 do Azure DevOps Server 2020: 12 de janeiro de 2021

Lançamos um patch para Azure DevOps Server 2020 que corrige o seguinte. Confira a postagem no blog para saber mais.

• Os detalhes da execução de teste não exibem detalhes da etapa de teste para dados de teste migrados usando a Migração do OpsHub
• Exceção no inicializador para 'Microsoft.TeamFoundation.TestManagement.Server.TCMLogger'
• Builds não retidos são excluídos imediatamente após a migração para Azure DevOps Server 2020
• Corrigir exceção do provedor de dados

Azure DevOps Server Patch 1 de 2020 Data: 8 de dezembro de 2020

Lançamos um patch para Azure DevOps Server 2020 que corrige o seguinte. Confira a postagem no blog para saber mais.

• CVE-2020-17145: vulnerabilidade de falsificação do Azure DevOps Server e do Team Foundation Services

data de lançamento do Azure DevOps Server 2020: 6 de outubro de 2020

Azure DevOps Server 2020 é um acúmulo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server RC2 de 2020 lançados anteriormente.

Observação

O Servidor do Azure DevOps 2020 tem um problema com a instalação de um dos assemblies usados pelo GVFS (Sistema de Arquivos Virtual do Git).

Se você estiver atualizando do Azure DevOps 2019 (qualquer versão) ou de um candidato à versão do Azure DevOps 2020 e instalando no mesmo diretório da versão anterior, o assembly Microsoft.TeamFoundation.Git.dll não será instalado. Você pode verificar se atingiu o problema procurando Microsoft.TeamFoundation.Git.dll nas pastas e <Install Dir>\Application Tier\TFSJobAgent<Install Dir>\Tools .<Install Dir>\Version Control Proxy\Web Services\bin Se o arquivo estiver ausente, você poderá executar um reparo para restaurar os arquivos ausentes.

Para executar um reparo, acesse Settings -> Apps & Features o Azure DevOps Server computador/VM e execute um reparo no Servidor do Azure DevOps 2020. Depois que o reparo for concluído, você poderá reiniciar o computador/VM.

data de lançamento do Azure DevOps Server RC2 de 2020: 11 de agosto de 2020

Azure DevOps Server RC2 de 2020 é um acúmulo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server RC1 de 2020 lançados anteriormente.

Azure DevOps Server RC1 de 2020 data de lançamento: 10 de julho de 2020

Lançamos novamente Azure DevOps Server RC1 2020 para corrigir esse tíquete de comentários Developer Community.

Anteriormente, após a atualização do Azure DevOps Server 2019 Atualização 1.1 para Azure DevOps Server RC1 2020, você não conseguia exibir arquivos no Repos, Pipelines e Wiki da interface do usuário da Web. Houve uma mensagem de erro indicando que ocorreu um erro inesperado nessa região da página. Você pode tentar recarregar esse componente ou atualizar a página inteira. Com esta versão, corrigimos esse problema. Confira a postagem no blog para saber mais.

data de lançamento do Azure DevOps Server RC1 de 2020: 30 de junho de 2020

Resumo das novidades no Azure DevOps Server 2020

Azure DevOps Server 2020 apresenta muitos novos recursos. Alguns dos destaques incluem:

• Pipelines de vários estágios
• Implantação contínua no YAML
• Acompanhar o progresso dos itens pai usando a lista de pendências Rollup on Boards
• Adicionar o filtro "Item de Trabalho Pai" ao quadro de tarefas e à lista de pendências do sprint
• Nova interface do usuário da Web para páginas de aterrissagem Azure Repos
• Administração de política de branch entre repositórios
• Página Novo Plano de Teste
• Edição avançada para páginas wiki de código
• Relatórios de falha e duração do pipeline

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

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

---

Geral

Disponibilidade geral da CLI do Azure DevOps

Em fevereiro, apresentamos a extensão do Azure DevOps para a CLI do Azure. A extensão permite que você interaja com o Azure DevOps na linha de comando. Coletamos seus comentários que nos ajudaram a melhorar a extensão e adicionar mais comandos. Agora estamos felizes em anunciar que a extensão está em disponibilidade geral.

Para saber mais sobre a CLI do Azure DevOps, confira a documentação aqui.

Usar o perfil de publicação para implantar o Azure WebApps para Windows do Centro de Implantação

Agora você pode usar a autenticação baseada em perfil de publicação para implantar seus Aplicativos Web do Azure para Windows no Centro de Implantação. Se você tiver permissão para implantar em um Azure WebApp para Windows usando seu perfil de publicação, poderá configurar o pipeline usando esse perfil nos fluxos de trabalho do Centro de Implantação.

Boards

Adicionar o filtro "Item de Trabalho Pai" ao quadro de tarefas e à lista de pendências do sprint

Adicionamos um novo filtro à placa Sprint e à lista de pendências do Sprint. Isso permite filtrar itens de lista de pendências no nível dos requisitos (primeira coluna à esquerda) pelo pai. Por exemplo, na captura de tela abaixo, filtramos a exibição para mostrar apenas histórias de usuários em que o pai é "Meu grande recurso".

Melhorar a experiência de tratamento de erros – – campos necessários em Bug/Tarefa

Historicamente, no quadro Kanban, se você moveu um item de trabalho de uma coluna para outra em que a alteração de estado disparou regras de campo, o cartão mostrará apenas uma mensagem de erro vermelha que forçará você a abrir o item de trabalho para entender a causa raiz. No sprint 170, melhoramos a experiência para que agora você possa clicar na mensagem de erro vermelha para ver os detalhes do erro sem precisar abrir o item de trabalho em si.

Recarregamento ao vivo do item de trabalho

Anteriormente, ao atualizar um item de trabalho e um segundo membro da equipe estava fazendo alterações no mesmo item de trabalho, o segundo usuário perderia suas alterações. Agora, enquanto você estiver editando campos diferentes, verá atualizações ao vivo das alterações feitas no item de trabalho.

Gerenciar caminhos de iteração e área da linha de comando

Agora você pode gerenciar caminhos de iteração e área da linha de comando usando os az boards iteration comandos e az boards area . Por exemplo, você pode configurar e gerenciar caminhos de iteração e área interativamente da CLI ou automatizar toda a configuração usando um script. Para obter mais detalhes sobre os comandos e a sintaxe, consulte a documentação aqui.

Coluna pai do item de trabalho como opção de coluna

Agora você tem a opção de ver o pai de cada item de trabalho na lista de pendências do produto ou na lista de pendências do sprint. Para habilitar esse recurso, acesse Opções de Coluna na lista de pendências desejada e adicione a coluna Pai .

Alterar o processo usado por um projeto

Suas ferramentas devem ser alteradas conforme sua equipe faz, agora você pode mudar seus projetos de qualquer modelo de processo pronto para qualquer outro processo pronto para uso. Por exemplo, você pode alterar seu projeto de usar Agile para Scrum ou Básico para Agile. Você pode encontrar a documentação passo a passo completa aqui.

Ocultar campos personalizados do layout

Agora você pode ocultar campos personalizados do layout do formulário ao personalizar seu processo. O campo ainda estará disponível em consultas e APIs REST. Isso é útil para acompanhar campos extras quando você está se integrando a outros sistemas.

Obtenha insights sobre a integridade da sua equipe com três novos relatórios de Azure Boards

Você não pode corrigir o que não pode ver. Portanto, você deseja ficar de olho no estado e na integridade dos processos de trabalho. Com esses relatórios, estamos facilitando o acompanhamento de métricas importantes com o mínimo de esforço em Azure Boards.

Os três novos relatórios interativos são: Burndown, CFD ( Diagrama de Fluxo Cumulativo ) e Velocidade. Você pode ver os relatórios na nova guia de análise.

Métricas como burndown de sprint, fluxo de trabalho e velocidade de equipe fornecem a visibilidade do progresso da sua equipe e ajudam a responder a perguntas como:

• Quanto trabalho ainda temos neste sprint? Estamos no caminho certo para concluí-lo?
• Qual etapa do processo de desenvolvimento está demorando mais? Podemos fazer algo sobre isso?
• Com base nas iterações anteriores, quanto trabalho devemos planejar para o próximo sprint?

Observação

Os gráficos mostrados anteriormente nos cabeçalhos foram substituídos por esses relatórios aprimorados.

Os novos relatórios são totalmente interativos e permitem que você os ajuste para suas necessidades. Você pode encontrar os novos relatórios na guia Análise em cada hub.

• O gráfico de burndown pode ser encontrado no hub Sprints .

  

• Os relatórios CFD e Velocity podem ser acessados na guia Análise em Quadros e Listas de Pendências clicando no cartão relevante.

  

Com os novos relatórios, você tem mais controle e informações sobre sua equipe. Estes são alguns exemplos:

• Os relatórios Burndown de Sprint e Velocity podem ser definidos para usar a contagem de itens de trabalho ou a soma do trabalho restante.
• Você pode ajustar o período do burndown de sprint sem afetar as datas do projeto. Portanto, se sua equipe geralmente passa o primeiro dia de cada planejamento de sprint, agora você pode corresponder ao gráfico para refletir isso.
• O gráfico burndown agora tem uma marca d'água mostrando fins de semana.
• O relatório CFD permite que você remova colunas de quadro como Design para obter mais foco no fluxo no qual as equipes têm controle.

Aqui está um exemplo do relatório CFD mostrando o fluxo dos últimos 30 dias da lista de pendências de Histórias.

O gráfico Velocity agora pode ser rastreado para todos os níveis de lista de pendências. Por exemplo, agora você pode adicionar Recursos e Epics, enquanto antes do gráfico anterior só tinha suporte para Requisitos. Aqui está um exemplo de um relatório de velocidade para as últimas 6 iterações da lista de pendências recursos.

Personalizar colunas do Quadro de Tarefas

Estamos felizes em anunciar que adicionamos uma opção para permitir que você personalize as colunas no Quadro de Tarefas. Agora você pode adicionar, remover, renomear e reordenar as colunas.

Para configurar as colunas no quadro de tarefas, vá para Opções de Coluna.

Esse recurso foi priorizado com base em uma sugestão do Developer Community.

Alternar para mostrar ou ocultar itens de trabalho filho concluídos na lista de pendências

Muitas vezes, ao refinar a lista de pendências, você só deseja ver itens que não foram concluídos. Agora, você tem a capacidade de mostrar ou ocultar itens filho concluídos na lista de pendências.

Se a alternância estiver ativada, você verá todos os itens filho em um estado concluído. Quando a alternância estiver desativada, todos os itens filho em um estado concluído ficarão ocultos na lista de pendências.

Marcas mais recentes exibidas ao marcar um item de trabalho

Ao marcar um item de trabalho, a opção de preenchimento automático agora exibirá até cinco de suas marcas usadas mais recentemente. Isso facilitará a adição das informações certas aos seus itens de trabalho.

Regras somente leitura e necessárias para associação de grupo

As regras de item de trabalho permitem que você defina ações específicas em campos de item de trabalho para automatizar seu comportamento. Você pode criar uma regra para definir um campo como somente leitura ou necessário com base na associação de grupo. Por exemplo, talvez você queira conceder aos proprietários de produtos a capacidade de definir a prioridade de seus recursos, tornando-a somente leitura para todos os outros.

Personalizar valores de lista de seleção do sistema

Agora você pode personalizar os valores de qualquer lista de seleção do sistema (exceto o campo motivo), como Severidade, Atividade, Prioridade etc. As personalizações de lista de seleção têm o escopo definido para que você possa gerenciar valores diferentes para o mesmo campo para cada tipo de item de trabalho.

Novo parâmetro de URL do item de trabalho

Compartilhe links para itens de trabalho com o contexto de sua placa ou lista de pendências com nosso novo parâmetro de URL de item de trabalho. Agora você pode abrir uma caixa de diálogo de item de trabalho em sua experiência de quadro, lista de pendências ou sprint acrescentando o parâmetro ?workitem=[ID] à URL.

Qualquer pessoa com quem você compartilhar o link chegará com o mesmo contexto que você tinha quando compartilhou o link!

Mencionar pessoas, itens de trabalho e PRs em campos de texto

Ao escutar seus comentários, ouvimos que você queria a capacidade de menção pessoas, itens de trabalho e PRs na área de descrição do item de trabalho (e outros campos HTML) no item de trabalho e não apenas em comentários. Às vezes, você está colaborando com alguém em um item de trabalho ou deseja realçar uma PR na descrição do item de trabalho, mas não tinha uma maneira de adicionar essas informações. Agora você pode menção pessoas, itens de trabalho e PRs em todos os campos de texto longos no item de trabalho.

Veja um exemplo aqui.

• Para usar menções de pessoas, digite o @ sinal e o nome da pessoa que você deseja menção. @mentionsem campos de item de trabalho gerarão notificações por email como o que ele faz para comentários.
• Para usar menções de item de trabalho, digite o # sinal seguido pela ID ou título do item de trabalho. #mentions criará um link entre os dois itens de trabalho.
• Para usar menções de PR, adicione um ! seguido por sua ID de PR ou nome.

Reações sobre comentários de discussão

Uma de nossas metas de main é tornar os itens de trabalho mais colaborativos para as equipes. Recentemente, realizamos uma pesquisa no Twitter para descobrir quais recursos de colaboração você deseja em discussões sobre o item de trabalho. Trazer reações aos comentários ganhou a votação, então nós os adicionamos! Aqui estão os resultados da pesquisa no Twitter.

Você pode adicionar reações a qualquer comentário e há duas maneiras de adicionar suas reações : o ícone sorridente no canto superior direito de qualquer comentário, bem como na parte inferior de um comentário ao lado de qualquer reação existente. Você pode adicionar todas as seis reações, se desejar, ou apenas uma ou duas. Para remover sua reação, clique na reação na parte inferior do comentário e ela será removida. Abaixo, você pode ver a experiência de adicionar uma reação, bem como como são as reações em um comentário.

Fixar relatórios Azure Boards no dashboard

Na Atualização do Sprint 155, incluímos versões atualizadas dos relatórios CFD e Velocity. Esses relatórios estão disponíveis na guia Análise de Quadros e Listas de Pendências. Agora você pode fixar os relatórios diretamente em seu Painel. Para fixar os relatórios, passe o mouse sobre o relatório, selecione as reticências "..." e Copiar para o Painel.

Acompanhar o progresso dos itens pai usando a lista de pendências Rollup on Boards

As colunas de rollup mostram barras de progresso e/ou totais de campos numéricos ou itens descendentes dentro de uma hierarquia. Os itens descendentes correspondem a todos os itens filhos dentro da hierarquia. Uma ou mais colunas cumulativos podem ser adicionadas a uma lista de pendências de produto ou portfólio.

Aqui, mostramos Progresso por todos os Itens de Trabalho que exibem barras de progresso para itens de trabalho crescentes com base na porcentagem de itens descendentes que foram fechados. Os itens descendentes para Epics incluem todos os Recursos filho e seus itens de trabalho filho ou filho. Os itens descendentes para Recursos incluem todas as Histórias de Usuário filho e seus itens de trabalho filho.

Atualizações dinâmicas do quadro de tarefas

Seu quadro de tarefas agora é atualizado automaticamente quando ocorrem alterações! À medida que outros membros da equipe movem ou reordenam cartões no quadro de tarefas, seu quadro será atualizado automaticamente com essas alterações. Você não precisa mais pressionar F5 para ver as alterações mais recentes.

Suporte para campos personalizados em colunas rollup

O rollup agora pode ser feito em qualquer campo, incluindo campos personalizados. Ao adicionar uma coluna Rollup, você ainda pode escolher uma coluna Rollup na lista Rápida, no entanto, se quiser fazer rollup em campos numéricos que não fazem parte do modelo de processo pronto para uso, você pode configurar o seu próprio da seguinte maneira:

1. Na lista de pendências, clique em "Opções de coluna". Em seguida, no painel, clique em "Adicionar coluna rollup" e Configurar rollup personalizado.

   

2. Escolha entre a Barra de Progresso e o Total.
3. Selecione um tipo de item de trabalho ou um nível de lista de pendências (geralmente as listas de pendências agregam vários tipos de item de trabalho).
4. Selecione o tipo de agregação. Contagem de itens de trabalho ou Soma. Para Soma, você precisará selecionar o campo a ser resumido.
5. O botão OK o levará de volta ao painel de opções de coluna, no qual você pode reordenar sua nova coluna personalizada.

Observe que você não pode editar sua coluna personalizada depois de clicar em OK. Se você precisar fazer uma alteração, remova a coluna personalizada e adicione outra conforme desejado.

Nova regra para ocultar campos em um formulário de item de trabalho com base na condição

Adicionamos uma nova regra ao mecanismo de regras herdado para permitir que você oculte campos em um formulário de item de trabalho. Essa regra ocultará campos com base na associação de grupo de usuários. Por exemplo, se o usuário pertencer ao grupo "proprietário do produto", você poderá ocultar um campo específico do desenvolvedor. Para obter mais detalhes, consulte a documentação aqui.

Configurações de notificação de item de trabalho personalizado

Manter-se atualizado sobre itens de trabalho relevantes para você ou sua equipe é incrivelmente importante. Ele ajuda as equipes a colaborar e manter-se no caminho certo com os projetos e garante que todas as partes certas estejam envolvidas. No entanto, diferentes stakeholders têm diferentes níveis de investimento em diferentes esforços e acreditamos que isso deve ser refletido em sua capacidade de seguir o status de um item de trabalho.

Anteriormente, se você quisesse seguir um item de trabalho e receber notificações sobre quaisquer alterações feitas, obteria notificações por email para qualquer e todas as alterações feitas no item de trabalho. Depois de considerar seus comentários, estamos tornando o acompanhamento de um item de trabalho mais flexível para todos os stakeholders. Agora, você verá um novo botão de configurações ao lado do botão Seguir no canto superior direito do item de trabalho. Isso levará você a um pop-up que permitirá que você configure suas opções a seguir.

Em Configurações de Notificação, você pode escolher entre três opções de notificação. Primeiro, você pode ser completamente desconscrito. Em segundo lugar, você pode ser totalmente inscrito, onde recebe notificações para todas as alterações de item de trabalho. Por fim, você pode optar por ser notificado para alguns dos principais e cruciais eventos de alteração de item de trabalho. Você pode selecionar apenas uma ou todas as três opções. Isso permitirá que os membros da equipe sigam itens de trabalho em um nível mais alto e não se distraiam com cada alteração feita. Com esse recurso, eliminaremos emails desnecessários e permitiremos que você se concentre nas tarefas cruciais em questão.

Vincular itens de trabalho a implantações

Estamos entusiasmados em liberar o controle implantação no formulário do item de trabalho. Esse controle vincula seus itens de trabalho a uma versão e permite que você acompanhe facilmente onde seu item de trabalho foi implantado. Para saber mais, confira a documentação aqui.

Importar itens de trabalho de um arquivo CSV

Até agora, a importação de itens de trabalho de um arquivo CSV dependia do uso do plug-in do Excel. Nesta atualização, estamos fornecendo uma experiência de importação de primeira classe diretamente de Azure Boards para que você possa importar itens de trabalho novos ou atualizados existentes. Para saber mais, confira a documentação aqui.

Adicionar o campo pai aos cartões de item de trabalho

O contexto pai agora está disponível em seu quadro Kanban como um novo campo para cartões de item de trabalho. Agora você pode adicionar o campo Pai aos seus cartões, ignorando a necessidade de usar soluções alternativas, como marcas e prefixos.

Adicionar campo pai à lista de pendências e consultas

O campo pai agora está disponível ao exibir listas de pendências e resultados da consulta. Para adicionar o campo pai, use a exibição Opções de coluna .

Repos

Métricas de cobertura de código e política de branch para solicitações de pull

Agora você pode ver as métricas de cobertura de código para alterações na exibição de PR (solicitação de pull). Isso garante que você tenha testado adequadamente suas alterações por meio de testes automatizados. O status de cobertura será exibido como um comentário na visão geral da PR. Você pode exibir detalhes das informações de cobertura para cada linha de código alterada na exibição de comparação de arquivos.

Além disso, os proprietários de repositório agora podem definir políticas de cobertura de código e impedir que alterações grandes e não testadas sejam mescladas em um branch. Os limites de cobertura desejados podem ser definidos em um azurepipelines-coverage.yml arquivo de configurações que é verificado na raiz do repositório e a política de cobertura pode ser definida usando a política de configuração existente de uma ramificação para recursos de serviços adicionais no Azure Repos.

Filtrar notificações de comentários de solicitações de pull

Os comentários em solicitações de pull geralmente podem gerar muito ruído devido a notificações. Adicionamos uma assinatura personalizada que permite filtrar quais notificações de comentário você assina por idade do comentário, comentarista, comentário excluído, usuários mencionados, autor de solicitação de pull, participantes de branch de destino e thread. Você pode criar essas assinaturas de notificação clicando no ícone do usuário no canto superior direito e navegando até Configurações do usuário.

Ganchos de serviço para comentários de solicitação de pull

Agora você pode criar ganchos de serviço para comentários em uma solicitação de pull com base no repositório e no branch de destino.

Política para bloquear arquivos com padrões especificados

Os administradores agora podem definir uma política para impedir que commits sejam enviados por push para um repositório com base em tipos de arquivo e caminhos. A política de validação de nome de arquivo bloqueará pushes que correspondem ao padrão fornecido.

Resolver itens de trabalho por meio de commits usando palavras-chave

Agora você pode resolve itens de trabalho por meio de commits feitos no branch padrão usando palavras-chave como correção, correções ou correções. Por exemplo, você pode escrever : "essa alteração corrigiu #476" em seu mensagem do commit e o item de trabalho nº 476 será concluído quando a confirmação for enviada por push ou mesclada no branch padrão. Para obter mais detalhes, consulte a documentação aqui.

Granularidade para revisores automáticos

Anteriormente, ao adicionar revisores de nível de grupo a uma solicitação de pull, apenas uma aprovação era necessária do grupo que foi adicionado. Agora você pode definir políticas que exigem mais de um revisor de uma equipe para aprovar uma solicitação de pull ao adicionar revisores automáticos. Além disso, você pode adicionar uma política para impedir que os solicitantes aprovem suas próprias alterações.

Usar a autenticação baseada em conta de serviço para se conectar ao AKS

Anteriormente, ao configurar o Azure Pipelines do Centro de Implantação do AKS, usamos uma Conexão de Resource Manager do Azure. Essa conexão tinha acesso a todo o cluster e não apenas ao namespace para o qual o pipeline foi configurado. Com essa atualização, nossos pipelines usarão a autenticação baseada em conta de serviço para se conectar ao cluster para que ele tenha acesso apenas ao namespace associado ao pipeline.

Visualizar arquivos Markdown na comparação lado a lado da solicitação de pull

Agora você pode ver uma visualização da aparência de um arquivo markdown usando o novo botão Visualização . Além disso, você pode ver o conteúdo completo de um arquivo na comparação lado a lado selecionando o botão Exibir .

Expiração da política de build para builds manuais

As políticas impõem a qualidade de código e os padrões de gerenciamento de alterações da sua equipe. Anteriormente, você podia definir políticas de expiração de build para builds automatizados. Agora você também pode definir políticas de expiração de build para seus builds manuais.

Adicionar uma política para bloquear commits com base no email autor do commit

Os administradores agora podem definir uma política de push para impedir que commits sejam enviados por push para um repositório para o qual o email autor do commit não corresponde ao padrão fornecido.

Esse recurso foi priorizado com base em uma sugestão do Developer Community para oferecer uma experiência semelhante. Continuaremos a manter o tíquete aberto e incentivaremos os usuários a nos dizerem quais outros tipos de políticas de push você gostaria de ver.

Marcar arquivos conforme revisado em uma solicitação de pull

Às vezes, você precisa examinar solicitações de pull que contêm alterações em um grande número de arquivos e pode ser difícil controlar quais arquivos você já examinou. Agora você pode marcar arquivos como revisados em uma solicitação de pull.

Você pode marcar um arquivo como revisado usando o menu suspenso ao lado de um nome de arquivo ou passando o mouse e clicando no nome do arquivo.

Observação

Esse recurso destina-se apenas a acompanhar seu progresso à medida que você examina uma solicitação de pull. Ele não representa a votação em solicitações de pull, portanto, essas marcas só ficarão visíveis para o revisor.

Esse recurso foi priorizado com base em uma sugestão do Developer Community.

Nova interface do usuário da Web para páginas de aterrissagem Azure Repos

Agora você pode experimentar nossas novas páginas de aterrissagem modernas, rápidas e amigáveis para dispositivos móveis em Azure Repos. Essas páginas estão disponíveis como páginas de aterrissagem do Novo Repos. As páginas de aterrissagem incluem todas as páginas, exceto para detalhes da solicitação de pull, detalhes de confirmação e comparação de branch.

Web

Dispositivos móveis

Administração de política de branch entre repositórios

As políticas de branch são um dos recursos avançados do Azure Repos que ajudam você a proteger branches importantes. Embora a capacidade de definir políticas no nível do projeto exista na API REST, não havia nenhuma interface do usuário para ela. Agora, os administradores podem definir políticas em um branch específico ou no branch padrão em todos os repositórios em seu projeto. Por exemplo, um administrador pode exigir dois revisores mínimos para todas as solicitações de pull feitas em cada branch main em cada repositório em seu projeto. Você pode encontrar o recurso Adicionar proteção de branch nas Configurações do Projeto do Repos.

Novas páginas de aterrissagem de conversão da plataforma Web

Atualizamos a experiência do usuário das páginas de aterrissagem do Repos para torná-la moderna, rápida e amigável para dispositivos móveis. Aqui estão dois exemplos das páginas que foram atualizadas, continuaremos a atualizar outras páginas em atualizações futuras.

Experiência na Web:

Experiência móvel:

Suporte para a linguagem Kotlin

Estamos felizes em anunciar que agora damos suporte ao realce da linguagem Kotlin no editor de arquivos. Realçar melhorará a legibilidade do arquivo de texto Kotlin e ajudará você a verificar rapidamente para encontrar erros. Priorizamos esse recurso com base em uma sugestão do Developer Community.

Assinatura de notificação personalizada para solicitações pull de rascunho

Para ajudar a reduzir o número de notificações por email de solicitações de pull, agora você pode criar uma assinatura de notificação personalizada para solicitações de pull criadas ou atualizadas no estado de rascunho. Você pode receber emails especificamente para solicitações de pull de rascunho ou filtrar emails de solicitações de pull de rascunho para que sua equipe não seja notificada antes que a solicitação de pull esteja pronta para ser revisada.

Melhor capacidade de ação de PR

Quando você tem muitas solicitações de pull para revisar, entender onde você deve tomar medidas primeiro pode ser difícil. Para melhorar a capacidade de ação de solicitação de pull, agora você pode criar várias consultas personalizadas na página da lista de solicitações de pull com várias novas opções para filtrar por, como estado de rascunho. Essas consultas criarão seções separadas e recolhidas em sua página de solicitação de pull, além de "Criado por mim" e "Atribuído a mim". Você também pode recusar a revisão de uma solicitação de pull à qual foi adicionado por meio do menu Voto ou do menu de contexto na página da lista de solicitações de pull. Nas seções personalizadas, agora você verá guias separadas para solicitações de pull nas quais você forneceu uma revisão ou se recusou a revisar. Essas consultas personalizadas funcionarão em repositórios na guia "Minhas solicitações de pull" da home page da coleção. Se você quiser voltar para uma solicitação de pull, poderá sinalizá-la e elas aparecerão na parte superior da sua lista. Por fim, as solicitações de pull que foram definidas como preenchimento automático serão marcadas com uma pílula que diz "Preenchimento automático" na lista.

Pipelines

Pipelines de vários estágios

Estamos trabalhando em uma experiência de usuário atualizada para gerenciar seus pipelines. Essas atualizações tornam a experiência de pipelines moderna e consistente com a direção do Azure DevOps. Além disso, essas atualizações reúnem pipelines de build clássicos e pipelines YAML de vários estágios em uma única experiência. Ele é compatível com dispositivos móveis e traz várias melhorias na forma como você gerencia seus pipelines. Você pode fazer drill down e exibir detalhes do pipeline, detalhes da execução, análise de pipeline, detalhes do trabalho, logs e muito mais.

Os seguintes recursos estão incluídos na nova experiência:

• exibindo e gerenciando vários estágios
• aprovando execuções de pipeline
• rolar todo o caminho de volta nos logs enquanto um pipeline ainda está em andamento
• integridade por branch de um pipeline.

Implantação contínua no YAML

Estamos felizes em fornecer recursos de CD YAML do Azure Pipelines. Agora oferecemos uma experiência unificada de YAML para que você possa configurar cada um de seus pipelines para fazer CI, CD ou CI e CD juntos. Os recursos de CD YAML apresentam vários novos recursos avançados que estão disponíveis para todas as coleções usando pipelines YAML de vários estágios. Alguns dos destaques incluem:

• Pipelines YAML de vários estágios (para CI e CD)
• Aprovações e verificações de recursos
• Ambientes e estratégias de implantação
• Recursos do Kubernetes e da Máquina Virtual no ambiente
• Examinar aplicativos para colaboração
• UX atualizada para conexões de serviço
• Recursos em pipelines YAML

Se você estiver pronto para começar a compilar, marcar a documentação ou o blog para criar pipelines de CI/CD de vários estágios.

Gerenciar variáveis de pipeline no editor YAML

Atualizamos a experiência para gerenciar variáveis de pipeline no editor YAML. Você não precisa mais ir ao editor clássico para adicionar ou atualizar variáveis em seus pipelines YAML.

Aprovar versões diretamente do Hub de Versões

A ação sobre aprovações pendentes foi facilitada. Antes, era possível aprovar uma versão da página de detalhes da versão. Agora você pode aprovar versões diretamente do hub de Versões.

Melhorias na introdução aos pipelines

Uma pergunta comum com o assistente de introdução foi a capacidade de renomear o arquivo gerado. Atualmente, ele é verificado como azure-pipelines.yml na raiz do repositório. Agora você pode atualizá-lo para um nome ou local de arquivo diferente antes de salvar o pipeline.

Por fim, teremos mais controle ao fazer check-in do azure-pipelines.yml arquivo em um branch diferente, pois você pode optar por ignorar a criação de uma solicitação de pull desse branch.

Visualizar o documento YAML totalmente analisado sem confirmar ou executar o pipeline

Adicionamos uma versão prévia, mas não executamos o modo para pipelines YAML. Agora, você pode experimentar um pipeline YAML sem confirmá-lo a um repositório ou executá-lo. Considerando um pipeline existente e uma nova carga YAML opcional, essa nova API devolverá o pipeline yaml completo. Em atualizações futuras, essa API será usada em um novo recurso de editor.

Para desenvolvedores: POSTE para dev.azure.com/<org>/<project>/_apis/pipelines/<pipelineId>/runs?api-version=5.1-preview com um corpo JSON como este:

{
  "PreviewRun": true,
  "YamlOverride": "
# your new YAML here, optionally
"
}

A resposta conterá o YAML renderizado.

Agendamentos cron no YAML

Anteriormente, você poderia usar o editor de interface do usuário para especificar um gatilho agendado para pipelines YAML. Com esta versão, você pode agendar builds usando a sintaxe cron em seu arquivo YAML e aproveitar os seguintes benefícios:

1. Configuração como código: você pode acompanhar os agendamentos junto com seu pipeline como parte do código.
2. Expressivo: você tem um poder mais expressivo na definição de agendas do que o que foi capaz com a interface do usuário. Por exemplo, é mais fácil especificar um único agendamento que inicia uma execução a cada hora.
3. Padrão do setor: muitos desenvolvedores e administradores já estão familiarizados com a sintaxe cron.

schedules:
- cron: "0 0 * * *"
 displayName: Daily midnight build
 branches:
  include:
  - main
  - releases/*
  exclude:
  - releases/ancient/*
 always: true

Também facilitamos o diagnóstico de problemas com agendas cron. As execuções agendadas no menu Executar pipeline fornecerão uma visualização das próximas execuções agendadas para seu pipeline para ajudá-lo a diagnosticar erros com seus agendamentos cron.

Atualizações à interface do usuário de conexões de serviço

Estamos trabalhando em uma experiência de usuário atualizada para gerenciar suas conexões de serviço. Essas atualizações tornam a experiência de conexão de serviço moderna e consistente com a direção do Azure DevOps. Introduzimos a nova interface do usuário para conexões de serviço como um recurso de visualização no início deste ano. Obrigado a todos que experimentaram a nova experiência e nos forneceram seus valiosos comentários.

Juntamente com a atualização da experiência do usuário, também adicionamos dois recursos que são essenciais para consumir conexões de serviço em pipelines YAML: autorizações e aprovações e verificações de pipeline.

A nova experiência do usuário será ativada por padrão com essa atualização. Você ainda terá a opção de recusar a versão prévia.

Observação

Planejamos introduzir o Compartilhamento entre projetos de conexões de serviço como uma nova funcionalidade. Você pode encontrar mais detalhes sobre a experiência de compartilhamento e as funções de segurança aqui.

Ignorando estágios em um pipeline YAML

Quando você inicia uma execução manual, às vezes você pode querer ignorar alguns estágios em seu pipeline. Por exemplo, se você não quiser implantar na produção ou se quiser ignorar a implantação em alguns ambientes em produção. Agora você pode fazer isso com seus pipelines YAML.

O painel de pipeline de execução atualizado apresenta uma lista de estágios do arquivo YAML e você tem a opção de ignorar um ou mais desses estágios. Você deve ter cuidado ao ignorar estágios. Por exemplo, se o primeiro estágio produzir determinados artefatos necessários para estágios subsequentes, você não deverá ignorar o primeiro estágio. O painel de execução apresenta um aviso genérico sempre que você ignora estágios que têm dependências downstream. Cabe a você saber se essas dependências são verdadeiras dependências de artefato ou se elas estão apenas presentes para sequenciamento de implantações.

Ignorar um estágio é equivalente a religar as dependências entre os estágios. Todas as dependências downstream imediatas do estágio ignorado são feitas para depender do upstream pai do estágio ignorado. Se a execução falhar e se você tentar executar novamente um estágio com falha, essa tentativa também terá o mesmo comportamento de ignorar. Para alterar quais estágios são ignorados, você precisa iniciar uma nova execução.

Conexões de serviço nova interface do usuário como experiência padrão

Há uma nova interface do usuário de conexões de serviço. Essa nova interface do usuário é criada com base em padrões de design modernos e vem com vários recursos críticos para dar suporte a pipelines de CD YAML de vários estágios, como aprovações, autorizações e compartilhamento entre projetos.

Saiba mais sobre conexões de serviço aqui.

Seletor de versão do recurso de pipeline no diálogo criar execução

Adicionamos a capacidade de selecionar manualmente versões de recursos de pipeline no diálogo criar execução. Se você consumir um pipeline como um recurso em outro pipeline, agora poderá escolher a versão desse pipeline ao criar uma execução.

az Melhorias da CLI para o Azure Pipelines

Comandos de gerenciamento de variáveis e grupo de variáveis de pipeline

Pode ser desafiador portar pipelines baseados em YAML de um projeto para outro, pois você precisa configurar manualmente as variáveis de pipeline e os grupos de variáveis. No entanto, com o grupo de variáveis de pipeline e os comandos de gerenciamento de variáveis , agora você pode criar scripts de configuração e gerenciamento de variáveis e variáveis de variáveis que, por sua vez, podem ser controlados por versão, permitindo que você compartilhe facilmente as instruções para mover e configurar pipelines de um projeto para outro.

Executar pipeline para um branch de PR

Ao criar uma PR, pode ser desafiador validar se as alterações podem interromper a execução do pipeline no branch de destino. No entanto, com a capacidade de disparar uma execução de pipeline ou enfileirar um build para um branch de PR, agora você pode validar e visualizar as alterações que estão entrando executando-a no pipeline de destino. Consulte az pipelines run e az pipelines build queue command documentation for more information.

Ignorar a primeira execução de pipeline

Ao criar pipelines, às vezes você deseja criar e confirmar um arquivo YAML e não disparar a execução do pipeline, pois isso pode resultar em uma execução com falha devido a uma variedade de motivos – a infraestrutura não está pronta ou precisa criar e atualizar grupos de variáveis/variáveis etc. Com a CLI do Azure DevOps, agora você pode ignorar a primeira execução de pipeline automatizado na criação de um pipeline, incluindo o parâmetro --skip-first-run. Consulte az pipeline create command documentation para obter mais informações.

Aprimoramento do comando do ponto de extremidade de serviço

Os comandos da CLI do ponto de extremidade de serviço suportavam apenas a configuração e o gerenciamento do ponto de extremidade de serviço do azure rm e do github. No entanto, com essa versão, os comandos de ponto de extremidade de serviço permitem que você crie qualquer ponto de extremidade de serviço fornecendo a configuração por meio de arquivo e fornece comandos otimizados – az devops service-endpoint github e az devops service-endpoint azurerm, que fornecem suporte de primeira classe para criar pontos de extremidade de serviço desses tipos. Consulte a documentação do comando para obter mais informações.

Trabalhos de implantação

Um trabalho de implantação é um tipo especial de trabalho usado para implantar seu aplicativo em um ambiente. Com essa atualização, adicionamos suporte para referências de etapa em um trabalho de implantação. Por exemplo, você pode definir um conjunto de etapas em um arquivo e fazer referência a ele em um trabalho de implantação.

Também adicionamos suporte para propriedades adicionais ao trabalho de implantação. Por exemplo, aqui estão algumas propriedades de um trabalho de implantação que agora você pode definir,

• timeoutInMinutes – quanto tempo executar o trabalho antes de cancelar automaticamente
• cancelTimeoutInMinutes – quanto tempo dar a "executar sempre mesmo se as tarefas canceladas" antes de encerrá-las
• condition – executar o trabalho condicionalmente
• variáveis – os valores codificados em código podem ser adicionados diretamente ou grupos de variáveis, o grupo de variáveis apoiado por um cofre de chaves do Azure pode ser referenciado ou você pode se referir a um conjunto de variáveis definido em um arquivo.
• continueOnError - se trabalhos futuros devem ser executados mesmo se esse trabalho de implantação falhar; usa como padrão 'false'

Para obter mais detalhes sobre trabalhos de implantação e a sintaxe completa para especificar um trabalho de implantação, consulte Trabalho de implantação.

Mostrando informações de pipelines de CD associados em pipelines de CI

Adicionamos suporte aos detalhes de pipelines de CD YAML nos quais os pipelines de CI são chamados de recursos de pipeline. No modo de exibição de execução do pipeline de CI, agora você verá uma nova guia "Pipelines associados", na qual poderá encontrar todas as execuções de pipeline que consomem o pipeline e os artefatos dele.

Suporte para pacotes do GitHub em pipelines YAML

Recentemente, introduzimos um novo tipo de recurso chamado pacotes que adiciona suporte para consumir pacotes NuGet e npm do GitHub como um recurso em pipelines YAML. Como parte desse recurso, agora você pode especificar o tipo de pacote (NuGet ou npm) que deseja consumir do GitHub. Você também pode habilitar gatilhos de pipeline automatizados após o lançamento de uma nova versão do pacote. Hoje, o suporte só está disponível para consumir pacotes do GitHub, mas, seguindo em frente, planejamos estender o suporte para consumir pacotes de outros repositórios de pacotes, como NuGet, npm, AzureArtifacts e muito mais. Consulte o exemplo abaixo para obter detalhes:

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConn # Github service connection of type PAT
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.9 # Version of the packge to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Observação

Hoje, os pacotes do GitHub só dão suporte à autenticação baseada em PAT, o que significa que a conexão de serviço do GitHub no recurso de pacote deve ser do tipo PAT. Depois que essa limitação for levantada, forneceremos suporte para outros tipos de autenticação.

Por padrão, os pacotes não são baixados automaticamente em seus trabalhos, portanto, por isso introduzimos uma macro getPackage que permite consumir o pacote definido no recurso. Consulte o exemplo abaixo para obter detalhes:

- job: job1
  pool: default
  steps:
    - getPackage: myPackageAlias # Alias of the package resource

link do cluster Serviço de Kubernetes do Azure na exibição de recursos de ambientes do Kubernetes

Adicionamos um link à exibição de recursos de ambientes do Kubernetes para que você possa navegar até a folha do Azure para o cluster correspondente. Isso se aplica a ambientes mapeados para namespaces em clusters Serviço de Kubernetes do Azure.

Liberar filtros de pasta em assinaturas de notificação

As pastas permitem organizar pipelines para facilitar a descoberta e o controle de segurança. Geralmente, convém configurar notificações por email personalizados para todos os pipelines de lançamento, que são representados por todos os pipelines em uma pasta. Anteriormente, você precisava configurar várias assinaturas ou ter uma consulta complexa nas assinaturas para obter emails focados. Com essa atualização, agora você pode adicionar uma cláusula de pasta de lançamento à implantação concluída e aprovação de eventos pendentes e simplificar as assinaturas.

Vincular itens de trabalho com pipelines YAML de vários estágios

Atualmente, você pode vincular automaticamente itens de trabalho com builds clássicos. No entanto, isso não era possível com pipelines YAML. Com essa atualização, resolvemos essa lacuna. Quando você executa um pipeline com êxito usando o código de um branch especificado, o Azure Pipelines associará automaticamente a execução a todos os itens de trabalho (que são inferidos por meio dos commits nesse código). Ao abrir o item de trabalho, você poderá ver as execuções nas quais o código desse item de trabalho foi criado. Para configurar isso, use o painel de configurações de um pipeline.

Cancelar estágio em uma execução de pipeline YAML de vários estágios

Ao executar um pipeline YAML de vários estágios, agora você pode cancelar a execução de um estágio enquanto ele está em andamento. Isso será útil se você souber que o estágio falhará ou se você tiver outra execução que deseja iniciar.

Repetir estágios com falha

Um dos recursos mais solicitados em pipelines de vários estágios é a capacidade de repetir um estágio com falha sem precisar começar desde o início. Com essa atualização, estamos adicionando uma grande parte dessa funcionalidade.

Agora você pode repetir um estágio de pipeline quando a execução falhar. Todos os trabalhos que falharam na primeira tentativa e aqueles que dependem transitivamente desses trabalhos com falha são todos tentados novamente.

Isso pode ajudá-lo a economizar tempo de várias maneiras. Por exemplo, ao executar vários trabalhos em uma fase, talvez você queira que cada estágio execute testes em uma plataforma diferente. Se os testes em uma plataforma falharem enquanto outros forem aprovados, você poderá economizar tempo não executando novamente os trabalhos aprovados. Como outro exemplo, uma fase de implantação pode ter falhado devido à conexão de rede irregular. Repetir esse estágio ajudará você a economizar tempo não precisando produzir outro build.

Há algumas lacunas conhecidas nesse recurso. Por exemplo, você não pode repetir um estágio que cancela explicitamente. Estamos trabalhando para fechar essas lacunas em atualizações futuras.

Aprovações em pipelines YAML de vários estágios

Seus pipelines de CD YAML podem conter aprovações manuais. Os proprietários de infraestrutura podem proteger seus ambientes e buscar aprovações manuais antes que um estágio em qualquer pipeline seja implantado neles. Com a segregação completa de funções entre proprietários de infraestrutura (ambiente) e aplicativo (pipeline), você garantirá a aprovação manual para implantação em um pipeline específico e obterá controle central na aplicação das mesmas verificações em todas as implantações ao ambiente.

As execuções de pipeline que estão sendo implantadas no desenvolvimento serão interrompidas para aprovação no início da fase.

Aumentar o limite de tempo limite e a frequência dos portões

Anteriormente, o limite de tempo limite do portão em pipelines de lançamento era de três dias. Com essa atualização, o limite de tempo limite foi aumentado para 15 dias para permitir portões com durações mais longas. Também aumentamos a frequência do portão para 30 minutos.

Novo modelo de imagem de build para Dockerfile

Anteriormente, ao criar um pipeline para um Dockerfile na criação de um novo pipeline, o modelo recomendava enviar a imagem por push para um Registro de Contêiner do Azure e implantar em um Serviço de Kubernetes do Azure. Adicionamos um novo modelo para permitir que você crie uma imagem usando o agente sem a necessidade de enviar por push para um registro de contêiner.

Nova tarefa para definir Serviço de Aplicativo do Azure configurações de aplicativo

Serviço de Aplicativo do Azure permite a configuração por meio de várias configurações, como configurações de aplicativo, cadeias de conexão e outras definições gerais de configuração. Agora temos uma nova tarefa do Azure Pipelines Serviço de Aplicativo do Azure Configurações que dá suporte à definição dessas configurações em massa usando a sintaxe JSON em seu aplicativo Web ou em qualquer um de seus slots de implantação. Essa tarefa pode ser usada junto com outras tarefas do Serviço de Aplicativo para implantar, gerenciar e configurar seus aplicativos Web, aplicativos de funções ou qualquer outro Serviço de Aplicativo em contêineres.

Serviço de Aplicativo do Azure agora dá suporte a Swap com versão prévia

Serviço de Aplicativo do Azure agora dá suporte a Swap com versão prévia em seus slots de implantação. Essa é uma boa maneira de validar o aplicativo com a configuração de produção antes que o aplicativo seja realmente trocado de um slot de preparo para o slot de produção. Isso também garantiria que o slot de destino/produção não experimentasse tempo de inatividade.

Serviço de Aplicativo do Azure tarefa agora dá suporte a essa troca de várias fases por meio das seguintes novas ações:

• Iniciar Troca com Versão Prévia – inicia uma troca com uma versão prévia (troca de várias fases) e aplica a configuração de slot de destino (por exemplo, o slot de produção) ao slot de origem.
• Concluir a Troca com Visualização – quando estiver pronto para concluir a troca pendente, selecione a ação Concluir Troca com Visualização.
• Cancelar Troca com Visualização – para cancelar uma troca pendente, selecione Cancelar Troca com Visualização.

Filtro de nível de estágio para artefatos de Registro de Contêiner do Azure e Docker Hub

Anteriormente, os filtros de expressão regular para artefatos de Registro de Contêiner do Azure e Docker Hub só estavam disponíveis no nível do pipeline de lançamento. Eles também foram adicionados no nível do estágio.

Aprimoramentos nas aprovações em pipelines YAML

Habilitamos a configuração de aprovações em conexões de serviço e pools de agentes. Para aprovações, seguimos a segregação de funções entre proprietários de infraestrutura e desenvolvedores. Ao configurar aprovações em seus recursos, como ambientes, conexões de serviço e pools de agentes, você terá certeza de que todas as execuções de pipeline que usam recursos exigirão aprovação primeiro.

A experiência é semelhante à configuração de aprovações para ambientes. Quando uma aprovação está pendente em um recurso referenciado em um estágio, a execução do pipeline aguarda até que o pipeline seja aprovado manualmente.

Suporte a testes de estrutura de contêiner no Azure Pipelines

O uso de contêineres em aplicativos está aumentando e, portanto, a necessidade de testes e validação robustos. O Azure Pipelines agora traz suporte para testes de estrutura de contêiner. Essa estrutura fornece uma maneira conveniente e poderosa de verificar o conteúdo e a estrutura de seus contêineres.

Você pode validar a estrutura de uma imagem com base em quatro categorias de testes que podem ser executados juntos: testes de comando, testes de existência de arquivo, testes de conteúdo de arquivo e testes de metadados. Você pode usar os resultados no pipeline para tomar decisões go/no go. Os dados de teste estão disponíveis na execução do pipeline com uma mensagem de erro para ajudá-lo a solucionar melhor as falhas.

Inserir o arquivo de configuração e os detalhes da imagem

Dados de teste e resumo

Decoradores de pipeline para pipelines de lançamento

Os decoradores de pipeline permitem adicionar etapas ao início e ao fim de cada trabalho. Isso é diferente de adicionar etapas a uma única definição porque ela se aplica a todos os pipelines em uma coleção.

Temos suportado decoradores para builds e pipelines YAML, com clientes usando-os para controlar centralmente as etapas em seus trabalhos. Agora também estamos estendendo o suporte para pipelines de lançamento. Você pode criar extensões para adicionar etapas direcionadas ao novo ponto de contribuição e elas serão adicionadas a todos os trabalhos do agente em pipelines de lançamento.

Implantar o ARM (Azure Resource Manager) no nível do grupo de gerenciamento e assinatura

Anteriormente, tínhamos suporte apenas para implantações no nível do Grupo de Recursos. Com essa atualização, adicionamos suporte para implantar modelos do ARM nos níveis de assinatura e grupo de gerenciamento. Isso ajudará você ao implantar um conjunto de recursos juntos, mas colocá-los em diferentes grupos de recursos ou assinaturas. Por exemplo, implantar a máquina virtual de backup para o Azure Site Recovery em um grupo de recursos e local separados.

Funcionalidades de CD para seus pipelines YAML de vários estágios

Agora você pode consumir artefatos publicados pelo pipeline de CI e habilitar gatilhos de conclusão de pipeline. Em pipelines YAML de vários estágios, estamos introduzindo pipelines como um recurso. No YAML, agora você pode consultar outro pipeline e também habilitar gatilhos de CD.

Aqui está o esquema YAML detalhado para o recurso de pipelines.

resources: 
  pipelines:
  - pipeline: MyAppCI  # identifier for the pipeline resource
    project:  DevOpsProject # project for the build pipeline; optional input for current project
    source: MyCIPipeline  # source pipeline definition name
    branch: releases/M159  # branch to pick the artifact, optional; defaults to all branches
    version: 20190718.2 # pipeline run number to pick artifact; optional; defaults to last successfully completed run
    trigger:     # Optional; Triggers are not enabled by default.
      branches:  
        include:  # branches to consider the trigger events, optional; defaults to all branches.
        - main
        - releases/*
        exclude:   # branches to discard the trigger events, optional; defaults to none.
        - users/*  

Além disso, você pode baixar os artefatos publicados pelo recurso de pipeline usando a - download tarefa .

steps: 
- download: MyAppCI  # pipeline resource identifier
    artifact:  A1 # name of the artifact to download; optional; defaults to all artifacts

Para obter mais detalhes, consulte a documentação de download de artefatos aqui.

Orquestrar a estratégia de implantação canário no ambiente para Kubernetes

Uma das principais vantagens da entrega contínua de atualizações de aplicativos é a capacidade de enviar atualizações por push rapidamente para produção para microsserviços específicos. Isso oferece a capacidade de responder rapidamente às alterações nos requisitos de negócios. O ambiente foi introduzido como um conceito de primeira classe, permitindo a orquestração de estratégias de implantação e facilitando versões de tempo de inatividade zero. Anteriormente, damos suporte à estratégia runOnce , que executou as etapas uma vez sequencialmente. Com suporte para estratégia canário em pipelines de vários estágios, agora você pode reduzir o risco distribuindo lentamente a alteração para um subconjunto pequeno. À medida que você ganha mais confiança na nova versão, pode começar a distribuí-la para mais servidores em sua infraestrutura e rotear mais usuários para ela.

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

A estratégia canário para Kuberenetes implantará primeiro as alterações com 10% de pods seguidos por 20% enquanto monitora a integridade durante postRouteTraffic. Se tudo correr bem, promoverá para 100%.

Estamos procurando comentários antecipados sobre o suporte para o recurso de VM em ambientes e a execução da estratégia de implantação sem interrupção em vários computadores. Entre em contato conosco para se inscrever.

Políticas de aprovação para pipelines YAML

Em pipelines YAML, seguimos uma configuração de aprovação controlada pelo proprietário do recurso. Os proprietários de recursos configuram aprovações no recurso e em todos os pipelines que usam a pausa de recursos para aprovações antes do início do estágio que consome o recurso. É comum que os proprietários de aplicativos baseados em SOX restrinjam que o solicitante da implantação aprove suas próprias implantações.

Agora você pode usar opções avançadas de aprovação para configurar políticas de aprovação, como o solicitante não deve aprovar, exigir aprovação de um subconjunto de usuários e tempo limite de aprovação.

ACR como um recurso de pipeline de primeira classe

Se você precisar consumir uma imagem de contêiner publicada no ACR (Registro de Contêiner do Azure) como parte do pipeline e disparar o pipeline sempre que uma nova imagem for publicada, você poderá usar o recurso de contêiner do ACR.

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

Além disso, os metadados de imagem do ACR podem ser acessados usando variáveis predefinidas. A lista a seguir inclui as variáveis do ACR disponíveis para definir um recurso de contêiner do ACR em seu pipeline.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Aprimoramentos para avaliar a política de verificação de artefatos em pipelines

Aprimoramos o artefato de avaliação marcar para facilitar a adição de políticas de uma lista de definições de política prontas para uso. A definição de política será gerada automaticamente e adicionada à configuração de marcar que pode ser atualizada, se necessário.

Suporte para variáveis de saída em um trabalho de implantação

Agora você pode definir variáveis de saída nos ganchos de ciclo de vida de um trabalho de implantação e consumi-las em outras etapas downstream e trabalhos dentro do mesmo estágio.

Ao executar estratégias de implantação, você pode acessar variáveis de saída entre trabalhos usando a sintaxe a seguir.

• Para a estratégia runOnce : $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para estratégia canary: $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para a estratégia sem interrupção : $[dependencies.<job-name>.outputs['<lifecycle-hookname>_<resource-name>.<step-name>.<variable-name>']]

// Set an output variable in a lifecycle hook of a deployment job executing canary strategy
- deployment: A
  pool:
    vmImage: 'ubuntu-16.04'
  environment: staging
  strategy:                  
    canary:      
      increments: [10,20]  # creates multiple jobs, one for each increment. Output variable can be referenced with this.
      deploy:
        steps:
        - script: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - script: echo $(setvarStep.myOutputVar)
          name: echovar

 // Map the variable from the job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-16.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['deploy_10.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromDeploymentJob)"
    name: echovar

Saiba mais sobre como definir uma variável de saída de vários trabalhos

Evitar a reversão de alterações críticas

Em pipelines de lançamento clássicos, é comum depender de implantações agendadas para atualizações regulares. Mas, quando você tem uma correção crítica, pode optar por iniciar uma implantação manual fora de banda. Ao fazer isso, as versões mais antigas continuam sendo agendadas. Isso representava um desafio, pois a implantação manual seria revertida quando as implantações fossem retomadas de acordo com o agendamento. Muitos de vocês relataram esse problema e agora o corrigimos. Com a correção, todas as implantações agendadas mais antigas no ambiente seriam canceladas quando você iniciasse manualmente uma implantação. Isso só é aplicável quando a opção de enfileiramento é selecionada como "Implantar mais recente e cancelar outras pessoas".

Autorização simplificada de recursos em pipelines YAML

Um recurso é qualquer coisa usada por um pipeline que está fora do pipeline. Os recursos devem ser autorizados para que possam ser usados. Anteriormente, ao usar recursos não autorizados em um pipeline YAML, ele falhava com um erro de autorização de recurso. Você precisava autorizar os recursos na página de resumo da execução com falha. Além disso, o pipeline falhou se estava usando uma variável que fazia referência a um recurso não autorizado.

Agora estamos facilitando o gerenciamento de autorizações de recursos. Em vez de falhar na execução, a execução aguardará permissões nos recursos no início da fase que consome o recurso. Um proprietário de recurso pode exibir o pipeline e autorizar o recurso na página Segurança.

Avaliar marcar de artefato

Agora você pode definir um conjunto de políticas e adicionar a avaliação de política como um marcar em um ambiente para artefatos de imagem de contêiner. Quando um pipeline é executado, a execução é pausada antes de iniciar um estágio que usa o ambiente. A política especificada é avaliada em relação aos metadados disponíveis para a imagem que está sendo implantada. A marcar é aprovada quando a política é bem-sucedida e marca o estágio como com falha se o marcar falhar.

Atualizações à tarefa de implantação de modelo do ARM

Anteriormente, não filtramos as conexões de serviço na tarefa de implantação do modelo do ARM. Isso poderá fazer com que a implantação falhe se você estiver selecionando uma conexão de serviço de escopo inferior para executar implantações de modelo do ARM em um escopo mais amplo. Agora, adicionamos a filtragem de conexões de serviço para filtrar conexões de serviço com escopo inferior com base no escopo de implantação escolhido.

ReviewApp in Environment

O ReviewApp implanta cada solicitação de pull do repositório Git em um recurso de ambiente dinâmico. Os revisores podem ver a aparência dessas alterações, bem como trabalhar com outros serviços dependentes antes de serem mescladas no branch main e implantadas em produção. Isso facilitará a criação e o gerenciamento de recursos de reviewApp e se beneficiará de todos os recursos de rastreamento e diagnóstico dos recursos de ambiente. Usando o reviewApp palavra-chave, você pode criar um clone de um recurso (criar dinamicamente um novo recurso com base em um recurso existente em um ambiente) e adicionar o novo recurso ao ambiente.

Veja a seguir um snippet yaml de exemplo de uso de reviewApp em ambientes.

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MasterNamespace

Coletar metadados automáticos e especificados pelo usuário do pipeline

Agora você pode habilitar a coleta de metadados automática e especificada pelo usuário de tarefas de pipeline. Você pode usar metadados para impor a política de artefato em um ambiente usando o artefato de avaliação marcar.

Implantações de VM com ambientes

Um dos recursos mais solicitados em Ambientes foram as implantações de VM. Com essa atualização, estamos habilitando o recurso de Máquina Virtual em Ambientes. Agora você pode orquestrar implantações em vários computadores e executar atualizações sem interrupção usando pipelines YAML. Você também pode instalar o agente em cada um dos servidores de destino diretamente e conduzir a implantação sem interrupção para esses servidores. Além disso, você pode usar o catálogo de tarefas completo em seus computadores de destino.

Uma implantação sem interrupção substitui instâncias da versão anterior de um aplicativo por instâncias da nova versão do aplicativo em um conjunto de computadores (conjunto sem interrupção) em cada iteração.

Por exemplo, a implantação sem interrupção abaixo atualiza até cinco destinos em cada iteração. maxParallel determinará o número de destinos que podem ser implantados em paralelo. A seleção é responsável pelo número de destinos que devem permanecer disponíveis a qualquer momento, excluindo os destinos que estão sendo implantados. Ele também é usado para determinar as condições de êxito e falha durante a implantação.

jobs:
- deployment:
  displayName: web
  environment:
    name: musicCarnivalProd
    resourceType: VirtualMachine
  strategy:                 
    rolling:
      maxParallel: 5 #for percentages, mention as x%
      preDeploy:
        steps:
        - script: echo initialize, cleanup, backup, install certs...
      deploy:              
        steps:                                     
        - script: echo deploy ...      
      routeTraffic:
        steps:
        - script: echo routing traffic...   
      postRouteTaffic:
        steps:          
        - script: echo health check post routing traffic...  
      on:
        failure:
          steps:
          - script: echo restore from backup ..     
        success:
          steps:
          - script: echo notify passed...

Observação

Com essa atualização, todos os artefatos disponíveis do pipeline atual e dos recursos de pipeline associados são baixados apenas no deploy gancho de ciclo de vida. No entanto, você pode optar por baixar especificando a tarefa Baixar Artefato do Pipeline. Há algumas lacunas conhecidas nesse recurso. Por exemplo, quando você tentar novamente uma fase, ele executará novamente a implantação em todas as VMs, não apenas em destinos com falha. Estamos trabalhando para fechar essas lacunas em atualizações futuras.

Controle adicional de suas implantações

O Azure Pipelines dá suporte a implantações controladas com aprovações manuais há algum tempo. Com os aprimoramentos mais recentes, agora você tem controle adicional sobre suas implantações. Além das aprovações, os proprietários de recursos agora podem adicionar automatizado checks para verificar políticas de segurança e qualidade. Essas verificações podem ser usadas para disparar operações e, em seguida, aguardar a conclusão delas. Usando as verificações adicionais, agora você pode definir critérios de integridade com base em várias fontes e ter certeza de que todas as implantações direcionadas aos seus recursos são seguras, independentemente do pipeline YAML que executa a implantação. A avaliação de cada marcar pode ser repetida periodicamente com base no Intervalo de Repetição especificado para o marcar. As seguintes verificações adicionais agora estão disponíveis:

• Invocar qualquer API REST e executar a validação com base no corpo da resposta ou em um retorno de chamada do serviço externo
• Invocar uma função do Azure e executar a validação com base na resposta ou em um retorno de chamada da função
• Consultar regras do Azure Monitor para alertas ativos
• Verifique se o pipeline estende um ou mais modelos YAML

Notificação de aprovação

Quando você adiciona uma aprovação a um ambiente ou a uma conexão de serviço, todos os pipelines de vários estágios que usam o recurso aguardam automaticamente a aprovação no início do estágio. Os aprovadores designados precisam concluir a aprovação antes que o pipeline possa continuar.

Com essa atualização, os aprovadores recebem uma notificação por email para a aprovação pendente. Os usuários e proprietários da equipe podem recusar ou definir assinaturas personalizadas usando configurações de notificação.

Configurar estratégias de implantação de portal do Azure

Com essa funcionalidade, facilitamos a configuração de pipelines que usam a estratégia de implantação de sua escolha, por exemplo, Rolling, Canary ou Blue-Green. Usando essas estratégias prontas para uso, você pode distribuir atualizações de maneira segura e atenuar os riscos de implantação associados. Para acessá-lo, clique na configuração "Entrega Contínua" em uma Máquina Virtual do Azure. No painel de configuração, você será solicitado a selecionar detalhes sobre o projeto do Azure DevOps em que o pipeline será criado, o grupo de implantação, o pipeline de build que publica o pacote a ser implantado e a estratégia de implantação de sua escolha. Em seguida, configurará um pipeline totalmente funcional que implanta o pacote selecionado nesta Máquina Virtual.

Para obter mais detalhes, marcar nossa documentação sobre como configurar estratégias de implantação.

Parâmetros de runtime

Os parâmetros de runtime permitem que você tenha mais controle sobre quais valores podem ser passados para um pipeline. Ao contrário das variáveis, os parâmetros de runtime têm tipos de dados e não se tornam automaticamente variáveis de ambiente. Com parâmetros de runtime, você pode:

• Fornecer valores diferentes para scripts e tarefas em runtime
• Tipos de parâmetro de controle, intervalos permitidos e padrões
• Selecionar dinamicamente trabalhos e estágios com a expressão de modelo

Para saber mais sobre parâmetros de runtime, consulte a documentação aqui.

O uso estende palavra-chave em pipelines

Atualmente, os pipelines podem ser fatorados em modelos, promovendo a reutilização e reduzindo o texto clichê. A estrutura geral do pipeline ainda foi definida pelo arquivo YAML raiz. Com essa atualização, adicionamos uma maneira mais estruturada de usar modelos de pipeline. Um arquivo YAML raiz agora pode usar o palavra-chave estende para indicar que a estrutura do pipeline main pode ser encontrada em outro arquivo. Isso coloca você no controle de quais segmentos podem ser estendidos ou alterados e quais segmentos são fixos. Também aprimoramos os parâmetros de pipeline com tipos de dados para deixar claro os ganchos que você pode fornecer.

Este exemplo ilustra como você pode fornecer ganchos simples para o autor do pipeline usar. O modelo sempre executará um build, executará opcionalmente etapas adicionais fornecidas pelo pipeline e, em seguida, executará uma etapa de teste opcional.

# azure-pipelines.yml
extends:
  template: build-template.yml
  parameters:
    runTests: true
    postBuildSteps:
    - script: echo This step runs after the build!
    - script: echo This step does too!

# build-template.yml
parameters:
- name: runTests
  type: boolean
  default: false
- name: postBuildSteps
  type: stepList
  default: []
steps:
- task: MSBuild@1   # this task always runs
- ${{ if eq(parameters.runTests, true) }}:
  - task: VSTest@2  # this task is injected only when runTests is true
- ${{ each step in parameters.postBuildSteps }}:
  - ${{ step }}

Controlar variáveis que podem ser substituídas no momento da fila

Anteriormente, você podia usar a interface do usuário ou a API REST para atualizar os valores de qualquer variável antes de iniciar uma nova execução. Embora o autor do pipeline possa marcar determinadas variáveis como _settable at queue time_, o sistema não imponha isso nem impediu que outras variáveis fossem definidas. Em outras palavras, a configuração só foi usada para solicitar entradas adicionais ao iniciar uma nova execução.

Adicionamos uma nova configuração de coleção que impõe o _settable at queue time_ parâmetro . Isso lhe dará controle sobre quais variáveis podem ser alteradas ao iniciar uma nova execução. Daqui para frente, você não pode alterar uma variável que não está marcada pelo autor como _settable at queue time_.

Observação

Essa configuração está desativada por padrão em coleções existentes, mas estará ativada por padrão quando você criar uma nova coleção do Azure DevOps.

Novas variáveis predefinidas no pipeline YAML

As variáveis oferecem uma forma conveniente de inserir os principais bits de dados em várias partes do pipeline. Com essa atualização, adicionamos algumas variáveis predefinidas a um trabalho de implantação. Essas variáveis são definidas automaticamente pelo sistema, com escopo para o trabalho de implantação específico e são somente leitura.

• Environment.Id – a ID do ambiente.
• Environment.Name – o nome do ambiente direcionado pelo trabalho de implantação.
• Environment.ResourceId - A ID do recurso no ambiente direcionado pelo trabalho de implantação.
• Environment.ResourceName - O nome do recurso no ambiente direcionado pelo trabalho de implantação.

Fazer check-out de vários repositórios

Os pipelines geralmente dependem de vários repositórios. Você pode ter repositórios diferentes com origem, ferramentas, scripts ou outros itens necessários para criar seu código. Anteriormente, você precisava adicionar esses repositórios como submódulos ou como scripts manuais para executar o check-out do Git. Agora você pode buscar e marcar outros repositórios, além do que você usa para armazenar seu pipeline YAML.

Por exemplo, se você tiver um repositório chamado MyCode com um pipeline YAML e um segundo repositório chamado Ferramentas, seu pipeline YAML terá esta aparência:

resources:
  repositories:
  - repository: tools
    name: Tools
    type: git

steps:
- checkout: self
- checkout: tools
- script: dir $(Build.SourcesDirectory)

A terceira etapa mostrará dois diretórios, MyCode e Tools no diretório de fontes.

Azure Repos repositórios Git são compatíveis. Para obter mais informações, confira Check-out de vários repositórios.

Obter detalhes em runtime sobre vários repositórios

Quando um pipeline está em execução, o Azure Pipelines adiciona informações sobre o repositório, o branch e a confirmação que dispararam a execução. Agora que os pipelines YAML dão suporte à verificação de vários repositórios, talvez você também queira saber o repositório, o branch e o commit que foram verificados para outros repositórios. Esses dados estão disponíveis por meio de uma expressão de runtime, que agora você pode mapear para uma variável. Por exemplo:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: echo "Tools version: $TOOLS_REF"

Permitir referências de repositório a outras coleções Azure Repos

Anteriormente, quando você fazia referência a repositórios em um pipeline YAML, todos os repositórios Azure Repos tinham que estar na mesma coleção que o pipeline. Agora, você pode apontar para repositórios em outras coleções usando uma conexão de serviço. Por exemplo:

resources:
  repositories:
  - repository: otherrepo
    name: ProjectName/RepoName
    endpoint: MyServiceConnection
steps:
- checkout: self
- checkout: otherrepo

MyServiceConnection aponta para outra coleção do Azure DevOps e tem credenciais que podem acessar o repositório em outro projeto. Ambos os repositórios, self e otherrepo, acabarão com check-out.

Importante

MyServiceConnectiondeve ser uma conexão de serviço Azure Repos/Team Foundation Server, consulte a imagem abaixo.

Metadados de recursos de pipeline como variáveis predefinidas

Adicionamos variáveis predefinidas para recursos de pipelines YAML no pipeline. Aqui está a lista das variáveis de recurso de pipeline disponíveis.

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

kustomize e kompose como opções de bake na tarefa KubernetesManifest

kustomize (parte da sig-cli do Kubernetes) permite personalizar arquivos YAML brutos e sem modelos para várias finalidades e deixa o YAML original inalterado. Uma opção para kustomize foi adicionada na ação bake da tarefa KubernetesManifest para que qualquer pasta que contenha arquivos kustomization.yaml possa ser usada para gerar os arquivos de manifesto usados na ação de implantação da tarefa KubernetesManifest.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose transformará arquivos do Docker Compose em um recurso do Kubernetes.

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

Suporte para credenciais de administrador de cluster na tarefa HelmDeploy

Anteriormente, a tarefa HelmDeploy usava as credenciais do usuário do cluster para implantações. Isso resultou em prompts de logon interativos e pipelines com falha para um cluster habilitado para RBAC baseado no Azure Active Directory. Para resolver esse problema, adicionamos uma caixa de seleção que permite usar credenciais de administrador de cluster em vez de credenciais de usuário de cluster.

Entrada de argumentos na tarefa Docker Compose

Um novo campo foi introduzido na tarefa Docker Compose para permitir que você adicione argumentos como --no-cache. O argumento será passado para baixo pela tarefa ao executar comandos como build.

Aprimoramentos da tarefa de versão do GitHub

Fizemos vários aprimoramentos na tarefa Versão do GitHub. Agora você pode ter um melhor controle sobre a criação de versão usando o campo padrão de marca especificando uma expressão regular de marca e a versão será criada somente quando a confirmação de gatilho for marcada com uma cadeia de caracteres correspondente.

Também adicionamos recursos para personalizar a criação e a formatação do changelog. Na nova seção para configuração do changelog, agora você pode especificar a versão na qual a versão atual deve ser comparada. A versão Comparar com pode ser a última versão completa (exclui pré-lançamentos), última versão não rascunho ou qualquer versão anterior que corresponda à marca de versão fornecida. Além disso, a tarefa fornece o campo de tipo changelog para formatar a lista de alterações. Com base na seleção, o changelog exibirá uma lista de commits ou uma lista de problemas/PRs categorizados com base em rótulos.

Tarefa do instalador do Open Policy Agent

O Open Policy Agent é um mecanismo de política de uso geral código aberto que permite a imposição de política unificada e com reconhecimento de contexto. Adicionamos a tarefa do instalador do Open Policy Agent. É particularmente útil para a imposição de políticas no pipeline em relação à Infraestrutura como provedores de código.

Por exemplo, o Open Policy Agent pode avaliar os arquivos de política do Rego e os planos do Terraform no pipeline.

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

Suporte para scripts do PowerShell na tarefa da CLI do Azure

Anteriormente, você podia executar scripts de lote e bash como parte de uma tarefa da CLI do Azure. Com essa atualização, adicionamos suporte para scripts principais do PowerShell e do PowerShell à tarefa.

Implantações canárias baseadas na Interface de Malha de Serviço na tarefa KubernetesManifest

Anteriormente, quando a estratégia canário era especificada na tarefa KubernetesManifest, a tarefa criava cargas de trabalho de linha de base e canário cujas réplicas eram iguais a uma porcentagem das réplicas usadas para cargas de trabalho estáveis. Isso não foi exatamente o mesmo que dividir o tráfego até a porcentagem desejada no nível da solicitação. Para resolver isso, adicionamos suporte para implantações canárias baseadas em Interface de Malha de Serviço à tarefa KubernetesManifest.

A abstração da Interface de Malha de Serviço permite a configuração de plug-and-play com provedores de malha de serviço, como Linkerd e Istio. Agora, a tarefa KubernetesManifest tira o trabalho árduo de mapear objetos TrafficSplit do SMI para os serviços estáveis, de linha de base e canário durante o ciclo de vida da estratégia de implantação. A divisão percentual desejada do tráfego entre estável, linha de base e canário é mais precisa, pois a divisão de tráfego percentual é controlada nas solicitações no plano de malha de serviço.

Veja a seguir um exemplo de execução de implantações canárias baseadas em SMI de maneira contínua.

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

A Tarefa de Cópia de Arquivo do Azure agora dá suporte ao AzCopy V10

A tarefa de cópia de arquivo do Azure pode ser usada em um pipeline de build ou lançamento para copiar arquivos para blobs de armazenamento da Microsoft ou VMs (máquinas virtuais). A tarefa usa o AzCopy, o build do utilitário de linha de comando para cópia rápida de dados de e para contas de armazenamento do Azure. Com essa atualização, adicionamos suporte para o AzCopy V10, que é a versão mais recente do AzCopy.

O azcopy copy comando dá suporte apenas aos argumentos associados a ele. Devido à alteração na sintaxe do AzCopy, alguns dos recursos existentes não estão disponíveis no AzCopy V10. Estão incluídos:

• Especificando o local do log
• Limpar arquivos de log e plano após a cópia
• Retomar cópia se o trabalho falhar

Os recursos adicionais com suporte nesta versão da tarefa são:

• Símbolos curinga no nome/caminho do arquivo da origem
• Inferindo o tipo de conteúdo com base na extensão de arquivo quando nenhum argumento é fornecido
• Definindo a verbosidade de log para o arquivo de log passando um argumento

Melhorar a segurança do pipeline restringindo o escopo dos tokens de acesso

Cada trabalho executado no Azure Pipelines obtém um token de acesso. O token de acesso é usado pelas tarefas e pelos scripts para chamar de volta para o Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, carregar logs, resultados de teste, artefatos ou fazer chamadas REST no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído. Com essa atualização, adicionamos os seguintes aprimoramentos.

• Impedir que o token acesse recursos fora de um projeto de equipe

  Até agora, o escopo padrão de todos os pipelines era a coleção de projetos de equipe. Você pode alterar o escopo para ser o projeto de equipe em pipelines de build clássicos. No entanto, você não tinha esse controle para a versão clássica ou pipelines YAML. Com essa atualização, estamos introduzindo uma configuração de coleção para forçar cada trabalho a obter um token no escopo do projeto, independentemente do que esteja configurado no pipeline. Também adicionamos a configuração no nível do projeto. Agora, cada novo projeto e coleção que você criar terá essa configuração ativada automaticamente.

  Observação

  A configuração da coleção substitui a configuração do projeto.

  Ativar essa configuração em projetos e coleções existentes pode fazer com que determinados pipelines falhem se os pipelines acessarem recursos que estão fora do projeto de equipe usando tokens de acesso. Para atenuar falhas de pipeline, você pode conceder explicitamente acesso à Conta de Serviço de Build do Project para o recurso desejado. É altamente recomendável que você ative essas configurações de segurança.

• Limitar o acesso ao escopo do serviço de build

  Com base na melhoria da segurança do pipeline restringindo o escopo do token de acesso, o Azure Pipelines agora pode definir o escopo do acesso ao repositório apenas para os repositórios necessários para um pipeline baseado em YAML. Isso significa que, se o token de acesso dos pipelines vazasse, ele só seria capaz de ver os repositórios usados no pipeline. Anteriormente, o token de acesso era bom para qualquer Azure Repos repositório no projeto ou potencialmente para toda a coleção.

  Esse recurso estará ativado por padrão para novos projetos e coleções. Para coleções existentes, você deve habilitá-la nasConfigurações>de ColeçõesConfiguraçõesdePipelines>. Ao usar esse recurso, todos os repositórios necessários para o build (mesmo aqueles que você clona usando um script) devem ser incluídos nos recursos do repositório do pipeline.

• Remover determinadas permissões para o token de acesso

  Por padrão, concedemos várias permissões ao token de acesso, uma destas permissões é Compilações de fila. Com essa atualização, removemos essa permissão para o token de acesso. Se os pipelines precisarem dessa permissão, você poderá concedê-la explicitamente à Conta de Serviço de Build do Projeto ou à Conta de Serviço de Build de Coleção de Projetos , dependendo do token usado.

Segurança no nível do projeto para conexões de serviço

Adicionamos segurança no nível do hub para conexões de serviço. Agora, você pode adicionar/remover usuários, atribuir funções e gerenciar o acesso em um local centralizado para todas as conexões de serviço.

Direcionamento de etapas e isolamento de comando

O Azure Pipelines dá suporte à execução de trabalhos em contêineres ou no host do agente. Anteriormente, um trabalho inteiro era definido como um desses dois destinos. Agora, as etapas individuais (tarefas ou scripts) podem ser executadas no destino escolhido. As etapas também podem ser direcionadas a outros contêineres, para que um pipeline possa executar cada etapa em um contêiner especializado e criado com finalidade.

Os contêineres podem agir como limites de isolamento, impedindo que o código faça alterações inesperadas no computador host. A maneira como as etapas se comunicam com os serviços de acesso e do agente não é afetada pela isolação de etapas em um contêiner. Portanto, também estamos introduzindo um modo de restrição de comando que você pode usar com destinos de etapa. Ativar isso restringirá os serviços que uma etapa pode solicitar do agente. Ele não poderá mais anexar logs, carregar artefatos e determinadas outras operações.

Aqui está um exemplo abrangente, mostrando etapas de execução no host em um contêiner de trabalho e em outro contêiner:

resources:
  containers:
  - container: python
    image: python:3.8
  - container: node
    image: node:13.2

jobs:
- job: example
  container: python

  steps:
  - script: echo Running in the job container

  - script: echo Running on the host
    target: host

  - script: echo Running in another container, in restricted commands mode
    target:
      container: node
      commands: restricted

Variáveis somente leitura

As variáveis do sistema foram documentadas como imutáveis, mas, na prática, elas poderiam ser substituídas por uma tarefa e as tarefas downstream captariam o novo valor. Com essa atualização, reforçamos a segurança em torno de variáveis de pipeline para tornar as variáveis de tempo de fila e sistema somente leitura. Além disso, você pode criar uma variável YAML somente leitura marcando-a da seguinte maneira.

variables:
- name: myVar
  value: myValue
  readonly: true

Acesso baseado em função para conexões de serviço

Adicionamos acesso baseado em função para conexões de serviço. Anteriormente, a segurança de conexão de serviço só podia ser gerenciada por meio de grupos predefinidos do Azure DevOps, como administradores de ponto de extremidade e Criadores de ponto de extremidade.

Como parte deste trabalho, apresentamos as novas funções de Leitor, Usuário, Criador e Administrador. Você pode definir essas funções por meio da página de conexões de serviço em seu projeto e elas são herdadas pelas conexões individuais. E em cada conexão de serviço você tem a opção de ativar ou desativar a herança e substituir as funções no escopo da conexão de serviço.

Saiba mais sobre a segurança de conexões de serviço aqui.

Compartilhamento entre projetos de conexões de serviço

Habilitamos o suporte para compartilhamento de conexão de serviço entre projetos. Agora você pode compartilhar suas conexões de serviço com seus projetos com segurança e segurança.

Saiba mais sobre o compartilhamento de conexões de serviço aqui.

Rastreabilidade de pipelines e recursos do ACR

Garantimos a rastreabilidade completa do E2E quando pipelines e recursos de contêiner do ACR são usados em um pipeline. Para cada recurso consumido pelo pipeline yaml, você pode rastrear de volta para confirmações, itens de trabalho e artefatos.

Na exibição de resumo da execução do pipeline, você pode ver:

• A versão do recurso que disparou a execução. Agora, seu pipeline pode ser disparado após a conclusão de outra execução de pipeline do Azure ou quando uma imagem de contêiner é enviada por push para o ACR.

  

• Os commits que são consumidos pelo pipeline. Você também pode encontrar o detalhamento das confirmações por cada recurso consumido pelo pipeline.

  

• Os itens de trabalho associados a cada recurso consumido pelo pipeline.

• Os artefatos que estão disponíveis para serem usados pela execução.

  

Na exibição de implantações do ambiente, você pode ver os commits e os itens de trabalho de cada recurso implantado no ambiente.

Suporte para anexos de teste grandes

A tarefa publicar resultados de teste no Azure Pipelines permite publicar resultados de teste quando os testes são executados para fornecer uma experiência abrangente de análise e relatórios de teste. Até agora, havia um limite de 100 MB para anexos de teste para resultados de teste e execução de teste. Isso limitou o upload de arquivos grandes, como despejos de memória ou vídeos. Com essa atualização, adicionamos suporte para anexos de teste grandes, permitindo que você tenha todos os dados disponíveis para solucionar problemas de testes com falha.

Você pode ver a tarefa VSTest ou a tarefa Publicar resultados de teste retornando um erro 403 ou 407 nos logs. Se você estiver usando builds auto-hospedados ou agentes de versão por trás de um firewall que filtra solicitações de saída, será necessário fazer algumas alterações de configuração para poder usar essa funcionalidade. ​

Para corrigir esse problema, recomendamos que você atualize o firewall para solicitações de saída para https://*.vstmrblob.vsassets.io. Você pode encontrar informações de solução de problemas na documentação aqui. ​

Observação

Isso só será necessário se você estiver usando agentes auto-hospedados do Azure Pipelines e estiver atrás de um firewall que esteja filtrando o tráfego de saída. Se você estiver usando agentes hospedados pela Microsoft na nuvem ou que não estão filtrando o tráfego de rede de saída, não será necessário executar nenhuma ação.

Mostrar informações corretas do pool em cada trabalho

Anteriormente, quando você usava uma matriz para expandir trabalhos ou uma variável para identificar um pool, às vezes resolvemos informações incorretas do pool nas páginas de logs. Esses problemas foram resolvidos.

Gatilhos de CI para novos branches

Foi uma solicitação pendente longa para não disparar builds de CI quando um novo branch é criado e quando esse branch não tem alterações. Considere os seguintes exemplos:

• Você usa a interface da Web para criar um novo branch com base em um branch existente. Isso disparará imediatamente um novo build de CI se o filtro de branch corresponder ao nome do novo branch. Isso é indesejado porque o conteúdo do novo branch é o mesmo quando comparado com o branch existente.
• Você tem um repositório com duas pastas : aplicativo e documentos. Configure um filtro de caminho para a CI corresponder ao "aplicativo". Em outras palavras, você não deseja criar um novo build se uma alteração tiver sido enviada por push para documentos. Você cria um branch localmente, faz algumas alterações nos documentos e, em seguida, envia esse branch por push para o servidor. Usamos para disparar um novo build de CI. Isso é indesejado, pois você pediu explicitamente para não procurar alterações na pasta docs. No entanto, devido à maneira como lidamos com um novo evento de branch, parece que uma alteração também foi feita na pasta do aplicativo.

Agora, temos uma maneira melhor de lidar com a CI para novos branches para resolver esses problemas. Quando você publica um novo branch, procuramos explicitamente novos commits nesse branch e marcar se eles correspondem aos filtros de caminho.

Os trabalhos podem acessar variáveis de saída de estágios anteriores

As variáveis de saída agora podem ser usadas entre estágios em um pipeline baseado em YAML. Isso ajuda você a passar informações úteis, como uma decisão de ir/não-ir ou a ID de uma saída gerada, de um estágio para o outro. O resultado (status) de um estágio anterior e seus trabalhos também estão disponíveis.

As variáveis de saída ainda são produzidas por etapas dentro de trabalhos. Em vez de fazer referência a dependencies.jobName.outputs['stepName.variableName'], os estágios referem-se a stageDependencies.stageName.jobName.outputs['stepName.variableName'].

Observação

Por padrão, cada fase em um pipeline depende daquele imediatamente anterior a ele no arquivo YAML. Portanto, cada fase pode usar variáveis de saída da fase anterior. Você pode alterar a grafo de dependência, que também alterará quais variáveis de saída estão disponíveis. Por exemplo, se a fase 3 precisar de uma variável do estágio 1, ela precisará declarar uma dependência explícita no estágio 1.

Desabilitar atualizações automáticas de agentes em um nível de pool

Atualmente, os agentes de pipelines serão atualizados automaticamente para a versão mais recente quando necessário. Isso normalmente acontece quando há um novo recurso ou tarefa que exige que uma versão mais recente do agente funcione corretamente. Com essa atualização, estamos adicionando a capacidade de desabilitar atualizações automáticas em um nível de pool. Nesse modo, se nenhum agente da versão correta estiver conectado ao pool, os pipelines falharão com uma mensagem de erro clara em vez de solicitar que os agentes sejam atualizados. Esse recurso é principalmente de interesse para clientes com pools auto-hospedados e requisitos muito rígidos de controle de alterações. As atualizações automáticas são habilitadas por padrão e não recomendamos que a maioria dos clientes as desabilite.

Diagnóstico do agente

Adicionamos diagnóstico para muitos problemas comuns relacionados ao agente, como muitos problemas de rede e causas comuns de falhas de atualização. Para começar a usar diagnóstico, use run.sh --diagnóstico ou run.cmd --diagnóstico no Windows.

Ganchos de serviço para pipelines YAML

A integração de serviços com pipelines YAML ficou mais fácil. Usando eventos de ganchos de serviço para pipelines YAML, agora você pode conduzir atividades em aplicativos ou serviços personalizados com base no progresso das execuções de pipeline. Por exemplo, você pode criar um tíquete de assistência técnica quando uma aprovação for necessária, iniciar um fluxo de trabalho de monitoramento após a conclusão de um estágio ou enviar uma notificação por push para os dispositivos móveis da sua equipe quando uma fase falhar.

Há suporte para filtragem no nome do pipeline e no nome do estágio para todos os eventos. Os eventos de aprovação também podem ser filtrados para ambientes específicos. Da mesma forma, os eventos de alteração de estado podem ser filtrados pelo novo estado da execução do pipeline ou do estágio.

Integração otimizada

Optimizely é uma plataforma avançada de sinalização de recursos e testes A/B para equipes de produtos. A integração do Azure Pipelines com a plataforma de experimentação Optimizely capacita as equipes de produtos a testar, aprender e implantar em um ritmo acelerado, ao mesmo tempo em que obtém todos os benefícios do DevOps do Azure Pipelines.

A extensão Optimizely para Azure DevOps adiciona etapas de distribuição de sinalizador de experimentação e recurso aos pipelines de build e lançamento, para que você possa iterar, distribuir recursos continuamente e revertê-los usando o Azure Pipelines.

Saiba mais sobre a extensão do Azure DevOps Optimizely aqui.

Adicionar uma versão do GitHub como uma fonte de artefato

Agora você pode vincular suas versões do GitHub como fonte de artefato em pipelines de lançamento do Azure DevOps. Isso permitirá que você consuma a versão do GitHub como parte de suas implantações.

Ao clicar em Adicionar um artefato na definição do pipeline de lançamento, você encontrará o novo tipo de origem da Versão do GitHub . Você pode fornecer a conexão de serviço e o repositório GitHub para consumir a versão do GitHub. Você também pode escolher uma versão padrão para a versão do GitHub consumir como versão de marca mais recente e específica ou selecionar no momento da criação do lançamento. Depois que uma versão do GitHub é vinculada, ela é baixada automaticamente e disponibilizada em seus trabalhos de lançamento.

Integração do Terraform com o Azure Pipelines

O Terraform é uma ferramenta de software livre para desenvolvimento, alteração e controle de versão de infraestrutura com segurança e eficiência. O Terraform codifica APIs em arquivos de configuração declarativos, permitindo que você defina e provisione a infraestrutura usando uma linguagem de configuração de alto nível. Você pode usar a extensão terraform para criar recursos em todos os principais provedores de infraestrutura: Azure, AWS (Amazon Web Services) e GCP (Google Cloud Platform).

Para saber mais sobre a extensão do Terraform, confira a documentação aqui.

Integração com o Google Analytics

A estrutura de experimentos do Google Analytics permite que você teste quase qualquer alteração ou variação em um site ou aplicativo para medir seu impacto em um objetivo específico. Por exemplo, você pode ter atividades que deseja que seus usuários concluam (por exemplo, fazer uma compra, inscrever-se em um boletim informativo) e/ou métricas que deseja melhorar (por exemplo, receita, duração da sessão, taxa de salto). Essas atividades permitem identificar as alterações que valem a pena implementar com base no impacto direto que elas têm no desempenho do seu recurso.

A extensão de experimentos do Google Analytics para o Azure DevOps adiciona etapas de experimentação aos pipelines de build e lançamento, para que você possa iterar, aprender e implantar continuamente em um ritmo acelerado gerenciando os experimentos continuamente, obtendo todos os benefícios do DevOps do Azure Pipelines.

Você pode baixar a extensão de experimentos do Google Analytics do Marketplace.

Integração atualizada do ServiceNow com o Azure Pipelines

O aplicativo Azure Pipelines para ServiceNow ajuda a integrar o Azure Pipelines e o ServiceNow Change Management. Com essa atualização, você pode se integrar à versão nova-iorquina do ServiceNow. A autenticação entre os dois serviços agora pode ser feita usando o OAuth e a autenticação básica. Além disso, agora você pode configurar critérios avançados de êxito para poder usar qualquer propriedade de alteração para decidir o resultado do portão.

Criar o Azure Pipelines do VSCode

Adicionamos uma nova funcionalidade à extensão do Azure Pipelines para VSCode. Agora, você poderá criar o Azure Pipelines diretamente do VSCode sem sair do IDE.

Gerenciamento e resolução de bugs irregulares

Introduzimos o gerenciamento de testes insumos para dar suporte ao ciclo de vida de ponta a ponta com detecção, relatórios e resolução. Para aprimorá-lo ainda mais, estamos adicionando gerenciamento e resolução de bugs de teste insumos.

Ao investigar o teste inscrito, você pode criar um bug usando a ação Bug , que pode ser atribuída a um desenvolvedor para investigar ainda mais a causa raiz do teste de problemas. O relatório de bugs inclui informações sobre o pipeline, como mensagem de erro, rastreamento de pilha e outras informações associadas ao teste.

Quando um relatório de bugs for resolvido ou fechado, desmarcaremos automaticamente o teste como unflaky.

Definir tarefas VSTest para falhar se um número mínimo de testes não for executado

A tarefa VSTest descobre e executa testes usando entradas de usuário (arquivos de teste, critérios de filtro e assim por diante), bem como um adaptador de teste específico para a estrutura de teste que está sendo usada. As alterações nas entradas do usuário ou no adaptador de teste podem levar a casos em que os testes não são descobertos e apenas um subconjunto dos testes esperados é executado. Isso pode levar a situações em que os pipelines são bem-sucedidos porque os testes são ignorados em vez de porque o código é de alta qualidade suficientemente alta. Para ajudar a evitar essa situação, adicionamos uma nova opção na tarefa VSTest que permite especificar o número mínimo de testes que devem ser executados para a tarefa ser aprovada.

A opção TestResultsDirectory do VSTest está disponível na interface do usuário da tarefa

A tarefa VSTest armazena resultados de teste e arquivos associados na $(Agent.TempDirectory)\TestResults pasta. Adicionamos uma opção à interface do usuário da tarefa para permitir que você configure uma pasta diferente para armazenar os resultados do teste. Agora, todas as tarefas subsequentes que precisam dos arquivos em um local específico podem usá-las.

Suporte ao Markdown em mensagens de erro de teste automatizadas

Adicionamos suporte a markdown a mensagens de erro para testes automatizados. Agora você pode formatar facilmente mensagens de erro para execução de teste e resultado de teste para melhorar a legibilidade e facilitar a experiência de solução de problemas de falha de teste no Azure Pipelines. A sintaxe markdown com suporte pode ser encontrada aqui.

Usar decoradores de pipeline para injetar etapas automaticamente em um trabalho de implantação

Agora você pode adicionar decoradores de pipeline a trabalhos de implantação. Você pode ter qualquer etapa personalizada (por exemplo, verificador de vulnerabilidades) injetada automaticamente em cada execução de gancho de ciclo de vida de cada trabalho de implantação. Como os decoradores de pipeline podem ser aplicados a todos os pipelines em uma coleção, isso pode ser aproveitado como parte da imposição de práticas de implantação seguras.

Além disso, os trabalhos de implantação podem ser executados como um trabalho de contêiner junto com os serviços de sidecar, se definidos.

Test Plans

Página Novo Plano de Teste

Uma nova página de Test Plans (Test Plans *) está disponível para todas as coleções do Azure DevOps. A nova página fornece exibições simplificadas para ajudá-lo a se concentrar na tarefa em questão – planejamento de teste, criação ou execução. Ele também é sem problemas e consistente com o restante da oferta do Azure DevOps.

Ajude-me a entender a nova página

A nova página Test Plans tem um total de 6 seções das quais as quatro primeiras são novas, enquanto as seções Gráficos & Extensibilidade são a funcionalidade existente.

1. Cabeçalho do plano de teste: use isso para localizar, favorito, editar, copiar ou clonar um plano de teste.
2. Árvore de pacotes de teste: use isso para adicionar, gerenciar, exportar ou ordenar pacotes de teste. Aproveite isso para também atribuir configurações e executar testes de aceitação do usuário.
3. Guia Definir: agrupar, adicionar e gerenciar casos de teste em um conjunto de testes de escolha por meio dessa guia.
4. Guia Executar: atribua e execute testes por meio desta guia ou localize um resultado de teste para detalhar.
5. Guia Gráfico: acompanhe a execução do teste e status por meio de gráficos que também podem ser fixados em painéis.
6. Extensibilidade: dá suporte aos pontos de extensibilidade atuais dentro do produto.

Vamos ter uma visão geral dessas novas seções abaixo.

1. Cabeçalho do plano de teste

Tarefas

O cabeçalho plano de teste permite que você execute as seguintes tarefas:

• Marcar um plano de teste como favorito
• Dinamarca um plano de teste favorito
• Navegue facilmente entre seus planos de teste favoritos
• Exibir o caminho de iteração do plano de teste, que indica claramente se o plano de teste é Atual ou Passado
• Exibir o resumo rápido do relatório de Progresso do Teste com um link para navegar até o relatório
• Navegue de volta para a página Todos/Minerar Test Plans

Opções de menu de contexto

O menu de contexto no cabeçalho plano de teste fornece as seguintes opções:

• Plano de teste de cópia: essa é uma nova opção que permite copiar rapidamente o plano de teste atual. Mais detalhes abaixo.
• Editar plano de teste: essa opção permite editar o formulário de item de trabalho do Plano de Teste para gerenciar os campos de item de trabalho.
• Configurações do plano de teste: essa opção permite que você defina as configurações de Execução de Teste (para associar pipelines de build ou lançamento) e as configurações de Resultado do Teste

Copiar plano de teste (nova funcionalidade)

É recomendável criar um novo Plano de Teste por sprint/versão. Ao fazer isso, geralmente, o Plano de Teste para o ciclo anterior pode ser copiado e, com poucas alterações, o plano de teste copiado está pronto para o novo ciclo. Para facilitar esse processo, habilitamos um recurso 'Copiar plano de teste' na nova página. Aproveitando-o, você pode copiar ou clonar planos de teste. Sua API REST de suporte é abordada aqui e a API permite copiar/clonar um plano de teste entre projetos também.
Para obter mais diretrizes sobre Test Plans uso, consulte aqui.

2. Árvore de pacotes de teste

Tarefas

O cabeçalho do conjunto de testes permite que você execute as seguintes tarefas:

• Expandir/recolher: essas opções de barra de ferramentas permitem expandir ou recolher a árvore de hierarquia do pacote.
• Mostrar pontos de teste de pacotes filho: essa opção de barra de ferramentas só fica visível quando você está na guia "Executar". Isso permite que você exiba todos os pontos de teste para o conjunto determinado e seus filhos em uma única exibição para facilitar o gerenciamento de pontos de teste sem precisar navegar para conjuntos individuais um de cada vez.
• Pacotes de pedidos: você pode arrastar/soltar pacotes para reordenar a hierarquia de pacotes ou movê-los de uma hierarquia de pacote para outra dentro do plano de teste.

Opções de menu de contexto

O menu de contexto na árvore Pacotes de teste fornece as seguintes opções:

• Criar novos pacotes: você pode criar três tipos diferentes de pacotes da seguinte maneira:
  • Use o pacote estático ou o pacote de pastas para organizar seus testes.
  • Use o pacote baseado em requisitos para vincular diretamente aos requisitos/histórias do usuário para rastrear perfeitamente.
  • Use baseado em consulta para organizar dinamicamente casos de teste que atendam a critérios de consulta.
• Atribuir configurações: você pode atribuir configurações para o pacote (exemplo: Chrome, Firefox, EdgeChromium) e elas seriam aplicáveis a todos os casos de teste existentes ou novos casos de teste que você adicionar posteriormente a esse pacote.
• Exportar como pdf/email: exporte as propriedades do plano de teste, as propriedades do conjunto de testes, juntamente com os detalhes dos casos de teste e os pontos de teste como "email" ou "imprimir em pdf".
• Abrir item de trabalho do conjunto de testes: essa opção permite editar o formulário de item de trabalho do pacote de testes para gerenciar os campos de item de trabalho.
• Atribuir testadores para executar todos os testes: essa opção é muito útil para cenários de teste de aceitação do usuário (UAT), em que o mesmo teste precisa ser executado/executado por vários testadores, geralmente pertencentes a departamentos diferentes.
• Renomear/Excluir: essas opções permitem que você gerencie o nome do pacote ou remova o pacote e seu conteúdo do plano de teste.

3. Definir guia

A guia Definir permite agrupar, adicionar e gerenciar casos de teste para um conjunto de testes. Enquanto a guia executar é para atribuir pontos de teste e executá-los.

A guia Definir e determinadas operações só estão disponíveis para usuários com o nível de acesso Básico + Test Plans ou equivalente. Todo o resto deve ser exercido por um usuário com nível de acesso "Básico".

Tarefas

A guia Definir permite que você execute as seguintes tarefas:

• Adicionar Novo caso de teste usando o formulário de item de trabalho: essa opção permite que você crie um novo caso de teste usando o formulário de item de trabalho. O caso de teste criado será adicionado automaticamente ao pacote.
• Adicionar Novo caso de teste usando grade: essa opção permite que você crie um ou mais casos de teste usando a exibição de grade de casos de teste. Os casos de teste criados serão adicionados automaticamente ao pacote.
• Adicionar casos de teste existentes usando uma consulta: essa opção permite que você adicione casos de teste existentes ao pacote especificando uma consulta.
• Ordenar casos de teste por arrastar/soltar: você pode reordenar casos de teste arrastando/soltando um ou mais casos de teste dentro de um determinado pacote. A ordem dos casos de teste só se aplica a casos de teste manuais e não a testes automatizados.
• Mover casos de teste de um pacote para outro: usando arrastar/soltar, você pode mover casos de teste de um conjunto de testes para outro.
• Mostrar grade: você pode usar o modo de grade para exibir/editar casos de teste junto com as etapas de teste.
• Exibição em tela inteira: você pode exibir o conteúdo de toda a guia Definir em um modo de tela inteira usando essa opção.
• Filtragem: usando a barra de filtros, você pode filtrar a lista de casos de teste usando os campos "título do caso de teste", "atribuído a" e "estado". Você também pode classificar a lista clicando nos cabeçalhos de coluna.
• Opções de coluna: você pode gerenciar a lista de colunas visíveis na guia Definir usando "Opções de coluna". A lista de colunas disponíveis para seleção são principalmente os campos do formulário de item de trabalho do caso de teste.

Opções de menu de contexto

O menu de contexto no nó Caso de teste na guia Definir fornece as seguintes opções:

• Formulário abrir/editar item de trabalho de caso de teste: essa opção permite editar um caso de teste usando o formulário de item de trabalho no qual você edita os campos de item de trabalho, incluindo etapas de teste.
• Editar casos de teste: essa opção permite editar em massa campos de item de trabalho de caso de teste. No entanto, você não pode usar essa opção para editar etapas de teste em massa.
• Editar casos de teste na grade: essa opção permite editar em massa os casos de teste selecionados, incluindo etapas de teste usando o modo de exibição de grade.
• Atribuir configurações: essa opção permite que você substitua as configurações no nível do pacote por configurações de nível de caso de teste.
• Remover casos de teste: essa opção permite que você remova os casos de teste do pacote especificado. No entanto, ele não altera o item de trabalho de caso de teste subjacente.
• Criar uma cópia/clone de casos de teste: essa opção permite que você crie uma cópia/clone de casos de teste selecionados. Consulte abaixo para obter mais detalhes.
• Exibir itens vinculados: essa opção permite que você examine os itens vinculados para um determinado caso de teste. Consulte abaixo para obter mais detalhes.

Copiar/clonar casos de teste (novo recurso)

Para cenários em que você deseja copiar/clonar um caso de teste, você pode usar a opção "Copiar caso de teste". Você pode especificar o projeto de destino, o plano de teste de destino e o conjunto de testes de destino no qual criar o caso de teste de cópia/clonado. Além disso, você também pode especificar se deseja incluir links/anexos existentes para fluir para a cópia clonada.

Exibir itens vinculados (novo recurso)

A rastreabilidade entre artefatos de teste, requisitos e bugs é uma proposta de valor crítico do produto Test Plans. Usando a opção "Exibir itens vinculados", você pode examinar facilmente todos os Requisitos vinculados aos quais esse caso de teste está vinculado, todos os pacotes de testes/planos de teste em que esse caso de teste foi usado e todos os bugs que foram arquivados como parte da execução do teste.

4. Guia Executar

A guia Definir permite agrupar, adicionar e gerenciar casos de teste para um conjunto de testes. Enquanto a guia executar é para atribuir pontos de teste e executá-los.

O que é um ponto de teste? Os casos de teste por si só não são executáveis. Quando você adiciona um caso de teste a um conjunto de testes, os pontos de teste são gerados. Um ponto de teste é uma combinação exclusiva de caso de teste, conjunto de testes, configuração e testador. Exemplo: se você tiver um caso de teste como "Testar funcionalidade de logon" e adicionar duas configurações a ele como Edge e Chrome, isso resultará em 2 pontos de teste. Agora, esses pontos de teste podem ser executados. Na execução, os resultados do teste são gerados. Por meio da exibição de resultados de teste (histórico de execução), você pode ver todas as execuções de um ponto de teste. A execução mais recente do ponto de teste é o que você vê na guia Executar.
Portanto, os casos de teste são entidades reutilizáveis. Ao incluí-los em um plano de teste ou pacote, os pontos de teste são gerados. Ao executar pontos de teste, você determina a qualidade do produto ou serviço que está sendo desenvolvido.

Um dos principais benefícios da nova página é para os usuários que fazem principalmente a execução/acompanhamento de teste (precisam ter apenas o nível de acesso 'Básico'), eles não estão sobrecarregados com a complexidade do gerenciamento do pacote (definir guia está oculto para esses usuários).

A guia Definir e determinadas operações só estão disponíveis para usuários com o nível de acesso Básico + Test Plans ou equivalente. Todo o resto, incluindo a guia "Executar", deve ser exercido por um usuário com nível de acesso "Básico".

Tarefas

A guia Executar permite que você execute as seguintes tarefas:

• Pontos de teste de marca em massa: essa opção permite marcar rapidamente o resultado dos pontos de teste – aprovados, com falha, bloqueados ou não aplicáveis, sem precisar executar o caso de teste por meio do executor de teste. O resultado pode ser marcado para um ou vários pontos de teste de uma só vez.
• Executar pontos de teste: essa opção permite executar os casos de teste individualmente passando por cada etapa de teste e marcando-os como aprovados/reprovados usando um executor de teste. Dependendo do aplicativo que você está testando, você pode usar o "Web Runner" para testar um "aplicativo Web" ou o "executor da área de trabalho" para testar aplicativos web e/ou desktop. Você também pode invocar "Executar com opções" para especificar um Build no qual o teste deseja executar.
• Opções de coluna: você pode gerenciar a lista de colunas visíveis na guia Executar usando "Opções de coluna". A lista de colunas disponíveis para seleção está associada a pontos de teste, como Executar por, Testador Atribuído, Configuração etc.
• Exibição em tela inteira: você pode exibir o conteúdo de toda a guia Executar em um modo de tela inteira usando essa opção.
• Filtragem: usando a barra de filtros, você pode filtrar a lista de pontos de teste usando os campos "título do caso de teste", "atribuído a", "estado", "resultado do teste", "Testador" e "Configuração". Você também pode classificar a lista clicando nos cabeçalhos de coluna.

Opções de menu de contexto

O menu de contexto no nó Ponto de teste dentro da guia Executar fornece as seguintes opções:

• Marcar o resultado do teste: o mesmo que acima, permite marcar rapidamente o resultado dos pontos de teste - aprovados, com falha, bloqueados ou não aplicáveis.
• Executar pontos de teste: o mesmo que acima, permite que você execute os casos de teste por meio do executor de teste.
• Redefinir o teste para ativo: essa opção permite redefinir o resultado do teste para ativo, ignorando assim o último resultado do ponto de teste.
• Formulário abrir/editar item de trabalho de caso de teste: essa opção permite editar um caso de teste usando o formulário de item de trabalho no qual você edita os campos de item de trabalho, incluindo etapas de teste.
• Atribuir testador: essa opção permite que você atribua os pontos de teste aos testadores para execução de teste.
• Exibir resultado do teste: essa opção permite exibir os detalhes mais recentes do resultado do teste, incluindo o resultado de cada etapa de teste, comentários adicionados ou bugs arquivados.
• Exibir histórico de execução: essa opção permite exibir todo o histórico de execução do ponto de teste selecionado. Ele abre uma nova página na qual você pode ajustar os filtros para exibir o histórico de execução não apenas do ponto de teste selecionado, mas também de todo o caso de teste.

relatório progresso do Test Plans

Esse relatório pronto para uso ajuda você a acompanhar a execução e status de um ou mais Test Plans em um projeto. Visite Test Plans > relatório progresso* para começar a usar o relatório.

As três seções do relatório incluem o seguinte:

1. Resumo: mostra uma exibição consolidada para os planos de teste selecionados.
2. Tendência de resultado: renderiza um instantâneo diário para fornecer uma linha de tendência de execução e status. Ele pode mostrar dados por 14 dias (padrão), 30 dias ou um intervalo personalizado.
3. Detalhes: esta seção permite que você faça uma busca detalhada por cada plano de teste e fornece análises importantes para cada conjunto de testes.

Artifacts

Observação

Azure DevOps Server 2020 não importa feeds que estão na lixeira durante a importação de dados. Se você quiser importar feeds que estão na lixeira, restaure-os da lixeira antes de iniciar a importação de dados.

Expressões de licença e licenças inseridas

Agora você pode ver os detalhes das informações de licença para pacotes NuGet armazenados no Azure Artifacts durante a navegação de pacotes no Visual Studio. Isso se aplica a licenças que são representadas usando expressões de licença ou licenças inseridas. Agora você pode ver um link para as informações de licença na página de detalhes do pacote do Visual Studio (seta vermelha na imagem abaixo).

Clicar no link levará você para uma página da Web na qual você pode exibir os detalhes da licença. Essa experiência é a mesma para expressões de licença e licenças inseridas, portanto, você pode ver detalhes de licença para pacotes armazenados no Azure Artifacts em um só lugar (para pacotes que especificam informações de licença e têm suporte do Visual Studio).

Tarefas de autenticação leve

Agora você pode se autenticar com gerenciadores de pacotes populares do Azure Pipelines usando tarefas de autenticação leves. Isso inclui NuGet, npm, PIP, Twine e Maven. Anteriormente, você podia autenticar com esses gerenciadores de pacotes usando tarefas que forneciam uma grande quantidade de funcionalidade, incluindo a capacidade de publicar e baixar pacotes. No entanto, isso exigia o uso dessas tarefas para todas as atividades que interagiam com os gerenciadores de pacotes. Se você tivesse seus próprios scripts para executar tarefas como publicar ou baixar pacotes, não seria possível usá-los em seu Pipeline. Agora, você pode usar scripts de seu próprio design em seu YAML de pipeline e executar a autenticação com essas novas tarefas leves. Um exemplo usando npm:

O uso do comando "ci" e "publish" nesta ilustração é arbitrário, você pode usar todos os comandos compatíveis com o YAML do Azure Pipelines. Isso permite que você tenha controle total da invocação de comando e facilita o uso de scripts compartilhados na configuração do pipeline. Para obter mais informações, consulte a documentação da tarefa de autenticação NuGet, npm, PIP, Twine e Maven .

Melhorias no tempo de carregamento da página de feed

Estamos felizes em anunciar que melhoramos o tempo de carregamento da página do feed. Em média, os tempos de carregamento da página de feed diminuíram 10%. Os maiores feeds foram os que mais melhoraram o tempo de carregamento da página do feed de 99º percentil (tempos de carga nos 99% mais altos de todos os feeds) diminuiu 75%.

Compartilhar seus pacotes publicamente com feeds públicos

Agora você pode criar e armazenar seus pacotes dentro de feeds públicos. Os pacotes armazenados em feeds públicos estão disponíveis para todos na Internet sem autenticação, estejam eles em sua coleção ou até mesmo conectados a uma coleção do Azure DevOps. Saiba mais sobre feeds públicos em nossa documentação de feeds ou acesse nosso tutorial para compartilhar pacotes publicamente.

Configurar upstreams em coleções diferentes dentro de um locatário do AAD

Agora você pode adicionar um feed em outra coleção associada ao seu locatário do AAD (Azure Active Directory) como uma fonte de upstream ao feed do Artifacts. O feed pode encontrar e usar pacotes dos feeds configurados como fontes upstream, permitindo que os pacotes sejam compartilhados facilmente entre coleções associadas ao seu locatário do AAD. Veja como configurar isso na documentação.

Usar o Provedor de Credenciais do Python para autenticar pip e twine com feeds do Azure Artifacts

Agora você pode instalar e usar o Provedor de Credenciais do Python (identificador de artefatos) para configurar automaticamente a autenticação para publicar ou consumir pacotes python de ou para um feed do Azure Artifacts. Com o provedor de credenciais, você não precisa configurar nenhum arquivo de configuração (pip.ini/pip.conf/.pypirc), você será simplesmente levado por meio de um fluxo de autenticação no navegador da Web ao chamar pip ou twine pela primeira vez. Veja mais informações na documentação.

Feeds do Azure Artifacts no Gerenciador de Pacotes do Visual Studio

Agora mostramos ícones de pacote, descrições e autores no Gerenciador de Pacotes NuGet do Visual Studio para pacotes fornecidos nos feeds do Azure Artifacts. Anteriormente, a maioria desses metadados não era fornecida ao VS.

Atualização da experiência conectar-se ao feed

A caixa de diálogo Conectar ao feed é a entrada para usar o Azure Artifacts; ele contém informações sobre como configurar clientes e repositórios para efetuar push e efetuar pull de pacotes de feeds no Azure DevOps. Atualizamos a caixa de diálogo para adicionar informações detalhadas de configuração e expandimos as ferramentas para as qual fornecemos instruções.

Os feeds públicos agora estão em disponibilidade geral com suporte upstream

A visualização pública de feeds públicos recebeu ótima adoção e comentários. Nesta versão, estendemos recursos adicionais para disponibilidade geral. Agora, você pode definir um feed público como uma fonte upstream de um feed privado. Você pode manter seus arquivos de configuração simples, podendo upstream de e para feeds privados e com escopo de projeto.

Criar feeds no escopo do projeto por meio do portal

Quando lançamos feeds públicos, também lançamos feeds com escopo de projeto. Até agora, os feeds no escopo do projeto podiam ser criados por meio de APIs REST ou criando um feed público e, em seguida, tornando o projeto privado. Agora, você pode criar feeds com escopo de projeto diretamente no portal de qualquer projeto se tiver as permissões necessárias. Você também pode ver quais feeds são projeto e quais têm escopo de coleção no seletor de feeds.

Melhorias de desempenho do npm

Fizemos alterações em nosso design principal para melhorar a maneira como armazenamos e entregamos pacotes npm nos feeds do Azure Artifacts. Isso nos ajudou a alcançar uma redução de até 10 vezes na latência para algumas das APIs mais usadas para npm.

Aprimoramentos de acessibilidade

Implantamos correções para resolver problemas de acessibilidade em nossa página de feeds. As correções incluem o seguinte:

• Criar experiência de feed
• Experiência de configurações de feed global
• Conectar-se à experiência de feed

Wiki

Edição avançada para páginas wiki de código

Anteriormente, ao editar uma página wiki de código, você era redirecionado para o hub Azure Repos para edição. Atualmente, o Hub de repositório não é otimizado para edição de markdown.

Agora você pode editar uma página wiki de código no editor lado a lado dentro do wiki. Isso permite que você use a barra de ferramentas markdown avançada para criar seu conteúdo, tornando a experiência de edição idêntica à do wiki do projeto. Você ainda pode optar por editar em repositórios selecionando a opção Editar em Repos no menu de contexto.

Criar e inserir itens de trabalho de uma página wiki

Enquanto ouvíamos seus comentários, ouvimos que você usa o wiki para capturar documentos de debate, documentos de planejamento, ideias sobre recursos, documentos de especificação, minutos de reunião. Agora você pode criar facilmente recursos e histórias de usuário diretamente de um documento de planejamento sem sair da página wiki.

Para criar um item de trabalho, selecione o texto na página wiki em que você deseja inserir o item de trabalho e selecione Novo item de trabalho. Isso economiza tempo, pois você não precisa criar o item de trabalho primeiro, vá para editar e, em seguida, localize o item de trabalho para inserção. Ele também reduz a alternância de contexto, pois você não sai do escopo wiki.

Para saber mais sobre como criar e inserir um item de trabalho do wiki, confira nossa documentação aqui.

Comentários em páginas wiki

Anteriormente, você não tinha uma maneira de interagir com outros usuários wiki dentro do wiki. Isso fez com que a colaboração no conteúdo e a obtenção de perguntas respondessem a um desafio, já que as conversas tinham que acontecer por email ou canais de chat. Com os comentários, agora você pode colaborar com outras pessoas diretamente no wiki. Você pode aproveitar a funcionalidade dos @mention usuários dentro de comentários para chamar a atenção de outros membros da equipe. Esse recurso foi priorizado com base nesse tíquete de sugestão. Para obter mais informações sobre comentários, consulte nossa documentação aqui.

Ocultar pastas e arquivos começando com ".". na árvore wiki

Até agora, a árvore wiki mostrava todas as pastas e arquivos começando com um ponto (.) na árvore wiki. Em cenários wiki de código, isso fazia com que pastas como .vscode, que deveriam estar ocultas, aparecessem na árvore wiki. Agora, todos os arquivos e pastas que começam com um ponto permanecerão ocultos na árvore wiki, reduzindo a desordem desnecessária.

Esse recurso foi priorizado com base nesse tíquete de sugestão.

URLs de página wiki curtas e legíveis

Você não precisa mais usar uma URL de várias linhas para compartilhar links de página wiki. Estamos aproveitando as IDs de página na URL para remover parâmetros, tornando a URL mais curta e fácil de ler.

A nova estrutura de URLs será semelhante a:

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

Este é um exemplo da nova URL para uma página do Wiki bem-vindo ao Azure DevOps :

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

Isso foi priorizado com base nesse tíquete de sugestão de recurso do Developer Community.

Rolagem síncrona para edição de páginas wiki

A edição de páginas wiki agora é mais fácil com a rolagem síncrona entre a edição e o painel de visualização. Rolar de um lado rolará automaticamente o outro lado para mapear as seções correspondentes. Você pode desabilitar a rolagem síncrona com o botão de alternância.

Observação

O estado da alternância de rolagem síncrona é salvo por usuário e conta.

Visitas de página para páginas wiki

Agora você pode obter informações sobre as visitas à página para páginas wiki. A API REST permite acessar as informações de visitas à página nos últimos 30 dias. Você pode usar esses dados para criar relatórios para suas páginas wiki. Além disso, você pode armazenar esses dados em sua fonte de dados e criar painéis para obter insights específicos, como as páginas mais exibidas.

Você também verá uma contagem de visitas de página agregada para os últimos 30 dias em cada página.

Observação

Uma visita de página é definida como uma exibição de página por um determinado usuário em um intervalo de 15 minutos.

Relatórios

Relatórios de falha e duração do pipeline

Métricas e insights ajudam você a melhorar continuamente a taxa de transferência e a estabilidade de seus pipelines. Adicionamos dois novos relatórios para fornecer insights sobre seus pipelines.

1. O relatório de falha do pipeline mostra a taxa de aprovação de build e a tendência de falha. Além disso, ele também mostrará a tendência de falha de tarefas para fornecer insights sobre qual tarefa no pipeline está contribuindo para o número máximo de falhas.

2. O relatório de duração do pipeline mostra a tendência de tempo necessário para que um pipeline seja executado. Ele também mostra quais tarefas no pipeline estão levando mais tempo.

Melhoria no widget Resultados da Consulta

O widget de resultados da consulta é um dos nossos widgets mais populares e por um bom motivo. O widget exibe os resultados de uma consulta diretamente em seu dashboard e é útil em muitas situações.

Com essa atualização, incluímos muitas melhorias tão esperadas:

• Agora você pode selecionar quantas colunas quiser exibir no widget. Não há mais limite de 5 colunas!
• O widget dá suporte a todos os tamanhos, de 1x1 a 10x10.
• Quando você redimensionar uma coluna, a largura da coluna será salva.
• Você pode expandir o widget para o modo de exibição em tela inteira. Quando expandida, ela exibirá todas as colunas retornadas pela consulta.

Filtragem avançada de widgets lead e cycle time

O tempo de cliente potencial e de ciclo é usado pelas equipes para ver quanto tempo leva para que o trabalho flua por meio de seus pipelines de desenvolvimento e, por fim, forneça valor aos clientes.

Até agora, os widgets lead e cycle time não suportavam critérios avançados de filtro para fazer perguntas como: "quanto tempo minha equipe está levando para fechar os itens de prioridade mais alta?"

Com essa atualização, perguntas como essa podem ser respondidas filtrando na raia Quadro.

Também incluímos filtros de item de trabalho para limitar os itens de trabalho que aparecem no gráfico.

Burndown de sprint embutido usando pontos de história

Seu Sprint Burndown agora pode queimar por Histórias. Isso aborda seus comentários do Developer Community.

No hub Sprint, selecione a guia Análise. Em seguida, configure o relatório da seguinte maneira:

1. Selecionar lista de pendências de Histórias
2. Selecione para gravar em Sum of Story Points

Um widget do Sprint Burndown com tudo o que você está pedindo

O novo widget Sprint Burndown dá suporte à queima por Pontos de História, contagem de Tarefas ou somando campos personalizados. Você pode até mesmo criar um burndown de sprint para Recursos ou Epics. O widget exibe burndown médio, % concluído e aumento de escopo. Você pode configurar a equipe, permitindo exibir burndowns de sprint para várias equipes no mesmo dashboard. Com todas essas ótimas informações a serem exibidas, permitimos redimensioná-la até 10x10 no dashboard.

Para experimentá-lo, você pode adicioná-lo do catálogo de widgets ou editando a configuração do widget existente do Sprint Burndown e marcando a caixa Experimentar a nova versão agora .

Observação

O novo widget usa o Analytics. Mantivemos o Sprint Burndown herdado caso você não tenha acesso ao Analytics.

Miniatura de burndown de sprint embutido

O Sprint Burndown está de volta! Há alguns sprints, removemos o burndown de sprint no contexto dos cabeçalhos Burndown e Taskboard do Sprint. Com base em seus comentários, melhoramos e reintroduzimos a miniatura do sprint burndown.

Clicar na miniatura exibirá imediatamente uma versão maior do gráfico com uma opção para exibir o relatório completo na guia Análise. Todas as alterações feitas no relatório completo serão refletidas no gráfico exibido no cabeçalho . Portanto, agora você pode configurá-lo para burndown com base em histórias, pontos de história ou por contagem de tarefas, em vez de apenas a quantidade de trabalho restante.

Criar um dashboard sem uma equipe

Agora você pode criar uma dashboard sem associá-la a uma equipe. Ao criar um dashboard, selecione o tipo Painel do Projeto.

Um Painel de Projeto é como um Painel de Equipe, exceto que ele não está associado a uma Equipe e você pode decidir quem pode editar/gerenciar o dashboard. Assim como um Painel de Equipe, ele é visível para todos no projeto.

Todos os widgets do Azure DevOps que exigem um contexto de equipe foram atualizados para permitir que você selecione uma equipe em sua configuração. Você pode adicionar esses widgets aos Painéis do Projeto e selecionar a equipe específica desejada.

Observação

Para widgets personalizados ou de terceiros, um Painel de Projeto passará o contexto da equipe padrão para esses widgets. Se você tiver um widget personalizado que depende do contexto da equipe, atualize a configuração para permitir que você selecione uma equipe.

---

Comentários

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

---

Parte superior da página