Notas de versão do Azure DevOps Server 2020

Comunidade de Desenvolvedores | Requisitos de Sistema | Termos de Licença | Blog de DevOps | Hashes SHA-1

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

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

A atualização direta para o Azure DevOps Server é suportada pelo Azure DevOps Server 2020, Azure DevOps Server 2019 ou Team Foundation Server (TFS) 2015 ou mais recente. Se sua 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, consulte Instalar e configurar o Azure DevOps local.

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

O Azure DevOps Server 2020 introduz uma nova execução de pipeline (compilação) modelo de retenção que funciona com base em configurações de no nível do projeto.

O Azure DevOps Server 2020 trata da retenção de compilações de forma diferente, com base em políticas de retenção ao nível do pipeline. Determinadas configurações de política levam a que as execuções de pipeline sejam excluídas 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 de blog para obter mais informações sobre como atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020.

Azure DevOps Server 2020 Atualização 0.2 Patch 6 Data de lançamento: 14 de novembro de 2023

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

• Estendida a lista de caracteres permitidos de tarefas do PowerShell para Habilitar argumentos de tarefas do shellde validação de parâmetros.

Instalar correções

Configurar o TFX

1. Siga as etapas no para carregar tarefas para a documentação da coleção do projeto para instalar e fazer login com o tfx-cli.

Atualizar tarefas usando TFX

1. Faça o download 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 do 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.

• Sobre o clássico:

  Defina a variável no separador de variáveis do pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Atualização 0.2 Patch 5 Data de lançamento: 10 de outubro de 2023

Lançámos um patch para a Atualização 0.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.

• Corrigido um bug em que a identidade "Analysis Owner" aparece como Identidade Inativa em máquinas de atualização de patch.

Azure DevOps Server 2020 Atualização 0.2 Patch 4 Data de lançamento: 12 de setembro de 2023

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

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

Instalar correções

1. Baixe e instale o Azure DevOps Server 2020 Update 0.2 patch 4.

Atualizar o agente do Azure Pipelines

1. Descarregue o agente a partir 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 Windows autoalojados para implantar o agente.  

Configurar o TFX

1. Siga as etapas no para carregar tarefas para a documentação da coleção do projeto para instalar e fazer login com o tfx-cli.

Atualizar tarefas usando TFX

1. Faça o download 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 do 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.

• Sobre o clássico:

  Defina a variável no separador de variáveis do pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Atualização 0.2 Patch 3 Data de lançamento: 8 de agosto de 2023

Lançámos um patch para a Atualização 0.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.

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

Azure DevOps Server 2020 Atualização 0.2 Patch 2 Data de lançamento: 13 de junho de 2023

Lançámos um patch para a Atualização 0.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.

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

Azure DevOps Server 2020 Atualização 0.2 Patch 1 Data de lançamento: 18 de outubro de 2022

Lançámos um patch para a Atualização 0.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.

• Resolva o problema com as novas identidades AD que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
• Corrigir um problema com o filtro Solicitado por Membro do Grupo nas configurações do webhook.
• Corrija o erro de compilações de check-in fechado quando as configurações da organização para pipeline tinham escopo de autorização de trabalho configurado como Limitar escopo de autorização de trabalho ao projeto atual para pipelines sem liberação.

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

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

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

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

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

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

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

• As notificações por e-mail não foram enviadas ao usar o controle @mention em um item de trabalho.
• Corrija o erro TF400813 ao mudar de conta. Este erro ocorreu quando atualizado do TFS 2018 para o Azure DevOps Server 2020.0.1.
• Corrigir o problema de falha ao carregar a página de resumo da Visão Geral do Projeto.
• Melhoria na sincronização de usuários do Ative Directory.
• Foi resolvida a vulnerabilidade do Elasticsearch removendo a classe jndilookup dos binários log4j.

Etapas de instalação

1. Atualize o servidor com Patch 9.
2. Verifique o valor do Registo 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 (Name = Version, Value = 5.4.1).
3. Execute o comando update PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update conforme fornecido no arquivo readme. 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 seja concluída.

1. Atualize o servidor com Patch 9..
2. Verifique o valor do Registo 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 (Name = Version, Value = 5.4.1).
3. Copie o conteúdo da pasta chamada zip, localizada em C:\Program Files\{TFS Version Folder}\Search\zip para a pasta de arquivos remotos do Elasticsearch.
4. Execute Configure-TFSSearch.ps1 -Operation update na máquina do servidor Elasticsearch.

SHA-256 Hash: B0C05A972C73F253154AEEB7605605EF2E596A96A3720AE942D7A9DDD881545E

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

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

• Problema de localização nos estados de layout de itens de trabalho personalizados.
• Problema de localização no modelo de notificação por e-mail.
• 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.

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

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

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

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

Patch 6 para o Azure DevOps Server 2020.0.1 inclui correções para os problemas seguintes.

• Corrigir a falha no download/upload de artefatos.
• Resolva o problema com dados de resultados de teste inconsistentes.

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

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

• Corrija o erro na interface de utilizador da definição de build.
• Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.
• Corrija o problema com trabalhos de entrega de e-mail para alguns tipos de item de trabalho.

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

Patch 4 para o Azure DevOps Server 2020.0.1 inclui correções para o que segue.

• Corrija o problema com a importação de dados. A importação de dados estava demorando muito tempo para clientes que têm muitos casos de teste obsoletos. Isto deveu-se a referências que aumentaram o tamanho da tabela tbl_testCaseReferences. Com esse patch, removemos referências a casos de teste obsoletos para ajudar a acelerar o processo de importação de dados.

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

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

• Dados de resultados de teste inconsistentes ao usar Microsoft.TeamFoundation.TestManagement.Client.

Se você tiver o Azure DevOps Server 2020.0.1, deverá instalar Azure DevOps Server 2020.0.1 Patch 3.

Verificando a instalação

• Opção 1: Executar 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 ficheiro: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. O Azure DevOps Server 2020.0.1 é instalado para c:\Program Files\Azure DevOps Server 2020 por padrão. Depois de instalar o Azure DevOps Server 2020.0.1 Patch 3, a versão será 18.170.31228.1.

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

Lançámos um patch para o 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 este patch, deverá seguir os passos listados abaixo para a instalação geral do patch, AzureResourceGroupDeploymentV2 e a instalação de tarefas AzureResourceManagerTemplateDeploymentV3.

Instalação geral do patch

Se você tiver o Azure DevOps Server 2020.0.1, deverá instalar Azure DevOps Server 2020.0.1 Patch 2.

Verificando a instalação

• Opção 1: Executar 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 ficheiro: [INSTALL_DIR]\Azure DevOps Server 2020\Application Tier\bin\Microsoft.Teamfoundation.Framework.Server.dll. O Azure DevOps Server 2020.0.1 é instalado para c:\Program Files\Azure DevOps Server 2020 por padrão. Depois de instalar o Azure DevOps Server 2020.0.1 Patch 2, a versão será 18.170.31123.3.

Instalação da tarefa AzureResourceGroupDeploymentV2

Instalar

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

2. Baixe e instale Node.js 14.15.1 e npm (incluído com o download Node.js) de acordo com sua máquina.

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

npm install -g tfx-cli

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

5. Execute o seguinte a partir do 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 seguinte comando para carregar a tarefa no servidor. Use o caminho do arquivo de .zip extraído da etapa 1.

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

Instalação da tarefa AzureResourceManagerTemplateDeploymentV3

Instalar

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

2. Transfira e instale Node.js 14.15.1 e npm (incluído com o Node.js download) conforme apropriado para a sua máquina.

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

npm install -g tfx-cli

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

5. Execute o seguinte a partir do 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 seguinte comando para carregar a tarefa no servidor. Use o caminho do arquivo de .zip extraído da etapa 1.

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

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

Lançámos um patch para o Azure DevOps Server 2020.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• Resolva o problema relatado no ticket de feedback da Comunidade de Desenvolvedores| O botão Novo Teste não está a funcionar
• Inclua correções lançadas com Azure DevOps Server 2020 Patch 2.

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

Lançámos um patch versão para o Azure DevOps Server 2020 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• Resolva o problema relatado no ticket de feedback da Comunidade de Desenvolvedores| O botão Novo Teste não está a funcionar

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

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

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

• Resolva um problema de atualização do Azure DevOps Server 2019 em que o proxy Git pode parar de funcionar após a atualização.
• Corrija a exceção System.OutOfMemoryException para coleções não ENU anteriores ao Team Foundation Server 2017 ao atualizar para o Azure DevOps Server 2020. Resolve o problema relatado no tíquete de feedback da Comunidade de Desenvolvedores.
• A falha de manutenção foi causada pela falta de Microsoft.Azure.DevOps.ServiceEndpoints.Sdk.Server.Extensions.dll. Resolve o problema relatado no tíquete de feedback da Comunidade de Desenvolvedores.
• Corrija o erro de nome de coluna inválido no Google Analytics ao atualizar para o Azure DevOps Server 2020. Resolve o problema relatado no tíquete de feedback da Comunidade de Desenvolvedores.
• XSS armazenado ao exibir etapas nos resultados de casos de teste.
• Falha na etapa de atualização ao migrar dados de resultados de pontos para o TCM.

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

Lançámos um patch versão para o Azure DevOps Server 2020 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• 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'
• As compilações não retidas são excluídas imediatamente após a migração para o Azure DevOps Server 2020
• Corrigir exceção do provedor de dados

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

Lançámos um patch versão para o Azure DevOps Server 2020 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• CVE-2020-17145: Vulnerabilidade de Spoofing no Servidor de DevOps do Azure e no Team Foundation Services

Azure DevOps Server 2020 Data de lançamento: 6 de outubro de 2020

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

Se você estiver atualizando do Azure DevOps 2019 (qualquer versão) ou de um candidato a 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 confirmar se encontrou o problema procurando por Microsoft.TeamFoundation.Git.dll nas pastas <Install Dir>\Version Control Proxy\Web Services\bin, <Install Dir>\Application Tier\TFSJobAgent e <Install Dir>\Tools. Se o ficheiro estiver em falta, pode executar uma reparação para restaurar os ficheiros em falta.

Para executar um reparo, vá para Settings -> Apps & Features na máquina/VM do Servidor de DevOps do Azure e execute um reparo no Servidor de DevOps 2020 do Azure. Quando o reparo for concluído, você poderá reiniciar a máquina/VM.

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

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

Azure DevOps Server 2020 RC1 nova edição Data de lançamento: 10 de julho de 2020

Relançamos o Azure DevOps Server 2020 RC1 para corrigir o feedback deste ticket da Comunidade de Desenvolvedores .

Anteriormente, após a atualização do Azure DevOps Server 2019 Update 1.1 para o Azure DevOps Server 2020 RC1, você não conseguia exibir arquivos nos Repos, Pipelines e Wiki da interface do usuário da Web. Houve uma mensagem de erro indicando ocorreu um erro inesperado nesta região da página. Você pode tentar recarregar este componente ou atualizar toda a página. Com esta versão, corrigimos esse problema. Consulte a postagem do blog para obter mais informações.

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

Resumo do que há de novo no Azure DevOps Server 2020

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

• Pipelines de múltiplos estágios
• Implantação contínua no YAML
• Acompanhe o progresso dos itens pai usando o Rollup on Boards backlog
• 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 destino do Azure Repos
• Administração de políticas de recompra cruzada
• Página do Novo Plano de Teste
• Edição avançada para páginas de 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
• Linhas de Pipeline
• Planos de teste
• Artefatos
• Wiki
• Relatórios

Geral

Disponibilidade geral da CLI do Azure DevOps

Em fevereiro, apresentamos a extensão Azure DevOps para a CLI do Azure. A extensão permite que você interaja com o Azure DevOps a partir da linha de comando. Recolhemos os seus comentários que nos ajudaram a melhorar a extensão e a adicionar mais comandos. Estamos agora felizes em anunciar que a extensão está disponível em geral.

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

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

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

Conselhos

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

Adicionámos um novo filtro tanto ao quadro Sprint como à lista de pendências da Sprint. Isso permite filtrar os itens da lista de pendências do nível de requisitos (primeira coluna à esquerda) pelos seus pais. 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 obrigatórios em Bug/Tarefa

Historicamente, a partir do quadro Kanban, se você movesse um item de trabalho de uma coluna para outra onde a mudança de estado acionasse regras de campo, o cartão mostraria apenas uma mensagem de erro vermelha que forçaria 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 ter que abrir o item de trabalho em si.

Recarga 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 perdia as alterações. Agora, contanto que ambos estejam editando campos diferentes, você verá atualizações em tempo real das alterações feitas no item de trabalho.

Gerencie caminhos de iteração e área a partir da linha de comando

Agora você pode gerenciar caminhos de iteração e área a partir da linha de comando usando os comandos az boards iteration e az boards area. Por exemplo, você pode configurar e gerenciar caminhos de iteração e área interativamente a partir 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 item pai de cada item de trabalho no seu backlog de produto ou backlog de sprint. Para habilitar este recurso, vá para Opções de Coluna na lista de pendências desejada e adicione a coluna Pai.

Alterar o processo usado por um projeto

As suas ferramentas devem evoluir à medida que a sua equipa evolui; agora pode alternar os seus projetos de qualquer processo pronto para uso para qualquer outro processo pronto para uso. Por exemplo, você pode alterar seu projeto de usar Agile para Scrum, ou Basic 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 a partir de consultas e APIs REST. Isso é útil para rastrear campos extras quando você está integrando com outros sistemas.

Obtenha informações sobre a integridade da sua equipe com três novos relatórios do Azure Boards

Você não pode consertar o que não pode ver. Portanto, você quer manter um olho atento sobre o estado e a saúde de seus processos de trabalho. Com esses relatórios, estamos facilitando o acompanhamento de métricas importantes com o mínimo de esforço nos Painéis do Azure.

Os três novos relatórios interativos são: Burndown, Cumulative Flow Diagram (CFD) e Velocity. Você pode ver os relatórios na nova guia de análise.

Métricas como quadro de redução do sprint, fluxo de trabalho e velocidade da equipa proporcionam-lhe visibilidade sobre o progresso da sua equipa e ajudam a responder a perguntas como:

• Quanto trabalho nos resta neste sprint? Estamos no caminho certo para completá-lo?
• Qual é a etapa do processo de desenvolvimento mais longa? Podemos fazer alguma coisa a esse respeito?
• Com base em iterações anteriores, quanto trabalho devemos planejar para o próximo sprint?

Os novos relatórios são totalmente interativos e permitem ajustá-los às suas necessidades. Você pode encontrar os novos relatórios na guia Analytics em cada hub.

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

  

• Os relatórios CFD e Velocity podem ser acedidos no separador Analytics em Boards e Backlogs, clicando no cartão relevante.

  

Com os novos relatórios você tem mais controle e informações sobre sua equipe. Eis alguns exemplos:

• Os relatórios Sprint Burndown 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 de tempo do burndown do sprint sem afetar as datas do projeto. Então, se sua equipe costuma passar o primeiro dia de cada planejamento de sprint, agora você pode combinar o gráfico para refletir isso.
• O gráfico Burndown agora tem uma marca d'água mostrando fins de semana.
• O relatório CFD permite remover colunas do quadro, como Design, para obter mais foco no fluxo sobre o qual as equipes têm controle.

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

O gráfico de velocidade agora pode ser rastreado para todos os níveis de lista de pendências. Por exemplo, agora você pode adicionar Recursos e Épicos, enquanto antes o gráfico anterior suportava apenas Requisitos. Aqui está um exemplo de um relatório de velocidade para as últimas 6 iterações do backlog de funcionalidades.

Personalizar colunas do Quadro de Tarefas

Temos o prazer de 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 seu Quadro de Tarefas, aceda a Opções de Colunas.

Esse recurso foi priorizado com base em uma sugestão da Comunidade de desenvolvedores.

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ó quer 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 o botão estiver ativado, verá todos os itens filho num estado concluído. Quando a alternância estiver desativada, todos os itens filho em um estado concluído serão ocultos da lista de pendências.

Tags mais recentes exibidas ao marcar um item de trabalho

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

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

As regras de item de trabalho permitem definir 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 obrigatório com base na associação ao grupo. Por exemplo, pode querer conceder aos proprietários de produtos a capacidade de definir a prioridade das suas funcionalidades, tornando-a como leitura exclusivamente para todos os outros.

Personalizar valores da lista de opções do sistema

Agora você pode personalizar os valores para qualquer lista de opções do sistema (exceto o campo motivo), como Gravidade, Atividade, Prioridade, etc. As personalizações da lista de opções têm escopo 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 do seu quadro ou lista de pendências com nosso novo parâmetro URL de item de trabalho. Agora você pode abrir uma caixa de diálogo de item de trabalho em seu quadro, lista de pendências ou experiência de sprint anexando o parâmetro ?workitem=[ID] à URL.

Qualquer pessoa com quem partilhar o link irá chegar ao mesmo contexto que tinha quando o partilhou!

Mencione pessoas, itens de trabalho e RPs em campos de texto

Enquanto ouvíamos seus comentários, ouvimos que você queria a capacidade de mencionar pessoas, itens de trabalho e RPs na área de descrição do item de trabalho (e outros campos HTML) no item de trabalho e não apenas nos comentários. Às vezes, estás a colaborar com alguém num item de trabalho ou queres destacar um PR na descrição do item de trabalho, mas não tens como adicionar essa informação. Agora é possível mencionar pessoas, itens de trabalho e PRs em todos os campos de texto longos do item de trabalho.

Pode ver um exemplo aqui.

• Para usar menções de pessoas, digite o sinal de @ e o nome da pessoa que você deseja mencionar. @mentions nos campos de item de trabalho gerará notificações por e-mail da mesma forma que faz para os comentários.
• Para usar menções de item de trabalho, digite o sinal de # seguido pelo ID ou título do item de trabalho. #mentions criará um link entre os dois itens de trabalho.
• Para usar menções PR, adicione um ! seguido do seu ID PR ou nome.

Reações aos comentários da discussão

Um dos nossos principais objetivos é tornar os itens de trabalho mais colaborativos para as equipas. Recentemente, conduzimos uma enquete de no Twitter para descobrir quais recursos de colaboração você deseja nas discussões sobre o item de trabalho. Adicionar reações aos comentários foi a vencedora da enquete, então nós vamos adicioná-las! Aqui estão os resultados da enquete do Twitter.

Você pode adicionar reações a qualquer comentário, e há duas maneiras de adicionar suas reações – o ícone de sorriso no canto superior direito de qualquer comentário, bem como na parte inferior de um comentário ao lado de quaisquer reações existentes. Você pode adicionar todas as seis reações, se quiser, ou apenas uma ou duas. Para remover sua reação, clique na reação na parte inferior do seu comentário e ela será removida. Abaixo podes ver a experiência de adicionar uma reação, assim como a forma como as reações são apresentadas num comentário.

Fixar relatórios do Azure Boards no dashboard

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

Acompanhe o progresso dos itens pai usando o Rollup on Boards backlog

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 filho dentro da hierarquia. Uma ou mais colunas de rollup podem ser adicionadas a uma lista de pendências de produtos ou portfólios.

Por exemplo, aqui mostramos Progresso por Itens de Trabalho, que exibe barras de progresso para itens de trabalho ascendentes com base na porcentagem de itens descendentes que foram fechados. Itens descendentes para Épicos inclui todos os recursos filho e seus itens de trabalho filho ou neto. Itens descendentes para Funcionalidades incluem todas as Histórias de Utilizador e os seus itens de trabalho filho.

Atualizações ao vivo do Taskboard

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 de Rollup

O processo de rollup agora pode ser feito em qualquer campo, incluindo campos personalizados. Ao adicionar uma coluna Rollup, pode ainda escolher uma coluna Rollup na lista Rápida; no entanto, se pretender acumular em campos numéricos que não fazem parte do modelo de processo pré-definido, 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 Configure a coluna Rollup personalizada.

   

2. Escolha entre Barra de Progresso e 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 levará você de volta ao painel de opções de coluna, onde você pode reordenar sua nova coluna personalizada.

Observe que não é possível 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 herdadas para permitir que você oculte campos em um formulário de item de trabalho. Esta regra ocultará campos com base na associação ao 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 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. Ajuda as equipas a colaborarem e a manterem-se no caminho certo com os projetos e garante que todas as partes certas estão envolvidas. No entanto, diferentes partes interessadas têm diferentes níveis de investimento em diferentes esforços, e acreditamos que isso deve ser refletido em sua capacidade de acompanhar 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, receberia notificações por e-mail para todas e quaisquer alterações feitas no item de trabalho. Depois de considerar o seu feedback, estamos tornando o seguimento de um item de trabalho mais flexível para todas as partes interessadas. 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 de seguimento.

No menu Configurações de Notificação, pode escolher entre três opções de notificação. Primeiro, pode anular completamente a sua subscrição. Em segundo lugar, você pode estar totalmente inscrito, onde você recebe notificações para todas as alterações de item de trabalho. Por fim, você pode optar por ser notificado sobre 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 os itens de trabalho em um nível mais alto e não se distraiam com cada alteração feita. Com este recurso, eliminaremos e-mails desnecessários e permitiremos que você se concentre nas tarefas cruciais em mãos.

Vincular itens de trabalho a implantações

Estamos entusiasmados em lançar o controle de implantação no formulário de item de trabalho. Esse controle vincula seus itens de trabalho a uma versão e permite que você rastreie facilmente onde seu item de trabalho foi implantado. Para saber mais, consulte 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 dos Painéis do Azure para que você possa importar itens de trabalho novos ou atualizar itens de trabalho existentes. Para saber mais, consulte a documentação aqui.

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

O contexto pai agora está disponível no 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 tags e prefixos.

Adicionar campo pai à lista de pendências e consultas

O campo pai agora está disponível ao visualizar listas de pendências e resultados de consultas. Para adicionar o campo pai, use as opções Coluna exibição.

Repositórios

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

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

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

Filtrar notificações de comentários em pull requests

Comentários nos pull requests muitas vezes podem gerar muito ruído devido às notificações. Adicionámos uma subscrição personalizada que lhe permite filtrar as notificações de comentários que subscreve por idade do comentário, comentador, comentário eliminado, utilizadores mencionados, autor do pull request, ramificação alvo e participantes do thread. Você pode criar essas assinaturas de notificação clicando no ícone de usuário no canto superior direito e navegando até Configurações de usuário.

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

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

Política para bloquear arquivos com padrões especificados

Agora, os administradores podem definir uma política para impedir que confirmações sejam enviadas 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 correspondam ao padrão fornecido.

Resolver itens de trabalho através de commits com palavras-chave

Agora pode resolver itens de trabalho através de commits feitos na branch padrão, usando palavras-chave como corrigir, corrige, ou corrigido. Por exemplo, você pode escrever - "esta alteração corrigiu #476" na sua mensagem de commit e o item de trabalho #476 ficará concluído quando o commit for feito push ou integrado na ramificação padrão. Para 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 pull, apenas uma aprovação era necessária do grupo adicionado. Agora você pode definir políticas que exigem que mais de um revisor de uma equipe aprove uma solicitação 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 autenticação baseada em conta de serviço para se conectar ao AKS

Anteriormente, ao configurar o Azure Pipelines a partir do Centro de Implementação AKS, utilizávamos uma Ligação do Azure Resource Manager. 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 só tenha acesso ao namespace associado ao pipeline.

Pré-visualizar arquivos Markdown num pull request com comparação lado a lado

Agora pode ver uma pré-visualização de como um arquivo markdown vai parecer ao usar o novo botão Pré-visualização. Além disso, pode-se ver o conteúdo completo de um arquivo na comparação lado a lado selecionando o botão Ver.

Expiração da política de compilação para compilações manuais

As políticas reforçam a qualidade do código e os padrões de gerenciamento de alterações da sua equipe. Anteriormente, você podia definir políticas de expiração de compilação para compilações automatizadas. Agora você também pode definir políticas de expiração de compilação para suas compilações manuais.

Adicionar uma política para bloquear confirmações com base no e-mail do autor da confirmação

Agora, os administradores podem definir uma política de push para evitar que confirmações sejam enviadas por push para um repositório para o qual o e-mail do autor da confirmação não corresponde ao padrão fornecido.

Esse recurso foi priorizado com base em uma sugestão da Comunidade de Desenvolvedores para oferecer uma experiência semelhante. Continuaremos a manter o ticket aberto e incentivaremos os usuários a nos dizer quais outros tipos de políticas push você gostaria de ver.

Marcar arquivos como revisados em uma solicitação pull

Às vezes, você precisa revisar solicitações pull que contêm alterações em um grande número de arquivos e pode ser difícil manter o controle de quais arquivos você já analisou. Agora você pode marcar os arquivos como revisados em uma solicitação 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.

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

Nova interface web para páginas de destino do Azure Repos

Agora você pode experimentar nossas novas páginas de destino modernas, rápidas e compatíveis com dispositivos móveis no Azure Repos. Essas páginas estão disponíveis como páginas de destino do New Repos. As páginas de destino incluem todas as páginas, exceto detalhes do pedido de pull, detalhes do commit e comparação de ramos.

Web

Telemóvel

Administração de políticas de ramificação entre repositórios

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

Novas páginas de destino de conversão da plataforma web

Atualizamos a experiência do usuário das páginas de destino do Repos para torná-la moderna, rápida e compatível com 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 o idioma Kotlin

Temos o prazer de anunciar que agora suportamos o destaque da linguagem Kotlin no editor de arquivos. O realce melhorará a legibilidade do seu 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 pull requests de rascunho

Para ajudar a reduzir o número de notificações por e-mail de solicitações pull, agora você pode criar uma assinatura de notificação personalizada para solicitações pull que são criadas ou atualizadas em estado de rascunho. Você pode receber e-mails especificamente para pedidos de pull de rascunho ou filtrar e-mails desses pedidos para que a tua equipa não seja notificada antes que o pedido de pull esteja pronto para ser analisado.

Melhor capacidade de ação de RP

Quando existem muitas pull requests para rever, pode ser difícil entender onde deve agir em primeiro lugar. Para melhorar a maneira de atuar nos pedidos de pull, agora pode criar várias consultas personalizadas na página de lista de pedidos de pull, com diversas novas opções de filtragem, como o estado de rascunho. Essas consultas criarão seções separadas e colapsáveis na sua página de pull requests, além de "Criado por mim" e "Atribuído a mim". Também pode recusar rever um pull request ao qual foi adicionado a partir do menu de Voto ou do menu de contexto na página da lista de pull requests. Nas seções personalizadas, você verá guias separadas para solicitações 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 pull" da página inicial da coleção. Caso queiras voltar a um pull request, podes sinalizá-lo e este aparecerá no topo da tua lista. Por fim, as solicitações pull que foram definidas para conclusão automática serão marcadas com uma etiqueta com a indicação "Conclusão automática" na lista de solicitações.

Condutas

Pipelines de vários estágios

Estamos trabalhando em uma experiência de usuário atualizada gerenciar seus pipelines. Essas atualizações tornam a experiência dos pipelines moderna e consistente com a direção do Azure DevOps. Além disso, estas atualizações reúnem pipelines de construção tradicionais e pipelines YAML de vários estágios numa única experiência. Ele é compatível com dispositivos móveis e traz várias melhorias para a forma como você gerencia seus pipelines. Pode aprofundar-se e visualizar detalhes do pipeline, detalhes da execução, análises do pipeline, detalhes da tarefa, logs e muito mais.

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

• visualizando e gerenciando vários estágios
• aprovando execuções de canalização
• Percorra todos os registos enquanto um pipeline ainda está em andamento
• saúde de cada ramificação de um pipeline.

Implantação contínua no YAML

Estamos entusiasmados por disponibilizar funcionalidades de CD YAML do Azure Pipelines. Agora oferecemos uma experiência YAML unificada para que você possa configurar cada um dos seus pipelines para fazer CI, CD ou CI e CD juntos. Os recursos do YAML CD introduzem 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
• do Kubernetes e recursos de de máquina virtual no ambiente
• Revisar aplicativos para colaboração
• UX atualizado para conexões de serviço
• Recursos em pipelines YAML

Se estiveres pronto para começar a criar, consulta a documentação do ou o blog para criar pipelines CI/CD de vários estágios.

Gerenciar variáveis de pipeline no editor YAML

Atualizamos a experiência de gerenciamento de 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 lançamentos diretamente no hub de Lançamentos

Foi facilitado o seguimento das aprovações pendentes. Antes, era possível aprovar um lançamento na página de detalhes do lançamento. Agora você pode aprovar versões diretamente do hub Releases.

Melhorias na introdução aos pipelines

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

Finalmente, você terá mais controle ao efetuar o registo do arquivo azure-pipelines.yml numa ramificação diferente, já que pode optar por ignorar a criação de um pedido de pull a partir dessa ramificação.

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

Adicionámos uma pré-visualização , mas não executamos o modo para pipelines YAML. Agora, você pode experimentar um pipeline YAML sem comprometê-lo a um repositório ou executá-lo. Dado um pipeline existente e uma nova carga útil YAML opcional, esta nova API lhe devolverá o pipeline YAML completo. Em atualizações futuras, essa API será usada em um novo recurso de editor.

Para desenvolvedores: POST 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.

Horários Cron em YAML

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

1. Config as code: Pode acompanhar os cronogramas juntamente com o seu pipeline como parte do código.
2. Expressivo: Você tem um poder mais expressivo na definição de horários do que foi capaz de fazer com a interface do usuário. Por exemplo, é mais fácil especificar uma única programação 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 tornámos mais fácil para si diagnosticar problemas com agendas cron. As execuções agendadas no menu Executar no pipeline lhe darão uma visualização das próximas execuções agendadas para o seu pipeline para ajudá-lo a diagnosticar erros com as suas agendas cron.

Atualizações na 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 seu valioso feedback.

Junto 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 de pipeline e aprovações e verificações.

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

Saltando estágios num pipeline YAML

Quando você inicia uma execução manual, às vezes você pode querer pular alguns estágios em seu pipeline. Por exemplo, se não quiseres implantar em produção ou se quiseres não proceder com a implantação em alguns ambientes de 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 pular etapas. Por exemplo, se o seu primeiro estágio produz certos artefatos que são necessários para os estágios subsequentes, então você não deve pular o primeiro estágio. O painel de execução apresenta um aviso genérico sempre que se saltam estágios com dependências a jusante. Cabe-lhe decidir se essas dependências são verdadeiras dependências de artefacto ou se estão apenas presentes para ordenar as implantações.

Pular uma etapa equivale a religar as dependências entre as etapas. Quaisquer dependências imediatas a jusante do estágio ignorado passam a depender do pai upstream do estágio ignorado. Se a execução falhar e tentares executar novamente um estágio falhado, essa tentativa também apresentará o mesmo comportamento de ignorar. Para alterar quais estágios são ignorados, você tem que iniciar uma nova execução.

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

Há uma nova interface do usuário de conexões de serviço. Essa nova interface do usuário é construída com base em padrões de design modernos e vem com vários recursos críticos para suportar 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 de recurso de pipeline na caixa de diálogo de criar execução

Adicionamos a capacidade de pegar manualmente versões de recursos de pipeline na caixa de diálogo create run. Se consumires um pipeline de como um recurso noutro pipeline, agora podes escolher a versão desse pipeline ao criar uma execução.

az melhorias da CLI para o Azure Pipelines

Grupo de variáveis de pipeline e comandos de gerenciamento de variáveis

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 pipeline , grupo de variáveis e comandos de gerenciamento de variável , agora pode roteirizar a configuração e gestão de variáveis de pipeline e grupos de variáveis que, por sua vez, podem ser controlados por versão, permitindo que partilhe facilmente as instruções para mover e configurar pipelines de um projeto para outro.

Executar pipeline para uma ramificação de RP

Ao criar um PR, pode ser um desafio validar se as alterações podem interromper a execução do pipeline na ramificação de destino. No entanto, com a capacidade de acionar uma execução de pipeline ou enfileirar uma compilação para uma ramificação de PR, agora pode validar e visualizar as alterações realizadas, executando-as no pipeline de destino. Consulte a documentação do comando az pipelines run e az pipelines build queue para obter mais informações.

Ignorar a primeira execução de pipeline

Ao criar pipelines, às vezes você deseja criar e confirmar um arquivo YAML e não acionar a execução do pipeline, pois isso pode resultar em uma execução defeituosa devido a uma variedade de razões - 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 a documentação do comando az pipeline create em para mais informações.

Aprimoramento do comando do ponto de extremidade de serviço

Os comandos da CLI do ponto de extremidade de serviço suportam apenas a configuração e o gerenciamento dos pontos de extremidade de serviço do Azure RM e do GitHub. No entanto, com esta versão, os comandos de endpoint de serviço permitem que o utilizador crie qualquer endpoint de serviço fornecendo a configuração através de um ficheiro e oferecem comandos otimizados - az devops service-endpoint github e az devops service-endpoint azurerm, que fornecem suporte de primeira classe para criar endpoints 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 de trabalho que é usado para implantar a sua aplicação em um ambiente. Com esta atualização, adicionámos suporte para referências de passo num trabalho de implementação. Por exemplo, você pode definir um conjunto de etapas em um arquivo e consultá-lo em um trabalho de implantação.

Também adicionámos suporte para propriedades adicionais à tarefa de implementação. Por exemplo, aqui estão algumas propriedades de uma tarefa de implementação que agora pode definir,

• timeoutInMinutes - por quanto tempo o trabalho deve ser executado antes de ser automaticamente cancelado
• cancelTimeoutInMinutes - quanto tempo dar às 'tarefas que devem sempre ser executadas mesmo se canceladas' antes de encerrá-las
• condição - executar a tarefa sob condição
• variáveis - Os valores codificados podem ser adicionados diretamente, ou grupos de variáveis, grupo de variáveis suportado por um cofre de chaves do Azure pode ser referenciado, ou pode-se referir a um conjunto de variáveis definidas num ficheiro.
• continueOnError - se trabalhos futuros devem ser executados mesmo se esse trabalho de implantação falhar; o 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

Adicionámos suporte aos detalhes dos pipelines YAML do CD, onde os pipelines de CI são referidos como recursos de pipeline. Na visualização de execução do pipeline de CI, verá um novo separador 'Pipelines associados', onde poderá encontrar todas as execuções de pipelines que utilizam o seu pipeline e artefactos do mesmo.

Suporte para pacotes GitHub em pipelines YAML

Recentemente, introduzimos um novo tipo de recurso chamado pacotes , que acrescenta 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 ativar acionadores automáticos de pipeline após o lançamento de uma nova versão do pacote. Hoje o suporte está disponível apenas para consumir pacotes do GitHub, mas no futuro, 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

Por padrão, os pacotes não são baixados automaticamente em seus trabalhos, daí porque introduzimos um getPackage macro 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 de Serviço do Kubernetes do Azure na exibição de recursos de ambientes Kubernetes

Adicionamos um link para a exibição de recursos de ambientes 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 do Serviço 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. Muitas vezes, pode querer configurar notificações por e-mail personalizadas para todos os pipelines de lançamento, que são representados por todos os pipelines numa pasta. Anteriormente, você tinha que configurar várias assinaturas ou ter consultas complexas nas assinaturas para obter e-mails focados. Com esta atualização, agora pode adicionar uma cláusula de pasta de lançamento aos eventos de implantação concluída e de aprovação pendente e simplificar as subscrições.

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

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

Cancelar estágio numa execução de pipeline de YAML de múltiplos 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 é útil se você sabe que o estágio vai falhar ou se você tem outra corrida que você deseja começar.

Repetir etapas falhadas

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

Agora podes reiniciar uma etapa do pipeline quando a execução falhar. Todos os trabalhos que falharam na primeira tentativa e aqueles que dependem transitivamente desses trabalhos falhados são todos repetidos.

Isso pode ajudá-lo a economizar tempo de várias maneiras. Por exemplo, quando você executa vários trabalhos em um estágio, talvez queira que cada estágio execute testes em uma plataforma diferente. Se os testes em uma plataforma falharem enquanto outras passarem, você poderá economizar tempo não executando novamente os trabalhos aprovados. Como outro exemplo, um estágio de implantação pode ter falhado devido a uma conexão de rede instável. Repetir essa etapa irá ajudá-lo a economizar tempo, não tendo que produzir outra compilação.

Existem algumas lacunas conhecidas neste recurso. Por exemplo, não é possível repetir um estágio que você cancela explicitamente. Estamos a trabalhar para colmatar estas lacunas em futuras atualizações.

Aprovações em pipelines YAML de múltiplos estágios

Seus pipelines de CD YAML podem conter aprovações manuais. Os proprietários de infraestrutura podem proteger os seus ambientes e buscar aprovações manuais antes que uma fase de uma pipeline seja implantada neles. Com a separação completa de funções entre proprietários de infraestrutura (ambiente) e aplicativos (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 no ambiente.

A execução do pipeline que faz a implementação para o ambiente de desenvolvimento será interrompida para aprovação no início da fase.

Aumento do limite de tempo limite e frequência dos portões

Anteriormente, o limite de tempo limite nos dutos de liberação era de três dias. Com esta 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 compilação para Dockerfile

Anteriormente, ao criar um novo pipeline para um Dockerfile na criação de um novo pipeline, o modelo recomendava enviar a imagem para um Registro de Contêiner do Azure e implantar em um Serviço 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 as configurações do aplicativo do Serviço de Aplicativo do Azure

O Serviço de Aplicativo do Azure permite a configuração por meio de várias definições de como configurações de aplicativo, cadeias de conexão e outras definições de configuração gerais. Agora temos uma nova tarefa do Azure Pipelines, Configurações do Serviço de Aplicativo do Azure, que permite configurar essas definições em massa usando a sintaxe JSON no seu aplicativo web ou em qualquer uma das suas ranhuras de implementaçã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ção ou quaisquer outros Serviços de Aplicativo em contêineres.

O Serviço de Aplicações do Azure agora oferece suporte ao Swap com versão preliminar

O Azure App Service agora dá suporte ao Swap com pré-visualização nos seus slots de implantação. Esta é uma maneira válida de validar a aplicação com a configuração de produção antes que a aplicação seja realmente transferida de um slot de preparação para um slot de produção. Isso também garantiria que o slot de destino/produção não sofresse tempo de inatividade.

A tarefa do Serviço de Aplicativo do Azure agora dá suporte a essa troca multifásica por meio das seguintes novas ações:

• Iniciar Troca com Pré-visualização - Começa uma troca com pré-visualização (troca multifásica) e aplica a configuração do slot de destino (por exemplo, o slot de produção) ao slot de origem.
• Troca completa com pré-visualização - Quando estiver pronto para concluir a troca pendente, selecione a ação Concluir Troca com Pré-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 do Registro de Contêiner do Azure e do Docker Hub

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

Melhorias nas aprovações em fluxos de trabalho YAML

Permitimos 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 aplicações 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 arquivos, testes de conteúdo de arquivo e testes de metadados. Você pode usar os resultados no fluxo de trabalho para tomar decisões de prosseguir/não prosseguir. Pode aceder aos dados de teste na execução do pipeline, acompanhados por uma mensagem de erro que o ajudará a solucionar eficazmente as falhas.

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

Dados e resumo dos ensaios

Decoradores de tubulações para tubulações de liberação

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

Temos apoiado decoradores para construções e pipelines YAML, com os clientes usando-os para controlar centralmente as etapas em seus trabalhos. Estamos agora a alargar o apoio também à libertação de gasodutos. 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 versão.

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

Anteriormente, oferecia suporte a implantações apenas no nível do Grupo de Recursos. Com esta atualização, adicionamos suporte para implantar modelos ARM nos níveis de assinatura e grupo de gerenciamento. Isso o ajudará 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.

Recursos de CD para os seus pipelines YAML com vários estágios

Agora pode-se consumir artefactos publicados pelo pipeline de Integração Contínua (CI) e ativar os gatilhos de conclusão do pipeline. Em pipelines YAML de vários estágios, estamos introduzindo pipelines como um recurso. No seu YAML, agora você pode consultar outro pipeline e também ativar gatilhos de CD.

Aqui está o esquema YAML pormenorizado 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 tarefa - download.

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.

Orquestre a estratégia de implantação canária no ambiente para Kubernetes

Uma das principais vantagens da entrega contínua de atualizações de aplicativos é a capacidade de enviar rapidamente atualizações para a produção de microsserviços específicos. Isso lhe dá a capacidade de responder rapidamente às mudanças nos requisitos de negócios. Environment foi introduzido como um conceito de primeira classe que permite orquestrar estratégias de implantação e facilitar lançamentos sem tempo de inatividade. Anteriormente, suportamos a estratégia runOnce que executava as etapas uma vez sequencialmente. Com o suporte para a estratégia canária em pipelines de vários estágios, pode-se agora reduzir o risco realizando uma implementação gradual da alteração em um pequeno subconjunto. À medida que ganha mais confiança na nova versão, pode começar a implementá-la em mais servidores na sua infraestrutura e encaminhar mais utilizadores para a mesma.

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ária para Kuberenetes implantará primeiro as mudanças com 10% pods seguidos por 20% enquanto monitora a saúde durante pósRouteTraffic. Se tudo correr bem, será promovido a 100%.

Estamos à procura de feedback inicial sobre o suporte para recursos de VM em ambientes e executando a estratégia de implantação progressiva em várias máquinas. Entre em contato conosco para inscrever-se.

Políticas de aprovação para pipelines YAML

Nos 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 todos os pipelines que usam o recurso pausam para aprovações antes do início da fase que consome o recurso. É comum que os responsáveis por aplicações com conformidade SOX impeçam que o próprio solicitante da implementação aprove as suas próprias implementaçõ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 acionar o pipeline sempre que uma nova imagem for publicada, poderá usar o recurso de contêiner 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 da imagem ACR podem ser acessados usando variáveis predefinidas. A lista a seguir inclui as variáveis ACR disponíveis para definir um recurso de contêiner 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ções de artefatos em pipelines

Aprimoramos o verificar artefato avaliar para facilitar a adição de políticas a partir de uma lista de definições de políticas pré-definidas. A definição de política será gerada automaticamente e adicionada à configuração de verificação , que pode ser atualizada, se necessário.

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

Pode-se agora definir variáveis de saída nos ganchos de ciclo de vida de um trabalho de implantação e consumi-las em outras etapas e trabalhos subsequentes 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 runOnce estratégia: $[dependencies.<job-name>.outputs['<lifecycle-hookname>.<step-name>.<variable-name>']]
• Para a estratégia canário :$[dependencies.<job-name>.outputs['<lifecycle-hookname>_<increment-value>.<step-name>.<variable-name>']]
• Para estratégia de contínua: $[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 multitarefa

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

Em canais de lançamento clássicos, é comum contar com desdobramentos agendados para atualizações regulares. Mas, quando você tiver uma correção crítica, poderá optar por iniciar uma implantação manual fora da banda. Ao fazer isso, os lançamentos mais antigos continuam a ser agendados. Isso representava um desafio, uma vez que a implantação manual seria revertida quando as implantações fossem retomadas conforme o cronograma. 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ê iniciar manualmente uma implantação. Isso só é aplicável quando a opção de fila é selecionada como "Implantar mais recente e cancelar outros".

Autorização simplificada de recursos em pipelines YAML

Um recurso é tudo aquilo que um pipeline usa e que está fora do próprio pipeline. Os recursos devem ser autorizados antes de poderem ser utilizados. Anteriormente, ao usar recursos não autorizados num pipeline YAML, ocorria um erro de autorização de recursos. Você tinha que autorizar os recursos da página de resumo da execução com falha. Além disso, o pipeline falhava se estivesse 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 sobre os 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 a inspeção de artefatos

Agora você pode definir um conjunto de políticas e adicionar a avaliação de política como uma verificação em um ambiente para artefatos de imagem de contêiner. Quando um pipeline é executado, a execução pausa antes de começar uma fase que utiliza o ambiente. A política especificada é avaliada em relação aos metadados disponíveis para a imagem que está sendo implantada. A verificação passa quando a política é bem-sucedida e marca o estágio como falhado se a verificação falhar.

Atualizações para a tarefa de implantação de modelo ARM

Anteriormente, não filtrávamos as conexões de serviço na tarefa de implantação do modelo ARM. Isso pode resultar na falha da implantação se você estiver selecionando uma conexão de serviço de escopo inferior para executar implantações de modelo ARM para um escopo mais amplo. Agora, adicionamos filtragem de conexões de serviço para filtrar conexões de serviço com escopo mais baixo com base no escopo de implantação escolhido.

ReviewApp no Ambiente

O ReviewApp implanta cada solicitação pull do seu repositório Git em um recurso de ambiente dinâmico. Os revisores podem ver o aspeto dessas alterações, bem como trabalhar com outros serviços dependentes antes de serem integrados na ramificação principal e implantados em produção. Isso tornará fácil para si criar e gerir os recursos do aplicativo de revisão e tirar partido de toda a capacidade de rastreabilidade e diagnóstico das funcionalidades do ambiente. Usando a palavra-chave reviewApp, 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.

A seguir está um trecho YAML de exemplo de uso do reviewApp em ambientes.

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

Colete metadados automáticos e especificados pelo utilizador do pipeline

Agora você pode habilitar a coleta automática e de metadados especificados pelo usuário a partir de tarefas de pipeline. Você pode usar metadados para impor a política de artefactos num ambiente usando a verificação de avaliação de artefacto .

Implantações de VM com ambientes

Um dos recursos mais solicitados em ambientes foram as implantações de VM. Com esta atualização, estamos habilitando o recurso de Máquina Virtual em Ambientes. Agora você pode orquestrar implantações em várias máquinas e executar atualizações de rolantes usando pipelines YAML. Você também pode instalar o agente em cada um dos servidores de destino diretamente e conduzir a implantação contínua para esses servidores. Além disso, você pode usar o catálogo de tarefas completo em suas máquinas 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 máquinas (conjunto contínuo) em cada iteração.

Por exemplo, a implantação contínua abaixo atualiza até cinco destinos em cada iteração. maxParallel determinará o número de alvos que podem ser implantados em paralelo. A seleção leva em conta o número de destinos que devem permanecer disponíveis a qualquer momento, excluindo os destinos para os quais estão sendo implantados. Ele também é usado para determinar as condições de sucesso 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...

Controle adicional de suas implantações

O Azure Pipelines oferece 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 checks automatizados para verificar as políticas de segurança e qualidade. Essas verificações podem ser usadas para acionar operações e, em seguida, aguardar que elas sejam concluídas. 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 verificação pode ser repetida periodicamente com base no intervalo de tentativa especificado para a verificação. Estão agora disponíveis as seguintes verificações adicionais:

• Invoque qualquer API REST e execute a validação com base no corpo da resposta ou em um retorno de chamada do serviço externo
• Invoque uma função do Azure e execute a validação com base na resposta ou em um retorno de chamada da função
• Consultar regras do Azure Monitor para alertas ativos
• Certifique-se de que o pipeline estenda 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 gasoduto possa continuar.

Com esta atualização, os aprovadores recebem uma notificação por e-mail para a aprovação pendente. Os utilizadores e proprietários de equipes podem desativar ou configurar subscrições personalizadas utilizando definições de notificação.

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

Com esse recurso, facilitamos a configuração de pipelines que usam a estratégia de implantação de sua escolha, por exemplo, Rolling, Canaryou Blue-Green. Usando essas estratégias prontas para uso, você pode distribuir atualizações de maneira segura e mitigar os riscos de implantação associados. Para acessar isso, 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 onde o pipeline será criado, o grupo de implantação, o pipeline de compilação que publica o pacote a ser implantado e a estratégia de implantação de sua escolha. Ir em frente configurará um pipeline totalmente funcional que implanta o pacote selecionado nesta máquina virtual.

Para obter mais detalhes, consulte nossa documentação sobre configuração de estratégias de implantação.

Parâmetros de tempo de execução

Os parâmetros de tempo de execução 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 tempo de execução têm tipos de dados e não se tornam automaticamente variáveis de ambiente. Com parâmetros de tempo de execução, você pode:

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

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

Usar a palavra-chave extends em pipelines

Atualmente, os dutos podem ser transformados em modelos, promovendo a reutilização e reduzindo o clichê. A estrutura geral do pipeline ainda era definida pelo arquivo YAML raiz. Com esta atualização, adicionamos uma maneira mais estruturada de usar modelos de pipeline. Um arquivo YAML raiz agora pode usar a palavra-chave estende para indicar que a estrutura principal do pipeline 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á uma compilação, 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 }}

Variáveis de controle que podem ser substituídas no tempo 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 certas variáveis como _settable at queue time_, o sistema não impôs isso, nem impediu que outras variáveis fossem definidas. Em outras palavras, a configuração foi usada apenas para solicitar entradas adicionais ao iniciar uma nova execução.

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

Novas variáveis predefinidas no pipeline YAML

As variáveis oferecem uma maneira conveniente de introduzir partes importantes de dados em várias partes do seu pipeline. Com esta atualização, adicionamos algumas variáveis predefinidas a um trabalho de implantação. Essas variáveis são definidas automaticamente pelo sistema, têm escopo no trabalho específico de implantação e são somente leitura.

• Environment.Id - A ID do ambiente.
• Environment.Name - O nome do ambiente visado pelo trabalho de implantação.
• Environment.ResourceId - O ID do recurso no ambiente de destino da tarefa de implantação.
• Environment.ResourceName - O nome do recurso no ambiente visado pelo trabalho de implantação.

Obter vários repositórios

Os pipelines geralmente dependem de vários repositórios. Você pode ter diferentes repositórios com código-fonte, ferramentas, scripts ou outros itens necessários para criar seu código. Anteriormente, você tinha que adicionar esses repositórios como submódulos ou como scripts manuais para executar git checkout. Agora você pode buscar e verificar outros repositórios, além daquele 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 Tools, 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 sources.

Os repositórios Git do Azure Repos são suportados. Para obter mais informações, consulte o checkout Multi-repo em .

Obtendo detalhes em tempo de execução sobre vários repositórios

Quando um pipeline está em execução, o Azure Pipelines adiciona informações sobre o repositório, a ramificação e a confirmação que dispararam a execução. Agora que os pipelines YAML suportam a verificação de vários repositórios, poderá também querer saber o repositório, a ramificação e a confirmação que foram verificados para cada um dos outros repositórios. Esses dados estão disponíveis por meio de uma expressão de tempo de execução, que agora você pode mapear em 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 do Azure Repos

Anteriormente, quando você fazia referência a repositórios em um pipeline YAML, todos os repositórios do Azure Repos precisavam 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 repos, self e otherrepo, acabarão verificados.

Metadados de recursos de pipeline como variáveis predefinidas

Adicionámos variáveis predefinidas para recursos de pipelines YAML no processo. 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 compilação na tarefa do KubernetesManifest

kustomize (parte do Kubernetes sig-cli) permite que você personalize arquivos YAML brutos e sem modelos para várias finalidades e deixa o YAML original intocado. Uma opção para kustomize foi adicionada na ação de bake da tarefa KubernetesManifest, para que qualquer pasta contendo arquivos kustomization.yaml possa ser usada para gerar os arquivos de manifesto utilizados na ação de deploy 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 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 de usuário do cluster para implantações. Isso resultou em prompts de logon interativos e pipelines com falha para um cluster com RBAC ativado, 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 pela tarefa ao executar comandos como build.

Aprimoramentos de tarefas de lançamento do GitHub

Fizemos vários aprimoramentos na tarefa de lançamento do GitHub. Agora pode ter um melhor controlo sobre a criação da versão, utilizando o campo de padrão de tags ao especificar uma expressão regular de tag. A versão será criada apenas quando o commit de ativação estiver marcado 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 com a qual a versão atual deve ser comparada. O lançamento em comparação com o pode ser o último lançamento completo (excluindo pré-lançamentos), o último lançamento que não seja rascunho, ou qualquer lançamento anterior correspondente à tag de lançamento fornecida. Além disso, a tarefa fornece o campo de tipo de changelog para formatar o log de alterações. Com base na seleção, o changelog exibirá uma lista de commits ou uma lista de problemas/RPs categorizados com base em rótulos.

Tarefa de instalação do Open Policy Agent

O Open Policy Agent é um mecanismo de política de uso geral de código aberto que permite a aplicação de políticas unificadas e sensíveis ao contexto. Adicionámos a tarefa de instalação do Open Policy Agent. É particularmente útil para a aplicação de políticas em ambiente de pipeline relativamente a fornecedores de Infraestrutura como Código.

Por exemplo, o Open Policy Agent pode avaliar arquivos de políticas de Rego e planos Terraform em pipeline.

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

Suporte para scripts do PowerShell na tarefa CLI do Azure

Anteriormente, você podia executar scripts em lote e bash como parte de uma tarefa da CLI do Azure. Com esta atualização, adicionámos suporte para scripts do PowerShell e do PowerShell Core à tarefa.

Implantações canárias baseadas em Service Mesh Interface na tarefa KubernetesManifest

Anteriormente, quando a estratégia canary era especificada na tarefa KubernetesManifest, a tarefa criava cargas de trabalho padrão e canary cujas réplicas equivaliam a uma porcentagem das réplicas usadas para cargas de trabalho estáveis. Isso não era exatamente o mesmo que dividir o tráfego até a porcentagem desejada no nível de solicitação. Para resolver isso, adicionamos suporte para Service Mesh Interface implantações canárias baseadas na tarefa KubernetesManifest.

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

A seguir está um exemplo de execução de implantações canárias baseadas em SMI de forma 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 oferece suporte ao AzCopy V10

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

O comando azcopy copy suporta apenas os argumentos associados a ele. Devido à alteração na sintaxe do AzCopy, alguns dos recursos existentes não estão disponíveis no AzCopy V10. Estes incluem:

• Especificando o local do log
• Limpeza de ficheiros de log e plano após a cópia
• Retomar processo de cópia se o trabalho falhar

Os recursos adicionais suportados 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
• Definir a verbosidade do ficheiro de log através da passagem de um argumento

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

Cada trabalho executado no Azure Pipelines recebe um token de acesso. O token de acesso é usado pelas tarefas e pelos seus scripts para realizar chamadas de retorno ao Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, carregar logs, resultados de teste, artefatos ou para fazer chamadas REST no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído. Com esta atualização, adicionámos as seguintes melhorias.

• 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 projeto de equipe. Você pode alterar o escopo para ser o projeto de equipe em pipelines de construção clássicos. No entanto, vocês não tinham esse controlo para pipelines de lançamento clássicas ou YAML. Com esta atualização, estamos introduzindo uma configuração de coleção para garantir que cada tarefa obtenha um token com escopo de projeto, independentemente da configuração do 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 de 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 seus pipelines acessarem recursos que estão fora do projeto de equipe usando tokens de acesso. Para atenuar falhas de pipeline, você pode conceder explicitamente Conta de Serviço de Criação de Projeto acesso ao recurso desejado. Recomendamos vivamente que ative estas definições de segurança.

• Limitar o acesso ao escopo de repositórios de serviço de compilação

  Com base na melhoria contínua da segurança do pipeline por meio da restrição do escopo do token de acesso, o Azure Pipelines agora pode limitar seu acesso ao repositório, abrangendo somente os repositórios necessários para um pipeline baseado em YAML de . Isso significa que, se o token de acesso dos pipelines vazasse, ele apenas teria acesso aos repositório(s) usado(s) no pipeline. Anteriormente, o token de acesso era bom para qualquer repositório do Azure Repos 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á-lo em Configurações de coleções >Pipelines>Configurações. Ao usar esse recurso, todos os repositórios necessários para a compilação (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 para o token de acesso, uma dessas permissões é Fila compila. Com esta atualização, removemos essa permissão para o token de acesso. Se os seus pipelines precisarem desta permissão, podes concedê-la explicitamente à Conta de Serviço de Compilação do Project Build ou à Conta de Serviço de Compilação de Coleção de Projetos , dependendo do token que usares.

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

Adicionamos segurança em nível de 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.

Segmentação de etapas e isolamento de comandos

O Azure Pipelines dá suporte à execução de trabalhos em contêineres ou no host do agente. Anteriormente, um trabalho inteiro era atribuído a uma dessas duas metas. Agora, etapas individuais (tarefas ou scripts) podem ser executadas no destino escolhido. As etapas também podem ter como alvo outros contêineres, de modo que um pipeline pode executar cada etapa em um contêiner especializado e construído especificamente para esse fim.

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

Aqui está um exemplo abrangente, mostrando etapas em 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 de leitura apenas

As variáveis do sistema foram documentadas como sendo imutáveis, mas na prática podiam ser substituídas por uma tarefa e as tarefas a jusante captariam o novo valor. Com esta atualização, reforçamos a segurança em torno das variáveis de pipeline para tornar as variáveis de sistema e de tempo de fila somente leitura. Além disso, pode-se tornar uma variável YAML apenas de leitura marcando-a da seguinte forma.

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

Acesso baseado em função de utilizador para ligações a serviços

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

Como parte deste trabalho, introduzimos as novas funções de Leitor, Utilizador, 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 de forma segura.

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

Rastreabilidade de oleodutos e recursos ACR

Garantimos total rastreabilidade E2E quando pipelines e recursos de contêineres ACR são usados em um pipeline. Para cada recurso consumido pelo pipeline YAML, pode-se rastrear as confirmações, os itens de trabalho e os artefatos.

No modo de exibição resumo de execução do pipeline, você pode ver:

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

  

• O compromete 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 utilizados pelo processo.

  

Na visualização de implantações do ambiente, você pode ver as confirmações e os itens de trabalho para 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 relatório de teste e análise. Até agora, havia um limite de 100 MB para anexos de execução de testes e dos resultados dos testes. Isso limitou o upload de arquivos grandes, como crash dumps ou vídeos. Com esta atualização, adicionamos suporte para anexos de teste grandes, permitindo que você tenha todos os dados disponíveis para solucionar problemas de seus testes reprovados.

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 compilações auto-hospedadas ou agentes de liberação atrá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 este problema, recomendamos que atualize o firewall para solicitações de saída para https://*.vstmrblob.vsassets.io. Você pode encontrar informações sobre solução de problemas na documentação aqui. ​

Mostrar informações corretas do pool em cada tarefa

Anteriormente, quando se usava uma matriz para expandir tarefas ou uma variável para identificar um pool, às vezes as informações incorretas do pool eram resolvidas nas páginas de registos. Estas questões foram resolvidas.

Gatilhos de IC para novas filiais

Tem sido uma solicitação pendente há muito tempo para não acionar compilações de CI quando uma nova ramificação é criada e quando essa ramificação não tem alterações. Considere os seguintes exemplos:

• Use a interface da Web para criar uma nova ramificação com base em uma ramificação existente. Isso acionaria imediatamente uma nova compilação de CI se o filtro de ramificação correspondesse ao nome da nova ramificação. Isso é indesejado porque o conteúdo da nova ramificação é o mesmo quando comparado com a ramificação existente.
• Você tem um repositório com duas pastas - app e docs. Você configura um filtro de caminho para CI para corresponder a "app". Em outras palavras, você não deseja criar uma nova compilação se uma alteração tiver sido enviada por push para o docs. Você cria uma nova ramificação localmente, faz algumas alterações nos documentos e, em seguida, envia essa ramificação para o servidor. Costumávamos acionar uma nova compilação 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 ramificação, parece que uma alteração também foi feita na pasta do aplicativo.

Agora, temos uma maneira melhor de lidar com a Integração Contínua para novas ramificações, de modo a resolver estes problemas. Quando você publica uma nova ramificação, procuramos explicitamente novas confirmações nessa ramificação e verificamos se elas correspondem aos filtros de caminho.

Os trabalhos podem aceder a 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. Isto ajuda a transmitir informações úteis, como uma decisão de avançar/no-go ou o ID de um resultado gerado, de uma fase para a próxima. O resultado (status) de uma etapa anterior e os respetivos trabalhos está também disponível.

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

Desativar atualizações automáticas de agentes a 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 requer uma versão mais recente do agente para funcionar corretamente. Com esta atualização, estamos adicionando a capacidade de desativar 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 atualizem. Esse recurso é de interesse principalmente para clientes com pools auto-hospedados e requisitos de controle de alterações muito rigorosos. As atualizações automáticas são ativadas por padrão e não recomendamos que a maioria dos clientes as desative.

Diagnóstico do agente

Adicionamos diagnósticos 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 o diagnóstico, use run.sh --diagnostics ou run.cmd --diagnostics no Windows.

Ganchos de serviço para pipelines YAML

A integração de serviços com pipelines YAML ficou mais fácil. Ao utilizar eventos de ganchos de serviço para pipelines YAML, agora é possível conduzir atividades em aplicações ou serviços personalizados com base no progresso das execuções dos pipelines. Por exemplo, você pode criar um tíquete de helpdesk 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 um estágio falhar.

A filtragem no nome do pipeline e no nome da etapa é suportada 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 da etapa.

Integração Optimizely

O Optimizely é uma poderosa plataforma de testes A/B e sinalização de recursos para equipes de produtos. A integração dos Pipelines do Azure com a plataforma de experimentação Optimizely permite que as equipes de produtos testem, aprendam e implantem em um ritmo acelerado, enquanto obtêm todos os benefícios de DevOps dos Pipelines do Azure.

A extensão Optimizely para Azure DevOps adiciona etapas de experimentos e sinalizadores de funcionalidades aos pipelines de compilação e lançamento, permitindo-lhe iterar continuamente, implementar funcionalidades e revertê-las usando o Azure Pipelines.

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

Adicionar um lançamento do GitHub como fonte de artefato

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

Ao clicar em Adicionar um artefacto na definição do pipeline de lançamento, encontrará o novo tipo de origem GitHub Release. 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 o lançamento no GitHub, como a versão mais recente, uma versão de tag específica, ou selecionar no momento da criação da versão. Uma vez que uma versão do GitHub é vinculada, ela é automaticamente baixada e disponibilizada em seus trabalhos de lançamento.

Integração do Terraform com o Azure Pipelines

Terraform é uma ferramenta de código aberto para desenvolver, alterar e versionar a infraestrutura de forma segura e eficiente. O Terraform codifica APIs em arquivos de configuração declarativa, 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, Amazon Web Services (AWS) e Google Cloud Platform (GCP).

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

Integração com Google Analytics

A estrutura de experiências do Google Analytics permite-lhe testar praticamente qualquer alteração ou variação num Website ou aplicação para medir o seu impacto num 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 rejeição). Essas atividades permitem que você identifique as mudanças que valem a pena implementar com base no impacto direto que elas têm no desempenho do seu recurso.

A extensão para experimentos do Google Analytics para o Azure DevOps adiciona etapas de experimentação aos pipelines de compilação e lançamento, permitindo iterar, aprender e implantar de forma contínua e a um ritmo acelerado, ao mesmo tempo que gere os experimentos de forma contínua, obtendo todos os benefícios com DevOps dos Pipelines do Azure.

Pode baixar a extensão de experiências do Google Analytics da 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 esta atualização, você pode integrar com a versão de Nova York do ServiceNow. A autenticação entre os dois serviços agora pode ser feita usando OAuth e autenticação básica. Além disso, agora você pode configurar critérios avançados de sucesso para poder usar qualquer propriedade de alteração para decidir o resultado do gate.

Criar pipelines do Azure a partir do VSCode

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

Gestão e resolução de bugs instáveis

Introduzimos a gestão de testes instáveis para suportar o ciclo de vida completo com deteção, relatórios e resolução. Para melhorá-lo ainda mais, estamos adicionando gerenciamento e resolução de bugs em testes intermitentes.

Ao investigar o teste intermitente, pode criar um bug usando a ação Bug que pode ser atribuída a um programador para investigar a causa raiz do teste intermitente. O relatório de erro 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 erro é resolvido ou fechado, removeremos automaticamente a marca de instável do teste.

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

A tarefa VSTest descobre e executa testes usando entradas do 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. 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 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 que a tarefa seja aprovada.

A opção VSTest TestResultsDirectory está disponível na interface de utilizador da tarefa

A tarefa VSTest armazena resultados de teste e arquivos associados na pasta $(Agent.TempDirectory)\TestResults. 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á-los.

Suporte a Markdown em mensagens de erro de testes automatizados

Adicionámos suporte a markdown às mensagens de erro para testes automatizados. Agora é possível formatar facilmente as mensagens de erro tanto para a execução como para os resultados dos testes, melhorando a legibilidade e facilitando a resolução de problemas nos casos de falhas em testes no Azure Pipelines. A sintaxe de markdown suportada pode ser encontrada aqui.

Use decoradores de pipeline para injetar etapas automaticamente em uma tarefa de implantação

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

Além disso, os trabalhos de implantação podem ser executados como um de trabalho de contêiner juntamente com de side-car de serviços de se definido.

Planos de Teste

Página de Novo Plano de Teste

Uma nova Página de Planos de Teste (Planos de Teste *) está disponível para todas as coleções de DevOps do Azure. A nova página fornece visualizações simplificadas para ajudá-lo a se concentrar na tarefa em questão - planejamento, criação ou execução de testes. Também está livre de desordem e é consistente com o resto da oferta do Azure DevOps.

Ajude-me a entender a nova página

A nova página Planos de Teste tem um total de 6 seções, das quais as 4 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, favoritar, editar, copiar ou clonar um plano de teste.
2. Árvore de conjuntos de testes: Use isso para adicionar, gerenciar, exportar ou solicitar conjuntos de testes. Aproveite isso para também atribuir configurações e executar testes de aceitação do usuário.
3. Guia Definir: Agrupar, adicionar e gerir casos de teste num conjunto de testes à sua escolha por meio desta guia.
4. separador Executar: Atribua e execute testes neste separador ou localize um resultado de teste para analisar detalhadamente.
5. guia Gráfico: Acompanhe a execução e o status do teste por meio de gráficos que também podem ser fixados em painéis.
6. Extensibilidade: Suporta os pontos de extensibilidade atuais dentro do produto.

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

1. Cabeçalho do plano de teste

Tarefas

O cabeçalho Plano de Teste permite executar as seguintes tarefas:

• Marcar um plano de teste como favorito
• Desmarcar um plano de teste favorito
• Navegue facilmente entre os seus planos de teste favoritos
• Visualize o caminho de iteração do plano de teste, que indica claramente se o plano de teste é Atual ou Passado
• Exiba o resumo rápido do relatório de progresso do teste com um link para navegar até o relatório
• Volte para a página de Planos de Teste Todos/Meus

Opções do menu de contexto

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

• Copiar plano de teste: Esta é uma nova opção que permite copiar rapidamente o plano de teste atual. Mais detalhes abaixo.
• Editar plano de teste: Esta opção permite editar o formulário do item de trabalho Plano de teste para gerir os campos do item de trabalho.
• Configurações do plano de teste: Esta opção permite que você defina as configurações de Execução de Teste (para associar pipelines de compilação ou liberação) e as configurações de Resultados de Teste

Copiar plano de teste (nova funcionalidade)

Recomendamos a criação de um novo Plano de Teste por sprint/release. 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 o recurso 'Copiar plano de teste' na nova página. Ao aproveitá-lo, 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 o uso de planos de teste, consulte aqui.

2. Árvore de suítes de teste

Tarefas

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

• Expandir/recolher: As opções da barra de ferramentas permitem expandir ou recolher a árvore de hierarquia do conjunto.
• Mostrar pontos de teste de suítes infantis: Esta opção da barra de ferramentas só é visível quando você está na guia "Executar". Isso permite que você visualize todos os pontos de teste para uma determinada suíte e seus filhos em uma visualização para facilitar o gerenciamento de pontos de teste sem ter que navegar para suítes individuais, uma de cada vez.
• Ordenar suítes: Você pode arrastar/soltar suítes para reordenar a hierarquia de suítes ou movê-las de uma hierarquia de suítes para outra dentro do plano de teste.

Opções do menu de contexto

O menu de contexto na árvore Test suites fornece as seguintes opções:

• Criar novas suítes: Você pode criar 3 tipos diferentes de suítes da seguinte maneira:
  • Use o conjunto estático ou o conjunto de pastas para organizar os teus testes.
  • Utilize o conjunto de ferramentas baseado em requisitos para vincular diretamente aos requisitos/histórias de utilizadores, assegurando uma rastreabilidade contínua.
  • Utilize consultas para organizar dinamicamente casos de teste que correspondam a um critério de consulta.
• Atribuir configurações: Você pode atribuir configurações para o pacote (por 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 este pacote.
• Exportar como pdf/e-mail: Exporte as propriedades do plano de teste, as propriedades do conjunto de testes, juntamente com os detalhes dos casos de teste e pontos de teste como "e-mail" ou "imprimir em pdf".
• Abrir item de trabalho da suíte de testes: Esta opção permite-lhe editar o formulário do item de trabalho da suíte de testes para gerir os campos do item de trabalho.
• Atribuir testadores para executar todos os testes: Esta opção é muito útil para cenários de teste de aceitação do usuário (UAT) onde 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 tab

A guia Definir permite agrupar, adicionar e gerir casos de teste para uma suíte de testes. A aba executar é utilizada para atribuir pontos de teste e executá-los.

O separador Definir e determinadas operações só estão disponíveis para utilizadores com nível de acesso Básico + Planos de Teste ou equivalente. Todo o resto deve ser exercitável por um utilizador com nível de acesso 'Básico'.

Tarefas

A guia Definir permite executar as seguintes tarefas:

• Adicionar novo caso de teste usando o formulário de item de trabalho: Esta opção permite criar um novo caso de teste usando o formulário de item de trabalho. O caso de teste criado será automaticamente adicionado ao pacote.
• Adicionar Novo caso de teste usando a grade: Esta opção permite criar um ou mais casos de teste utilizando a visão em grade de casos de teste. Os casos de teste criados serão automaticamente adicionados ao pacote.
• Adicionar casos de teste existentes usando uma consulta: Esta opção permite adicionar casos de teste existentes ao pacote especificando uma consulta.
• Ordene casos de teste por arrastar e largar: Pode reordenar casos de teste ao arrastar e largar um ou mais casos de teste dentro de uma dada suite. 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 uma suite para outra: Usando arrastar/soltar, pode-se mover casos de teste de uma suite de testes para outra.
• Mostrar grelha: Pode usar o modo grelha para visualizar/editar casos de teste juntamente com passos de teste.
• Visualização em tela cheia: Você pode visualizar o conteúdo de toda a guia Definir em um modo de tela cheia usando esta opção.
• Filtragem: Usando a barra de filtro, você pode filtrar a lista de casos de teste usando os campos de "título do caso de teste", "atribuído a" e "estado". Você também pode classificar a lista clicando nos cabeçalhos das colunas.
• 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 de caso de teste.

Opções do menu de contexto

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

• Abrir/editar formulário de item de trabalho de caso de teste: Esta opção permite editar um caso de teste específico usando o formulário de item de trabalho, onde se podem editar os campos do item de trabalho, incluindo as etapas de teste.
• Editar casos de teste: Esta opção permite editar em massa os campos do item de trabalho do caso de teste. No entanto, você não pode usar essa opção para editar etapas de teste em massa.
• Editar casos de teste em grade: Esta opção permite que você edite em massa os casos de teste selecionados, incluindo etapas de teste usando a exibição de grade.
• Atribuir configurações: Esta opção permite que você substitua as configurações de nível de suíte por configurações de nível de caso de teste.
• Remover casos de teste: Esta opção permite remover os casos de teste da suíte fornecida. No entanto, ele não altera o item de trabalho do caso de teste subjacente.
• Criar uma cópia/clone de casos de teste: Esta opção permite criar uma cópia/clone de casos de teste selecionados. Veja abaixo mais detalhes.
• Exibir itens vinculados: Esta opção permite que você examine os itens vinculados para um determinado caso de teste. Veja abaixo mais detalhes.

Casos de teste de cópia/clonagem (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 nos quais criar o caso de teste de cópia/clonado. Além disso, podes especificar se desejas incluir os links/attachments existentes na cópia clonada.

Exibir itens vinculados (novo recurso)

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

4. Executar separador

A guia Definir permite agrupar, adicionar e gerir casos de teste para uma suíte de testes. A aba executar é utilizada 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, então o(s) ponto(s) de teste são gerados. Um ponto de teste é uma combinação única de caso de teste, conjunto de testes, configuração e testador. Exemplo: se você tiver um caso de teste como "Funcionalidade de login de teste" e adicionar 2 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. Através da visualizaçã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 para o ponto de teste é o que você vê na guia executar.
Assim, os casos de teste são entidades reutilizáveis. Ao incluí-los em um plano ou conjunto de testes, 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 utilizadores que fazem principalmente a execução/rastreamento de testes (apenas precisam ter o nível de acesso 'Básico'), não ficam sobrecarregados pela complexidade do gerenciamento do pacote (o separador de definição fica oculto para esses utilizadores).

O separador Definir e determinadas operações só estão disponíveis para utilizadores com nível de acesso Básico + Planos de Teste ou equivalente. Todo o resto, incluindo o separador "Executar", deve ser exercitável por um utilizador com nível de acesso 'Básico'.

Tarefas

A guia Executar permite executar as seguintes tarefas:

• Pontos de teste de marcação em massa: Esta opção permite marcar rapidamente o resultado dos pontos de teste - aprovados, reprovados, bloqueados ou não aplicáveis, sem ter de executar o caso de teste através da ferramenta de execução de testes. O resultado pode ser marcado para um ou vários pontos de teste ao mesmo tempo.
• Executar pontos de teste: Esta opção permite que você execute os casos de teste passando individualmente por cada etapa de teste e marcando-os como aprovado/reprovado 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 "Desktop Runner" para testar aplicativos desktop e/ou web. Você também pode selecionar a opção "Executar com opções" para especificar uma compilação contra a qual deseja realizar o teste.
• 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 Executado por, Testador Atribuído, Configuração, etc.
• Visualização em tela cheia: Você pode visualizar o conteúdo de toda a guia Executar em um modo de tela cheia usando esta opção.
• Filtragem: Usando a barra de filtro, você pode filtrar a lista de pontos de teste usando os campos de "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 das colunas.

Opções do menu de contexto

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

• Marcar o resultado do teste: O mesmo que acima, permite que você marque rapidamente o resultado dos pontos de teste - aprovado, reprovado, bloqueado ou não aplicável.
• Executar pontos de teste: O mesmo que acima, permite-lhe executar os conjuntos de teste através do executador de testes.
• Redefinir teste paraativo: Esta opção permite que você redefina o resultado do teste para ativo, ignorando assim o último resultado do ponto de teste.
• Abrir/editar formulário de item de trabalho de caso de teste: Esta opção permite editar um caso de teste específico usando o formulário de item de trabalho, onde se podem editar os campos do item de trabalho, incluindo as etapas de teste.
• Atribuir testador: Esta opção permite atribuir pontos de teste aos testadores para a execução do teste.
• Ver resultado do teste: Esta opção permite visualizar os detalhes mais recentes do resultado do teste, incluindo o resultado de cada etapa do teste, comentários adicionados ou bugs registados.
• Exibir histórico de execução: Esta opção permite visualizar todo o histórico de execução para o ponto de teste selecionado. Ele abre uma nova página onde você pode ajustar os filtros para visualizar 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 de progresso dos planos de teste

Este relatório pronto para uso ajuda você a acompanhar a execução e o status de um ou mais Planos de Teste em um projeto. Visite Planos de teste > Relatório de progresso* para começar a usar o relatório.

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

1. Resumo: mostra uma vista 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 detalhar cada plano de teste e fornece análises importantes para cada conjunto de testes.

Artefatos

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

Agora você pode ver os detalhes das informações de licença para pacotes NuGet armazenados no Azure Artifacts enquanto navega por pacotes no Visual Studio. Isso se aplica a licenças que são representadas usando expressões de licença ou licenças incorporadas. 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).

Clicando no link irá levá-lo para uma página web onde você pode ver os detalhes da licença. Essa experiência é a mesma para expressões de licença e licenças incorporadas, para que você possa ver os detalhes da licença para pacotes armazenados nos Artefatos do Azure em um só lugar (para pacotes que especificam informações de licença e são suportados pelo Visual Studio).

Tarefas de autenticação leves

Agora você pode 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 funcionalidades, 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 capaz de usá-los em seu Pipeline. Agora, você pode usar scripts de seu próprio design em seu pipeline YAML 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 quaisquer comandos suportados pelo Azure Pipelines YAML. Isso permite que você tenha controle total da invocação de comandos e facilita o uso de scripts compartilhados em sua configuração de pipeline. Para obter mais informações, consulte o NuGet, npm, PIP, Twinee Maven documentação da tarefa de autenticação.

Melhorias no tempo de carregamento da página de feed

Temos o prazer de anunciar que melhoramos o tempo de carregamento da página de feed. Em média, os tempos de carregamento das páginas de feed diminuíram por 10%. Os maiores feeds viram a maior melhoria: o tempo de carregamento da página de alimentação do percentil 99 (tempos de carregamento nos 99% mais altos de todos os feeds) diminuiu em 75%.

Disponibilize os seus pacotes publicamente através de 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 ou não na sua coleção ou até mesmo conectados a uma coleção do Azure DevOps. Saiba mais sobre feeds públicos na nossa documentação de feeds ou vá diretamente para o nosso tutorial para partilhar pacotes publicamente.

Configurar upstreams em diferentes coleções dentro de um tenant do AAD

Agora pode adicionar um feed em outra coleção associada ao seu locatário do Azure Active Directory (AAD) como uma fonte principal para o seu feed de Artefatos. Seu feed pode localizar 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 Python para autenticar pip e twine com feeds do Azure Artifacts

Agora você pode instalar e usar o Provedor de Credenciais Python (artifacts-keyring) para configurar automaticamente a autenticação e publicar ou consumir pacotes Python a partir de ou para um alimentador de Artefatos do Azure. Com o provedor de credenciais, você não precisa configurar nenhum arquivo de configuração (pip.ini/pip.conf/.pypirc), você simplesmente será levado através de um fluxo de autenticação em seu navegador da Web ao chamar pip ou twine pela primeira vez. Veja mais informações em a documentação.

Feeds de Artefactos do Azure no Gestor de Pacotes do Visual Studio

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

Experiência de conexão ao feed atualizada

A caixa de diálogo Conectar ao feed é a porta de entrada para usar os Artefatos do Azure; ele contém informações sobre como configurar clientes e repositórios para enviar e extrair pacotes de feeds no Azure DevOps. Atualizámos a caixa de diálogo para adicionar informações detalhadas de configuração e expandimos as ferramentas para as quais damos instruções.

Os feeds públicos estão agora geralmente disponíveis com suporte upstream

A visualização pública de feeds públicos teve uma grande aceitação e recebeu muitos comentários. Nesta versão, tornámos recursos adicionais disponíveis para uso geral. Agora, você pode definir um feed público como uma fonte upstream de um feed privado. Você pode manter os seus arquivos de configuração simples, sendo capaz de enviar e receber dados tanto para feeds privados quanto para feeds com escopo de projeto.

Criar feeds com escopo de projeto a partir do portal

Quando lançamos feeds públicos, também lançamos feeds de escopo de projeto . Até agora, os feeds com escopo de 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 a partir de qualquer projeto, se tiver as permissões necessárias. Você também pode ver quais feeds são de 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 de Artefatos do Azure. Isso nos ajudou a alcançar uma redução de até 10 vezes na latência para algumas das APIs mais usadas para npm.

Melhorias de acessibilidade

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

• Criar experiência de feed
• Experiência de configurações globais de feed
• Conecte-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 Repo não está otimizado para edição de markdown.

Agora você pode editar uma página wiki de código no editor lado a lado dentro da wiki. Isso permite que você use a barra de ferramentas de marcação 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 repositórios no menu de contexto.

Criar e incorporar itens de trabalho a partir de uma página wiki

Enquanto ouvíamos seus comentários, ouvimos que você usa o wiki para capturar documentos de brainstorming, documentos de planejamento, ideias sobre recursos, documentos de especificação, atas de reunião. Agora você pode facilmente criar recursos e histórias de usuários 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 onde deseja incorporar o item de trabalho e selecione Novo item de trabalho. Isso economiza tempo, já que você não precisa criar o item de trabalho primeiro, vá para editar e, em seguida, encontre o item de trabalho para incorporá-lo. Também reduz a mudança de contexto, pois não se sai do escopo do wiki.

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

Comentários em páginas wiki

Anteriormente, você não tinha uma maneira de interagir com outros usuários da wiki dentro da wiki. Isso tornou a colaboração no conteúdo e a resposta às perguntas um desafio, já que as conversas tinham que acontecer por e-mail ou canais de bate-papo. Com comentários, agora você pode colaborar com outras pessoas diretamente dentro do wiki. Você pode aproveitar a funcionalidade @mention usuários dentro dos comentários para chamar a atenção de outros membros da equipe. Este recurso foi priorizado com base neste ticket de sugestão . Para mais informações sobre comentários, consulte a 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 de código wiki, isso fez 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 assim a desordem desnecessária.

Este recurso foi priorizado com base neste ticket de sugestão .

URLs de páginas Wiki curtas e legíveis

Você não precisa mais usar um URL de várias linhas para compartilhar links de páginas wiki. Estamos aproveitando os IDs de página no URL para remover parâmetros, tornando o URL mais curto e fácil de ler.

A nova estrutura de URLs terá a seguinte aparência:

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

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

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

Isso foi priorizado com base no tíquete de sugestão de funcionalidade número da Comunidade de Desenvolvedores.

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

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

Visitas a páginas wiki

Agora você pode obter informações sobre as visitas de páginas wiki. A API REST permite que você acesse 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 informações específicas, como páginas mais visualizadas.

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

Apresentação de relatórios

Relatórios sobre falhas 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. Adicionámos dois novos relatórios para fornecer informações sobre os seus pipelines.

1. O relatório de falhas do pipeline mostra a taxa de sucesso de build e a tendência de falha. Além disso, ele também mostrará a tendência de falhas nas tarefas para fornecer informações sobre qual tarefa no pipeline está a contribuir para o maior número de falhas.

2. O relatório sobre a duração do pipeline mostra a tendência do tempo que demora a execução de um pipeline. Ele também mostra quais tarefas no pipeline estão levando mais tempo.

Melhoria do widget Resultados da Consulta

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

Com esta atualização, incluímos muitas melhorias há muito esperadas:

• Agora você pode selecionar quantas colunas quiser exibir no widget. Chega de limite de 5 colunas!
• O widget suporta todos os tamanhos, de 1x1 a 10x10.
• Quando redimensionares uma coluna, a largura da coluna ficará guardada.
• Você pode expandir o widget para a visualização em tela cheia. Quando expandido, ele exibirá todas as colunas retornadas pela consulta.

Filtragem avançada para widgets de Lead e Tempo de Ciclo

Os tempos de lead e de ciclo são usados pelas equipas para verem quanto tempo leva para o trabalho fluir através dos seus canais de desenvolvimento e, finalmente, entregar valor aos seus clientes.

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

Com esta atualização, perguntas como esta podem ser respondidas filtrando pela faixa do quadro.

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

Gráfico de burndown linear de sprint usando pontos de história

O teu Sprint Burndown agora pode ser reduzido por histórias. Isso aborda os seus comentários da Comunidade de Desenvolvedores.

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

1. Selecionar lista de pendências do Stories
2. Selecione para fazer o burndown em Soma dos Pontos de História

Um widget Sprint Burndown com tudo o que você tem pedido

O novo widget Sprint Burndown suporta a redução por Pontos de História, pela contagem de Tarefas ou pela soma de campos personalizados. Você pode até criar um burndown de sprint para Recursos ou Épicos. O widget exibe burndown médio, % concluído e aumento do escopo. Você pode configurar a equipe, permitindo que você exiba burndowns de sprint para várias equipes no mesmo painel. Com todas estas fantásticas informações para apresentar, permitimos redimensioná-las até 10x10 no painel de instrumentos.

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

Miniatura integrada de burndown de sprint

O Sprint Burndown está de volta! Alguns sprint atrás, removemos o burndown de sprint no contexto dos cabeçalhos Sprint Burndown e Taskboard. Com base nos seus comentários, melhorámos e reintroduzimos a miniatura de burndown do sprint.

Clicar na miniatura exibirá imediatamente uma versão maior do gráfico com uma opção para visualizar o relatório completo na guia Análise. Quaisquer alterações feitas no relatório completo serão refletidas no gráfico exibido no cabeçalho. Assim, agora pode configurá-lo para redução baseada em histórias, pontos de história ou pela contagem de tarefas, em vez de apenas na quantidade de trabalho restante.

Criar um painel sem uma equipe

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

Um Painel do Projeto é como um Painel de Equipe, exceto que não está associado a uma Equipe e você pode decidir quem pode editar/gerenciar o painel. 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.

Feedback

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