Notas de versão do Azure DevOpsServer 2020 Update 1

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 de DevOps do Azure, visite a página Downloads do Servidor de DevOps do Azure.

A atualização direta para o Azure DevOps Server 2020 é suportada pelo Azure DevOps Server 2019 ou Team Foundation Server 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 um novo modelo de retenção de execução de pipeline (compilação) que funciona com base em configurações no nível do projeto .

O Azure DevOps Server 2020 lida com a retenção de compilação de forma diferente, com base em políticas de retenção no nível de 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 1.2 Patch 15 Data de lançamento: 11 de março de 2025

Ficheiro	SHA-256 Hash
devops2020.1.2patch15.exe	66B6FDE4949C0B7A87B20F3BC8E0673774401929D8B75E37F599DFF8BA74ABE5

Lançamos Patch 15 para a Atualização 1.2 do Azure DevOps Server 2020 para incluir o seguinte:

• Atualizar tarefas devido à descontinuação do Edgio CDN. Confira a postagem do blog Switching CDN providers para obter mais detalhes.

Azure DevOps Server 2020 Atualização 1.2 Patch 14 Data de lançamento: 12 de novembro de 2024

Ficheiro	SHA-256 Hash
devops2020.1.2patch14.exe	89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420

Lançamos Patch 14 para o Azure DevOps Server 2020 Update 1.2 para incluir uma atualização para uma dependência vulnerável.

Azure DevOps Server 2020 Atualização 1.2 Patch 13 Data de lançamento: 12 de março de 2024

Ficheiro	SHA-256 Hash
devops2020.1.2patch13.exe	55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6

Lançamos Patch 13 para a Atualização 1.2 do Azure DevOps Server 2020 que inclui correções para o seguinte:

• Resolvido um problema em que o servidor proxy parava de funcionar após a instalação do Patch 12.

Azure DevOps Server 2020 Atualização 1.2 Patch 12 Data de lançamento: 13 de fevereiro de 2024

Ficheiro	SHA-256 Hash
devops2020.1.2patch12.exe	C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53

Lançamos Patch 12 para a Atualização 1.2 do Azure DevOps Server 2020 que inclui correções para o seguinte:

• Corrigido um bug em que o espaço em disco usado pela pasta de cache de proxy foi calculado incorretamente e a pasta não foi limpa corretamente.
• CVE-2024-20667: Vulnerabilidade de execução remota de código do Azure DevOps Server.

Azure DevOps Server 2020 Atualização 1.2 Patch 11 Data de lançamento: 12 de dezembro de 2023

Ficheiro	SHA-256 Hash
devops2020.1.2patch11.exe	C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87

Lançamos Patch 11 para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte:

• Corrigido um erro em que a herança de segurança para aprovação pré-implantação não estava a funcionar nas etapas dos canais de implantação.

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

Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.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.

Observação

Para implementar correções para este patch, você terá que seguir uma série de etapas para atualizar manualmente as tarefas.

Instalar correções

Importante

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

Configurar o TFX

1. Siga as etapas nas tarefas de carregamento no para a documentação da coleção do projeto para instalar o tfx-cli e iniciar sessão.

Atualizar tarefas usando TFX

Ficheiro	SHA-256 Hash
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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 na aba de configuração no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Importante

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

Lançamos um patch . para o Azure DevOps Server 2020 Update 1.2, que inclui correções para o seguinte.

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

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

Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.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.

Importante

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

Observação

Para implementar correções para este patch, você terá que seguir uma série de etapas para atualizar manualmente o agente e as tarefas.

Instalar correções

1. Baixe e instale o Azure DevOps Server 2020 Update 1.2 patch 8.

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 auto-hospedados para implantar o agente.  

Observação

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

Configurar TFX

1. Siga as etapas na tarefa de carregamento para a documentação da coleção do projeto, a fim de 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 na guia variável no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Lançamos o patch para a Atualização 1.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.

• CVE-2023-36869: Vulnerabilidade de spoofing no Azure DevOps Server.
• Atualize o serviço SSH para suportar SHA2-256 e SHA2-512. Se você tiver arquivos de configuração SSH codificados para usar RSA, você deve atualizar para SHA2 ou remover a entrada.
• Foi resolvido um problema com ligações relativas que não funcionavam em ficheiros de markdown.
• Corrigido um bug com a navegação de comentários em uma página de confirmação.
• Corrigido um bug em que a identidade do Proprietário da Análise era exibida como Identidade Inativa.
• Corrigido erro de loop infinito na extensão CronScheduleJob.

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

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

• CVE-2023-21565: Vulnerabilidade de falsificação do servidor Azure DevOps.
• CVE-2023-21569: Vulnerabilidade de falsificação do servidor Azure DevOps.
• Corrigido um bug que interferia com o envio de pacotes durante a atualização de 2018 ou anterior.
• Corrigido um bug em que desanexar ou anexar a coleção falhava relatando o seguinte erro: 'TF246018: A operação do banco de dados excedeu o limite de tempo limite e foi cancelada.

Azure DevOps Server 2020 Atualização 1.2 Patch 5 Data de lançamento: 14 de fevereiro de 2023

Lançámos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para os seguintes.

• CVE-2023-21553: Vulnerabilidade de execução remota de código do Azure DevOps Server
• Corrigido problema de acessibilidade de prateleiras via interface do usuário da Web
• Os clientes precisam reiniciar o serviço tfsjobagent e o pool de aplicativos do Servidor de DevOps do Azure depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Servidor de DevOps do Azure.

Azure DevOps Server 2020 Atualização 1.2 Patch 4 Data de lançamento: 13 de dezembro de 2022

Lançámos um patch para o Azure DevOps Server 2020 Update 1.2 que inclui correções para os seguintes problemas.

• Exibição fixa de caracteres especiais no IdentityPicker.

• Os dados de teste não estavam sendo excluídos, fazendo com que o banco de dados crescesse. Com essa correção, atualizamos a retenção de compilação para evitar a criação de novos dados de teste órfãos.

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

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

• Resolva um problema com identidades do AD recém-adicionadas que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
• Corrija um problema com o filtro Solicitado por Membro do Grupo nas definiçõ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.
• Corrigir a obtenção do token de acesso do Azure ao estabelecer a conexão de serviço através de um proxy autenticado.

Azure DevOps Server 2020 Atualização 1.2 Patch 2 Data de lançamento: 9 de agosto de 2022

Lançámos um patch para o Azure DevOps Server 2020 Update 1.2, que inclui correções para o seguinte.

• Corrija o erro de valor de identidade ao atribuir um item de trabalho a uma identidade que aparece em domínios diferentes.

Azure DevOps Server 2020 Atualização 1.2 Patch 1 Data de lançamento: 12 de julho de 2022

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

• Em APIs de Execuções de Teste, o token de continuação retornado era maior do que o valor "maxLastUpdatedDate" especificado.

Azure DevOps Server 2020 Atualização 1.2 Data de lançamento: 17 de maio de 2022

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

Observação

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

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

• O Azure DevOps Server 2020.1.2 desativa o novo modelo de retenção (introduzido no Azure DevOps Server 2020) para evitar a perda de execuções de pipeline (compilações). Isto significa que o sistema:

  • Criar concessões para as 3 compilações mais recentes geradas durante a execução do Server 2020
  • Para pipelines YAML e pipelines Classic sem políticas de retenção por pipeline, as compilações serão mantidas de acordo com as configurações de retenção máxima de nível de coleta
  • Para pipelines clássicos com políticas de retenção personalizadas por pipeline, as compilações serão mantidas de acordo com a política de retenção específica do pipeline
  • As construções com arrendamentos não contam para o mínimo exigido para manter a configuração.

• Os links de comentários de changeset e shelveset não estavam a ser redirecionados corretamente. Quando comentários eram adicionados a arquivos em conjuntos de alterações ou shelvesets, a seleção desses comentários não redirecionava para o local correto na visualização do arquivo.

• Não é possível saltar a fila de compilação usando o botão "Executar a seguir". 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.1.1 Patch 4 Data de lançamento: 26 de janeiro de 2022

Lançamos um patch para o Azure DevOps Server 2020.1.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.
• O endereço de e-mail preferido não estava sendo atualizado no perfil do usuário. Isso resultou no envio de e-mails para o endereço de e-mail anterior.
• O cabeçalho não foi mostrado na página Resumo do Projeto. O cabeçalho foi mostrado por alguns milissegundos e depois desapareceu.
• 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 4.
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.

Observação

Se o Azure DevOps Server e o Elasticsearch estiverem instalados em máquinas diferentes, siga as etapas descritas abaixo.

1. Atualize o servidor com Patch 4.
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.

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

Azure DevOps Server 2020.1.1 Patch 3 Data de lançamento: 15 de dezembro de 2021

Patch 3 para o Azure DevOps Server 2020.1.1 inclui correções para o seguinte.

• Corrija a macro do item de trabalho para consultas que contêm palavras. Anteriormente, as consultas retornavam resultados incorretos para valores que continham uma quebra de linha.
• Aumente os limites para o comprimento de caracteres da versão do pacote Maven.
• Problema de localização para estados de layout de itens de trabalho personalizados.
• Problema de localização no modelo de notificação por e-mail.
• Problema com a avaliação de regras NOTSAMEAS quando várias regras NOTSAMEAS foram definidas para um campo.

Azure DevOps Server 2020.1.1 Patch 2 Data de lançamento: 26 de outubro de 2021

Patch 2 para o Azure DevOps Server 2020.1.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 de conexões do GitHub em nas 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 com a página de resumo da Visão Geral do Projeto que não carrega.
• Corrija o problema com e-mails que não estão sendo enviados para confirmar a atualização do produto.

Azure DevOps Server 2020.1.1 Patch 1 Data de lançamento: 14 de setembro de 2021

Patch 1 para o Azure DevOps Server 2020.1.1 inclui correções para o seguinte.

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

Azure DevOps Server 2020 Atualização 1.1 Data de lançamento: 17 de agosto de 2021

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

Observação

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

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

Azure Boards

• O hiperlink "Exibir item de trabalho" nos e-mails de notificação não está usando a URL pública.

Azure Repos

• Corrigida a exibição das caixas de seleção de herança para tipos de mesclagem limitados de modo a permitir a modificação desses tipos após definir políticas entre repositórios.

Azure Pipelines

• Ao alterar a configuração da Atualização do Agente, as configurações não estavam se propagando para outras camadas de aplicativo no ambiente.

Geral

• Correção ortográfica no assistente de configuração do servidor.
• Aumentar o tamanho do pacote de extensão e permitir-lhe alterar o tamanho no registo.

Planos de teste do Azure

• Não é possível navegar de volta para os resultados do teste depois de voltar do histórico para a página de resumo.

---

Azure DevOps Server 2020.1 Patch 2 Data de lançamento: 10 de agosto de 2021

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

• Corrige o erro na interface de definição de build.
• Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.

Azure DevOps Server 2020.1 Patch 1 Data de lançamento: 15 de junho de 2021

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

• Cookies seguros utilizados em fluxos de autorização que afirmam SameSite=None.

• Resolva o problema com o SDK de notificações. Anteriormente, as assinaturas de notificações usando o filtro Caminho de Área não estavam sendo analisadas corretamente.

Azure DevOps Server 2020.1 RTW Data de lançamento: 25 de maio de 2021

Resumo do que há de novo no Azure DevOps Server 2020.1 RTW

O Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos no Azure DevOps Server 2020.1 RC2 lançado anteriormente. do Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Você pode instalar diretamente o Azure DevOps Server 2020.1 ou atualizar do Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou mais recente.

Observação

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

Azure DevOps Server 2020.1 RC2 Data de lançamento: 13 de abril de 2021

Resumo do que há de novo no Azure DevOps Server 2020.1 RC2

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

Azure DevOps Server 2020.1 RC1 Data de lançamento: 23 de março de 2021

Resumo do que há de novo no Azure DevOps Server 2020.1 RC1

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

• Regras estaduais de restrição de transição em Conselhos
• As partes interessadas agora podem mover itens de trabalho entre colunas
• Melhore a segurança de liberação restringindo o escopo dos tokens de acesso
• Experiência aprimorada de pull request
• Gatilhos Multi-repo em Pipelines

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

• Placas
• Repos
• Pipelines
• Artefatos

---

Painéis

Regras de restrição de transição de estados

Continuamos a fechar a lacuna de paridade de recursos entre o XML hospedado e o modelo de processo herdado. Esta nova regra de tipo de item de trabalho permite restringir que os itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode restringir Bugs de ir de Novo para Resolvido. Em vez disso, eles devem ir de Novo –> Ativo –> Resolvido

Você também pode criar uma regra para restringir transições de estado por associação ao grupo. Por exemplo, apenas os usuários do grupo "Aprovadores" podem mover histórias de usuários de Novo -> Aprovado.

Copiar item de trabalho para copiar crianças

Um dos principais recursos solicitados para os Painéis do Azure é a capacidade de copiar um item de trabalho que também copia os itens de trabalho associados. Adicionamos uma nova opção para "Incluir itens de trabalho filho" à caixa de diálogo Copiar item de trabalho. Quando selecionada, esta opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).

Regras melhoradas para campos ativados e resolvidos

Até agora, as regras para Ativado por, Data de Ativação, Resolvido pore Data de Resolução têm sido um mistério. Eles são definidos apenas para tipos de item de trabalho do sistema e são específicos para o valor de estado de "Ativo" e "Resolvido". Mudamos a lógica para que essas regras não sejam mais para um estado específico. Em vez disso, eles são acionados pela categoria (categoria de estado) em que o estado reside. Por exemplo, digamos que temos um estado personalizado de "Necessita de Testes" na categoria Resolvido. Quando o item de trabalho muda de "Ativo" para "Necessita de Testes", as regras Resolvido por e Data de Resolução são acionadas.

Isso permite que os clientes criem quaisquer valores de estado personalizados e ainda gerem os campos Ativado por, Data Ativada, Resolvido pore Data Resolvida, sem a necessidade de usar regras personalizadas.

Os detentores de interesse podem mover itens de trabalho entre colunas

As partes interessadas sempre foram capazes de alterar o estado dos itens de trabalho. Mas quando eles vão para o quadro Kanban, não conseguem mover os itens de trabalho de uma coluna para outra. Em vez disso, as partes interessadas teriam que abrir cada item de trabalho, um de cada vez, e atualizar o valor do estado. Isso tem sido um ponto problemático para os clientes, e estamos felizes em anunciar que agora você pode mover itens de trabalho entre colunas.

Tipos de item de trabalho do sistema em listas de pendências e quadros

Agora é possível adicionar um tipo de item de trabalho do sistema ao nível de backlog da sua escolha. Historicamente, esses tipos de item de trabalho só estavam disponíveis a partir de consultas.

Processo	Tipo de item de trabalho
Ágil	Questão
Scrum	Impedimento
CMMI	Pedido de alteração
	Questão
	Avaliação
	Risco

Adicionar um tipo de item de trabalho do sistema a um nível de lista de pendências é simples. Basta entrar no seu processo personalizado e clicar guia Níveis de lista de pendências. Selecione o nível de sua lista de pendências (exemplo: Lista de requisitos em atraso) e escolha a opção de edição. Em seguida, adicione o tipo de item de trabalho.

Limite do repositório da aplicação Azure Boards GitHub aumentado

O limite de recompra para o do aplicativo Azure Boards no mercado do GitHub foi aumentado de 100 para 250.

Personalizar o estado do item de trabalho quando a solicitação pull é mesclada

Nem todos os fluxos de trabalho são iguais. Alguns clientes desejam fechar seus itens de trabalho relacionados quando uma solicitação pull é concluída. Outros querem definir os itens de trabalho para outro estado de modo a serem validados antes de fecharem. Devemos permitir ambos.

Temos um novo recurso que permite definir os itens de trabalho para o estado desejado quando a solicitação pull é mesclada e concluída. Para fazer isso, analisamos a descrição do pull request e procuramos o valor do estado seguido pela menção do(s) item(ns) de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvidas e fechando duas tarefas.

Vincular seu item de trabalho a compilações em outro projeto

Agora pode facilmente acompanhar as suas dependências de compilação em todos os projetos apenas ao vincular o seu item de trabalho a uma compilação, Encontrado na compilação ou Integrado na compilação.

Editando descrição (texto de ajuda) em campos do sistema

Você sempre foi capaz de editar a descrição de campos personalizados. Mas para campos do sistema como prioridade, gravidade e atividade, a descrição não era editável. Essa era uma lacuna de recurso entre o XML hospedado e herdado que impedia alguns clientes de migrar para o modelo herdado. Agora você pode editar a descrição nos campos do sistema. O valor editado afetará apenas esse campo no processo e para esse tipo de item de trabalho. Isso lhe dá a flexibilidade de ter descrições diferentes para o mesmo campo em diferentes tipos de item de trabalho.

Personalizar o estado do item de trabalho quando a solicitação pull é mesclada

As solicitações pull geralmente se referem a vários itens de trabalho. Ao criar ou atualizar uma solicitação pull, convém fechar algumas delas, resolver algumas delas e manter o restante aberto. Agora você pode usar comentários como os mostrados na figura abaixo para conseguir isso. Consulte a documentação para obter mais detalhes.

Campo principal no quadro de tarefas

Devido ao pedido popular, agora você pode adicionar o campo Pai aos cartões filho e pai no Quadro de Tarefas.

Removendo a regra "Atribuído a" no tipo de item de trabalho Bug

Existem várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho em Agile, Scrum e CMMI. Estas regras existem há mais de uma década e, em geral, têm funcionado bem, sem quaisquer queixas. No entanto, há algumas regras que já não são bem-vindas. Uma regra em particular causou muita dor para clientes novos e existentes e decidimos que era hora de removê-la. Esta regra existe no tipo de item de trabalho "Bug" do processo Agile.

"Defina o valor atribuído como Criado por quando o estado for alterado para Resolvido"

Recebemos muitos dos seus comentários sobre esta regra. Em resposta, fomos em frente e removemos essa regra do tipo de item de trabalho Bug no processo Agile. Essa alteração afetará cada projeto usando um processo Agile herdado ou um processo Agile herdado personalizado. Para os clientes que gostam e dependem dessa regra atual, consulte nossa postagem no blog sobre as etapas que você pode seguir para adicionar novamente a regra usando regras personalizadas.

Itens removidos na página Itens de Trabalho

A página Itens de Trabalho é um ótimo lugar para encontrar rapidamente itens que você criou ou que são atribuídos a você, entre outras coisas. Ele fornece vários pivôs e filtros personalizados. Uma das principais reclamações sobre a aba "Atribuído a mim" é que esta exibe itens de trabalho removidos, ou seja, itens de trabalho no estado Removido. E nós concordamos! Os itens removidos são trabalhos que não têm mais valor e, portanto, foram removidos da lista de pendências, portanto, incluí-lo nessa exibição não é útil.

Agora você pode ocultar todos os itens removidos do pivô Atribuído a mim na página Itens de trabalho.

Repositórios

Preferência de nome de ramo padrão

O Azure Repos agora oferece um nome de ramificação padrão personalizável para o Git. Nas configurações do repositório, você pode escolher qualquer nome de ramificação legal para usar quando um repositório for inicializado. O Azure Repos sempre deu suporte à alteração do nome da filial padrão de um repositório existente.

Para obter mais informações, consulte Gerenciar ramificações e Alterar a ramificação padrão.

Configuração ao nível da organização para ramo padrão

Agora há uma configuração de nível de coleção para seu nome de ramificação inicial preferido para novos repositórios. Se um projeto não tiver escolhido um nome de ramificação inicial, essa configuração de nível de organização será usada. Se você não especificou o nome da ramificação inicial nas configurações da organização ou nas configurações do projeto, os novos repositórios usarão um padrão definido pelo Azure DevOps.

Adicionar um novo escopo de autenticação para contribuir com comentários de RP

Esta versão adiciona um novo escopo OAuth para leitura/gravação de comentários de pull requests. Se tiveres um bot ou automação que só precise interagir com comentários, podes dar-lhe um PAT apenas com este escopo. Esse processo reduz o raio de explosão se a automação tiver um bug ou se o token for comprometido.

Melhorias na experiência do Pull Request

A nova experiência com pull requests foi aprimorada com as seguintes melhorias:

• Tornar as verificações opcionais mais visíveis

Os clientes usam verificações opcionais para chamar a atenção de um desenvolvedor para possíveis problemas. Na experiência anterior, costumava ser óbvio quando essas verificações falhavam. No entanto, esse não é o caso na experiência de pré-visualização. Um grande sinal verde nas verificações necessárias mascara as falhas nas verificações opcionais. Os usuários só puderam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores geralmente não fazem isso quando não há indicação de um problema. Nesta implantação, tornamos o status das verificações opcionais mais visível no resumo.

• Ctrl clica em itens de menu

Os menus de separadores num PR não suportavam o clique com Ctrl. Os utilizadores frequentemente abrem novos separadores do navegador enquanto analisam um pull request. Isso foi corrigido.

• Localização da anotação [+]

A árvore de listagem de arquivos em um PR mostra uma anotação [+] para ajudar autores e revisores a identificar novos arquivos. Como a anotação ficava após as reticências, muitas vezes não ficava visível em nomes de ficheiro mais longos.

• Menu suspenso de atualizações de PR retorna informações de temporização

A lista suspensa para selecionar, atualizar e comparar arquivos em uma RP perdeu um elemento importante na experiência de visualização. Ele não mostrou quando essa atualização foi feita. Isso foi corrigido.

• **Layout de filtro de comentários melhorado **

Ao filtrar comentários na página de resumo de uma solicitação pull, a lista suspensa estava à direita, mas o texto estava alinhado à esquerda. Isso foi corrigido.

• Navegação para os commits ascendentes

Na página de Confirmações, pode-se comparar as alterações efetuadas num determinado commit com o seu commit pai. No entanto, você pode querer navegar até o commit pai e compreender melhor como esse commit difere do seu próprio pai. Isso geralmente é necessário quando você deseja entender todas as alterações em uma versão. Adicionámos um cartão de pais a um compromisso para o ajudar a alcançar este objetivo.

• Mais espaço para pastas e arquivos com nomes longos na guia Arquivos de RP

Pastas e arquivos com nomes longos foram cortados devido à falta de espaçamento horizontal na árvore de arquivos. Recuperamos algum espaço adicional na árvore ao ajustar a indentação da árvore para alinhá-la com o nó raiz e ocultar o botão de reticências da página, exceto quando se paira o rato.

Imagem da nova árvore de ficheiros:

Imagem da árvore de arquivos ao passar o mouse sobre um diretório:

• Preservar a posição de rolagem ao redimensionar o painel de comparação na guia Arquivos PR

Ao redimensionar o painel de comparação lado a lado na guia de ficheiros da PR, a posição de scroll do utilizador seria perdida. Este problema foi corrigido; A posição de scroll do utilizador agora é mantida durante o redimensionamento de um painel de diferenças.

• Pesquisar um commit num dispositivo móvel

Ao visualizar a página Confirmações em um dispositivo móvel, a caixa de pesquisa está ausente na nova experiência. Como resultado, é difícil para você encontrar um commit por seu hash e abri-lo. Isso foi corrigido agora.

• Melhor utilização do espaço para a nova vista móvel de comparação de ficheiros PR

Atualizámos esta página para utilizar melhor o espaço para que os utilizadores possam ver mais do ficheiro em vistas móveis em vez de terem 40% do ecrã ocupados por um cabeçalho.

• Imagens melhoradas na vista de resumo de RP

As imagens editadas em um PR não foram exibidas na visualização de resumo de RP, mas foram exibidas corretamente na visualização de arquivos de RP. Este problema foi resolvido.

• Experiência melhorada de ramificação ao criar um novo PR

Antes dessa atualização, essa experiência não era ideal, pois comparava as alterações com a ramificação padrão do repositório em vez da ramificação de comparação.

Condutas

Plataforma de agente adicional: ARM64

Adicionámos Linux/ARM64 à lista de plataformas suportadas para o agente Azure Pipelines. Embora as mudanças de código tenham sido mínimas, muito trabalho nos bastidores teve que ser concluído primeiro, e estamos entusiasmados em anunciar seu lançamento!

Suporte de filtro de tags para recursos de pipeline

Agora adicionamos 'tags' nos pipelines YAML. Você pode usar tags para definir o pipeline de CI para ser executado ou quando disparar automaticamente.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:              ### This filter is used for resolving default version
    - Production       ### Tags are AND'ed
    trigger:
      tags:            ### This filter is used for triggering the pipeline run
      - Production     ### Tags are AND'ed
      - Signed

O trecho acima mostra que as tags podem ser usadas para determinar a versão padrão do pipeline de CI (integração contínua) a ser executado quando a execução do pipeline de CD (implantação contínua) não é acionada por alguma outra fonte/recurso ou um gatilho de execução agendada.

Por exemplo, se você tiver um conjunto de gatilhos agendados para o pipeline de CD que só deseja executar se o CI tiver a tag de produção, as tags na seção triggers garantirão que o pipeline de CD só seja acionado se a condição de marcação for atendida pelo evento de conclusão do CI.

Controlar quais tarefas são permitidas nos pipelines

Agora você pode desativar as tarefas do Marketplace. Alguns de vocês podem permitir extensões do Marketplace, mas não as tarefas do Pipelines que elas trazem. Para ainda mais controle, também permitimos que você desative de forma independente todas as tarefas in-the-box (exceto checkout, que é uma ação especial). Com ambas as configurações habilitadas, as únicas tarefas permitidas para serem executadas em um pipeline seriam aquelas carregadas usando tfx. Visite https://dev.azure.com/<your_org>/_settings/pipelinessettings e procure a seção chamada "Restrições de tarefas" para começar.

Política exclusiva de bloqueio de implantação

Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente de cada vez. Ao optar pela opção "Bloqueio exclusivo" num ambiente, apenas uma execução será realizada. As execuções subsequentes que desejam desplegar nesse ambiente serão pausadas. Quando a execução com o bloqueio exclusivo for concluída, a última execução continuará. Todas as execuções intermediárias serão canceladas.

Filtros de estágios para gatilhos de recursos de pipeline

Adicionamos suporte para 'estágios' como um filtro para recursos de pipeline no YAML. Com esse filtro, você não precisa esperar que todo o pipeline de CI seja concluído para acionar o pipeline de CD. Agora você pode optar por acionar o pipeline de CD após a conclusão de um estágio específico no pipeline de CI.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

Quando os estágios fornecidos no filtro de gatilho são completados com sucesso no pipeline de CI, uma nova execução é automaticamente iniciada para o pipeline de CD.

Acionadores genéricos baseados em webhook para pipelines YAML

Hoje, temos vários recursos (como pipelines, contêineres, compilação e pacotes) através dos quais você pode consumir artefatos e habilitar gatilhos automatizados. Até agora, no entanto, você não podia automatizar seu processo de implantação com base em outros eventos ou serviços externos. Nesta versão, estamos introduzindo o suporte a gatilhos de webhook em pipelines YAML para permitir a integração da automação de pipeline com qualquer serviço externo. Você pode se inscrever em qualquer evento externo através de seus webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) e acionar seus pipelines.

Aqui estão as etapas para configurar os gatilhos do webhook:

1. Configure um webhook no seu serviço externo. Ao criar seu webhook, você precisa fornecer as seguintes informações:

   • URL da solicitação - "https://dev.azure.com/<coleção ADO>/_apis/public/distributedtask/webhooks/<Nome do WebHook>?api-version=6.0-preview"
   • Segredo - Isto é opcional. Se precisar proteger a sua carga JSON, forneça o valor Secret

2. Crie uma nova conexão de serviço "Incoming Webhook". Este é um Tipo de Conexão de Serviço recém-introduzido que permitirá definir três informações importantes:

   • Webhook Name: O nome do webhook deve corresponder ao webhook criado no seu serviço externo.
   • Cabeçalho HTTP - O nome do cabeçalho HTTP na solicitação que contém o valor hash do payload para verificação da solicitação. Por exemplo, no caso do GitHub, o cabeçalho da solicitação será "X-Hub-Signature"
   • Secret - O segredo é usado para analisar o hash de carga útil usado para verificação da solicitação de entrada (isso é opcional). Se você usou um segredo na criação de seu webhook, você precisará fornecer a mesma chave secreta

   

3. Um novo tipo de recurso chamado webhooks é introduzido nos pipelines YAML. Para subscrever um evento webhook, é necessário definir um recurso webhook no pipeline e apontá-lo para a ligação de serviço de webhook de entrada. Você também pode definir filtros adicionais no recurso de webhook com base nos dados do payload JSON para personalizar melhor os gatilhos para cada pipeline, e você pode consumir os dados do payload na forma de variáveis nos seus processos.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

4. Sempre que um evento webhook é recebido pela conexão do serviço Webhook de entrada, uma nova execução será acionada para todos os pipelines inscritos no evento webhook.

Suporte e rastreabilidade de problemas de gatilho de recursos YAML

Pode ser confuso quando os gatilhos de pipeline não são executados como você espera. Para ajudar a entender melhor isso, adicionamos um novo item de menu na página de definição de pipeline chamado 'Problemas de gatilho', onde são exibidas informações sobre por que os gatilhos não estão sendo executados.

Os gatilhos de recursos podem falhar na execução por dois motivos.

1. Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado. Estes são apresentados como erros.

2. Se as condições do gatilho não forem correspondidas, o gatilho não será executado. Sempre que isso ocorrer, um aviso será exibido para que você possa entender por que as condições não foram correspondidas.

   

Gatilhos multi-repo

Você pode especificar vários repositórios em um arquivo YAML e fazer com que um pipeline seja acionado por atualizações em qualquer um dos repositórios. Esse recurso é útil, por exemplo, nos seguintes cenários:

• Você consome uma ferramenta ou uma biblioteca de um repositório diferente. Você deseja executar testes para seu aplicativo sempre que a ferramenta ou biblioteca for atualizada.
• Você mantém seu arquivo YAML em um repositório separado do código do aplicativo. Você deseja acionar o pipeline sempre que uma atualização for efetuada ao repositório do aplicativo.

Com esta atualização, os gatilhos multi-repo funcionarão apenas para repositórios Git no Azure Repos. Eles não funcionam para recursos de repositório GitHub ou BitBucket.

Aqui está um exemplo que mostra como definir vários recursos de repositório em um pipeline e como configurar gatilhos em todos eles.

trigger:
- main

resources:
  repositories:
  - repository: tools
    type: git
    name: MyProject/tools
    ref: main
    trigger:
      branches:
        include:
        - main
        - release

O pipeline neste exemplo será acionado se houver atualizações para:

• main ramificação no repositório self que contém o ficheiro YAML
• main ou release ramos em tools repositório

Para obter mais informações, consulte Vários repositórios no seu pipeline.

Melhorias nos uploads de registos do agente

Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que estava sendo executado é abandonado. Se por acaso você estava olhando para os logs do console de streaming, você pode ter obtido algumas pistas sobre o que o agente estava fazendo antes de parar de responder. Mas se você não estava, ou se você atualizou a página, esses logs do console desapareceram. Com esta versão, se o agente parar de responder antes de enviar seus logs completos, manteremos os logs do console como a próxima melhor coisa. Os logs do console são limitados a 1000 caracteres por linha e ocasionalmente podem estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a resolver problemas nos seus próprios pipelines, e certamente ajudará os nossos engenheiros de suporte quando prestarem assistência na resolução de problemas.

Opcionalmente, monte volumes de contentor em modo apenas leitura

Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o espaço de trabalho, tarefas e outros materiais são mapeados como volumes. Estes volumes têm acesso de leitura/gravação por padrão. Para maior segurança, pode-se montar os volumes como somente leitura ao alterar a especificação do contentor no YAML. Cada chave em mountReadOnly pode ser definida como true para somente leitura (o padrão é false).

resources:
  containers:
    - container: example
      image: ubuntu:18.04
      mountReadOnly:
        externals: true
        tasks: true
        tools: true
        work: false

Controlo minucioso sobre o arranque/paragem do contentor

Em geral, recomendamos que você permita que o Azure Pipelines gerencie o ciclo de vida de seus contêineres de trabalho e serviço. No entanto, em alguns cenários incomuns, você pode querer começar e pará-los você mesmo. Com esta versão, incorporamos esse recurso à tarefa do Docker.

Aqui está um exemplo de pipeline usando o novo recurso:

resources:
  containers:
    - container: builder
      image: ubuntu:18.04
steps:
  - script: echo "I can run inside the container (it starts by default)"
    target:
      container: builder
  - task: Docker@2
    inputs:
      command: stop
      container: builder
# if any step tried to run in the container here, it would fail

Além disso, incluímos a lista de contêineres em uma variável de pipeline, Agent.ContainerMapping. Você pode usar isso se quiser inspecionar a lista de contêineres em um script, por exemplo. Ele contém um objeto JSON stringified mapeando o nome do recurso ("builder" do exemplo acima) para o ID do contêiner que o agente gerencia.

Descomprima pacotes de tarefas em cada etapa

Quando o agente executa um trabalho, ele primeiro baixa todos os pacotes de tarefas exigidos pelas etapas do trabalho. Normalmente, para otimizar o desempenho, ele descompacta as tarefas uma única vez por trabalho, mesmo que a tarefa seja usada em várias etapas. Se você tiver preocupações sobre código não confiável alterando o conteúdo descompactado, você pode sacrificar um pouco de desempenho fazendo com que o agente descompacte a tarefa toda vez que for usado. Para habilitar esse modo, passe --alwaysextracttask ao configurar o agente.

Melhore a segurança de lançamento restringindo o escopo dos tokens de acesso

Com base na nossa iniciativa de melhorar as definições de segurança para o Azure Pipelines, agora suportamos a restrição do âmbito dos tokens de acesso para lançamentos.

Cada trabalho executado em versões recebe um token de acesso. O token de acesso é utilizado pelas tarefas e pelos seus scripts para fazer chamadas de retorno para o Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, baixar artefatos, carregar logs, resultados de teste ou 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, nos baseamos em melhorar a segurança do pipeline, restringindo o escopo dos tokens de acesso e estendendo o mesmo para versões clássicas.

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 de coleta > Pipelines > Configurações. > Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de liberação. Saiba mais aqui.

Aprimoramentos da API de visualização do YAML

Agora você pode visualizar o YAML completo de um pipeline sem executá-lo. Além disso, criamos um novo URL dedicado para o recurso de visualização. Agora podes fazer um POST para em https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview para recuperar o corpo YAML finalizado. Esta nova API aceita os mesmos parâmetros que enfileirar uma execução, mas já não requer a permissão "Enfileirar compilações".

Execute este trabalho em seguida

Você já teve uma correção de bug que você precisava implantar neste minuto mas teve que esperar atrás de trabalhos de CI e RP? Com esta versão, agora permitimos que você aumente a prioridade de um trabalho em fila. Os utilizadores com a permissão "Gerir" no pool - geralmente os administradores de pool - verão um novo botão "Executar seguinte" na página de detalhes do trabalho. Clicar no botão definirá o trabalho a ser executado o mais rápido possível. (Você ainda precisará de paralelismo disponível e um agente adequado, é claro.)

Expressões de modelo permitidas no bloco resources YAML

Anteriormente, as expressões em tempo de compilação (${{ }}) não eram permitidas na seção resources de um ficheiro YAML do Azure Pipelines. Com esta libertação, eliminámos esta restrição para os contentores. Isto permite-lhe usar o parâmetro em tempo de execução e os conteúdos dentro dos seus recursos, por exemplo, para escolher um contentor no tempo de fila. Planeamos alargar este apoio a outros recursos ao longo do tempo.

Controle sobre atualizações automatizadas de tarefas do Marketplace

Quando você escreve um pipeline YAML, normalmente você especifica apenas o número da versão principal das tarefas incluídas. Isso permite que seus pipelines recebam automaticamente as mais recentes adições de recursos e correções de bugs. Ocasionalmente, você pode precisar reverter para uma versão pontual anterior de uma tarefa e, com essa atualização, adicionamos a capacidade de fazê-lo. Agora você pode especificar uma versão completa da tarefa major.minor.patch em seus pipelines YAML.

Não recomendamos proceder assim regularmente e deve utilizá-la apenas como uma solução temporária quando descobrir que uma nova tarefa desestabiliza os pipelines. Além disso, isso não instalará uma versão mais antiga de uma tarefa do Marketplace. Ele já deve existir na tua coleção ou a tua canalização falhará.

Exemplo:

steps:
- task: MyTask@1  # a normal, major-version only reference
- task: MyOtherTask@2.3.4   # pinned to a precise version

Suporte para o Node 10 em agentes e tarefas

Como o Nó 6 não é mais suportado, estamos migrando as tarefas para trabalhar com o Nó 10. Para esta atualização, migramos quase 50% de tarefas da caixa de entrada para o Nó 10. O agente agora pode executar tarefas no Node 6 e no Node 10. Em uma atualização futura, removeremos totalmente o Nó 6 do agente. Para que se preparem para a remoção do Node 6 do agente, solicitamos que atualizem as vossas extensões internas e tarefas personalizadas para que também utilizem o Node 10 em breve. Para usar o Node 10 para a sua tarefa, no seu task.json, sob execution, atualize de Node para Node10.

Melhore a conversão de YAML no designer de construção clássico

Com esta versão, introduzimos um novo recurso de "exportação para YAML" para pipelines de build de design. Salve sua definição de pipeline e encontre "Exportar para YAML" no menu ....

A nova função de exportação substitui a função "View as YAML" anteriormente encontrada no designer de construção clássico. Essa função estava incompleta, pois só podia inspecionar o que a interface do usuário da Web sabia sobre a compilação, o que às vezes levava à geração de YAML incorreto. A nova função de exportação leva em conta exatamente como o pipeline será processado e gera YAML com total fidelidade ao pipeline do designer.

Nova conversão de plataforma web – Configurações do repositório

Convertemos as duas páginas de configurações do repositório em uma única experiência que foi atualizada para uma nova plataforma web. Essa atualização não apenas torna a experiência mais rápida e moderna, mas essas páginas também fornecem um único ponto de entrada para todas as políticas, desde o nível do projeto até o nível da ramificação.

Com esta nova experiência, a navegação para projetos com um número substancial de repositórios tornou-se mais fácil devido aos tempos de carregamento mais rápidos e a um filtro de pesquisa adicional. Você também pode visualizar políticas de nível de projeto e a lista de políticas de repositório cruzado na guia Políticas.

Se você clicar em um repositório, poderá visualizar as políticas e permissões definidas no nível do repositório. Na guia políticas, você pode exibir uma lista de todas as ramificações em que a política está definida. Agora, clique na ramificação para ver as políticas, sem nunca sair da página de configurações do repositório.

Agora, quando as políticas são herdadas de um escopo mais alto do que aquele em que está a trabalhar, mostramos ao lado de cada política individual de onde foi herdada. Você também pode navegar até a página onde a política de nível superior foi definida clicando no nome do escopo.

A própria página de política também foi atualizada para a nova plataforma web com seções dobráveis! Para melhorar a experiência de procurar uma política específica de Validação de Compilação, Verificação de Status ou Revisor Automático, adicionamos filtros de pesquisa para cada seção.

Integração do gerenciamento de alterações ServiceNow com pipelines YAML

O aplicativo Azure Pipelines para ServiceNow ajuda você a integrar o Azure Pipelines e o ServiceNow Change Management. Com esta atualização, levamos nossa jornada de tornar os Pipelines do Azure cientes do processo de gerenciamento de alterações gerenciado no ServiceNow ainda mais para os pipelines YAML.

Ao configurar a verificação "ServiceNow Change Management" em um recurso, agora você pode pausar para que a alteração seja aprovada antes de implantar a compilação nesse recurso. Você pode criar automaticamente uma nova alteração para um estágio ou aguardar uma solicitação de alteração existente.

Integração do ServiceNow Change Management

Você também pode adicionar a tarefa UpdateServiceNowChangeRequest em um trabalho de servidor para atualizar a solicitação de alteração com status de implantação, anotações, etc.

Artefatos

Capacidade de criar feeds com escopo organizacional a partir da interface do usuário

Estamos a restaurar a capacidade de os clientes criarem e gerirem feeds com escopo de coleção através da interface Web para serviços no local e em hospedagem.

Agora você pode criar feeds com escopo organizacional por meio da interface do usuário, acessando Artefatos -> Criar Feed e escolhendo um tipo de feed dentro do Escopo.

Embora recomendemos o uso de feeds com escopo de projeto em alinhamento com o restante das ofertas de DevOps do Azure, você pode novamente criar, gerenciar e usar feeds com escopo de coleção por meio da interface do usuário e de várias APIs REST. Consulte a nossa documentação de fluxos para obter mais informações.

A "Update Package Version REST API" agora está disponível para os pacotes Maven.

Agora, você pode usar a API REST "Atualizar Versão do Pacote" do Azure Artifacts para atualizar as versões de pacotes Maven. Anteriormente, você podia usar a API REST para atualizar versões de pacotes para NuGet, Maven, npm e Pacotes Universais, mas não pacotes Maven.

Para atualizar pacotes Maven, use o comando HTTP PATCH da seguinte maneira.

PATCH https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1

Você pode definir o seguinte:

Parâmetros de URI

Nome	em	Necessário	Tipo	Descrição
artifactId	caminho	VERDADEIRO	cadeia de caracteres	ID do artefacto do pacote
Alimentação	caminho	VERDADEIRO	string	Nome ou ID do fluxo
groupId	caminho	VERDADEIRO	string	ID de grupo do pacote
Coleção	caminho	VERDADEIRO	string	O nome da coleção Azure DevOps
Versão	caminho	VERDADEIRO	string	Versão do pacote
projeto	caminho		string	ID do projeto ou nome do projeto
API-versão	consulta	VERDADEIRO	string	Versão da API a ser usada. Isso deve ser definido como '5.1-preview.1' para usar esta versão da api

Órgão do Pedido

Nome	Tipo	Descrição
Visualizações	JsonPatchOperation	A vista à qual a versão do pacote será adicionada

Para obter mais informações, consulte a documentação da API REST à medida que ela é atualizada.

Feedback

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

---

Topo da página