Azure DevOpsServer 2020 Atualização 1 Notas de versão

Comunidade de Desenvolvedores | Requisitos do Sistema | Termos de Licença | DevOps Blog | 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 Azure DevOps Server, consulte Azure DevOps Server Requisitos. 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 2020 é compatível com o Azure DevOps Server 2019 ou o Team Foundation Server 2015 ou posterior. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps local.

---

Atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020

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

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

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

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

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

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

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

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

Lançamos o Patch 13 para a Atualização 1.2 do Azure DevOps Server de 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 Data de lançamento do Patch 12: 13 de fevereiro de 2024

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

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

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

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

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

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

• Corrigido um bug em que a herança de aprovação de segurança de pré-despacho não estava funcionando nas etapas dos pipelines.

Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 10: 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.

• A lista de caracteres permitidos para tarefas do PowerShell foi estendida para Habilitar a validação dos parâmetros de argumentos das tarefas do shell.

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çamos 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 você 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 na documentação de upload de tarefas para a coleção de projetos para instalar e fazer login com o tfx-cli.

Atualizar tarefas usando o TFX

Arquivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

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

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

Requisitos de pipeline

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

• No clássico:

  Defina a variável na guia Variável do pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

Importante

Lançamos 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 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 Atualização 1.2, que inclui correções para o seguinte.

• Corrigido um bug em que a identidade "Proprietário da Análise" é exibida como Identidade Inativa em máquinas de atualização de patch.

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

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

• CVE-2023-33136: vulnerabilidade de execução de código remoto 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 verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.

Observação

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

Instalar correções

1. Baixe e instale Azure DevOps Server 2020 Atualização 1.2 patch 8.

Atualizar o agente do Azure Pipelines

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

Observação

AZP_AGENT_DOWNGRADE_DISABLED precisa ser definido como “true” para impedir o downgrade do agente. 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 da documentação de upload de tarefas para a coleção de projetos para instalar e logar com o tfx-cli.

Atualizar tarefas usando o TFX

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

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

Requisitos de Canalização

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

• Sobre o clássico:

  Defina a variável na aba de variáveis no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 7: 8 de agosto 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-36869: vulnerabilidade de falsificação do Azure DevOps Server.
• Atualize o serviço SSH para dar suporte a SHA2-256 e SHA2-512. Se você tiver arquivos de configuração SSH codificados para usar RSA, atualize para SHA2 ou remova a entrada.
• Foi resolvido um problema em que os links relativos não funcionavam em arquivos 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 o bug de loop infinito em CronScheduleJobExtension.

Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 6: 13 de junho 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-21565: vulnerabilidade de falsificação do Azure DevOps Server.
• CVE-2023-21569: vulnerabilidade de falsificação do Azure DevOps Server.
• Corrigido um erro que interferia no envio de pacotes ao realizar a atualização de versões de 2018 ou anteriores.
• Corrigido um bug onde, ao desanexar ou anexar uma coleção, ocorre a falha relatando o seguinte erro: 'TF246018: a operação do banco de dados excedeu o limite de tempo e foi cancelada.

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

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

• CVE-2023-21553: vulnerabilidade de execução remota de código do Azure DevOps Server
• Corrigido o problema de acessibilidade dos conjuntos de alterações por meio da interface do usuário da web
• Os clientes precisam reiniciar o serviço tfsjobagent e o pool de aplicativos Azure DevOps Server depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento Azure DevOps Server.

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

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

• Corrigida a exibição 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 impedir a criação de novos dados de teste residuais.

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

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

• Resolva o problema com identidades do Active Directory adicionadas recentemente que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
• Correção de um problema com o filtro Solicitado pelo membro do grupo nas configurações do web hook.
• Correção do erro em construções de check-in com controle restrito quando as configurações da organização para o pipeline tinham o escopo de autorização de trabalho configurado como Limitar o escopo de autorização de trabalho ao projeto atual para pipelines que não são de lançamento.
• Corrija a recuperação do token de acesso do Azure ao estabelecer a conexão de serviço por trás do proxy autenticado.

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

Lançamos um patch para a Atualização 1.2 do Azure DevOps Server 2020 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 Data de lançamento do Patch 1: 12 de julho de 2022

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

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

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

Azure DevOps Server 2020 Update 1.2 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.2 ou atualizar de 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 publicação. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

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

• Azure DevOps Server 2020.1.2 desativa o novo modelo de retenção (introduzido no Azure DevOps Server 2020) para evitar a perda das execuções de pipelines (builds). Isso significa que o sistema irá:

  • 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, os builds serão mantidos de acordo com as configurações máximas de retenção ao nível da coleção.
  • Para Pipelines Clássicos com políticas de retenção personalizadas para cada pipeline, os builds serão retidos conforme a política de retenção específica do pipeline.
  • As compilações com concessões não contam para o Mínimo necessário para manter a configuração.

• Os links de comentários do conjunto de alterações e do shelveset não estavam redirecionando corretamente. Quando os comentários eram adicionados a arquivos em conjuntos de alterações ou shelvesets, selecionar esses comentários não os redirecionava para o local correto na visualização do arquivo.

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

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

Azure DevOps Server 2020.1.1 Data de lançamento do Patch 4: 26 de janeiro de 2022

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

• As notificações por email não foram enviadas ao usar o @mention controle em um item de trabalho.
• O endereço de email preferencial não estava sendo atualizado no perfil do usuário. Isso resultava no envio de emails para o endereço de email 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 Active Directory.
• Resolução da vulnerabilidade do Elasticsearch pela remoção da classe jndilookup dos binários do Log4j.

Etapas de instalação

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

Observação

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

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

Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6

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

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

• Corrija a macro do item de trabalho para consultas com "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 nos 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 Data de lançamento do Patch 2: 26 de outubro de 2021

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

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

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

O Patch 1 para 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 inconsistentes dos Resultados dos Testes.

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

Azure DevOps Server 2020 Update 1.1 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.1 ou atualizar de 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 Azure DevOps Server Atualização 1.1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

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

Azure Boards

• O hiperlink "Exibir item de trabalho" nos emails 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 de tipos de mesclagem limitados para permitir a modificação dos tipos de mesclagem limitados após a definição de políticas de repositório cruzado.

Azure Pipelines

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

Geral

• Corrigida a ortografia no assistente de configuração do servidor.
• Aumento do tamanho do pacote de extensão e permite que você altere o tamanho no registro.

Azure Test Plans

• 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 Data de lançamento do Patch 2: 10 de agosto de 2021

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

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

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

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

• Cookies seguros usados em fluxos de autorização que declaram SameSite=None.

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

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

Resumo das novidades no Azure DevOps Server 2020.1 RTW

Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2020.1 RC2 lançado anteriormente. Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020.1 ou atualizar de 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 Azure DevOps Server Atualização 1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

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

Resumo das novidades em Azure DevOps Server 2020.1 RC2

Azure DevOps Server 2020.1 RC2 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do 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 das novidades em Azure DevOps Server 2020.1 RC1

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

• Regras de restrição de transição estadual nos Conselhos
• Os participantes agora podem mover itens de trabalho entre colunas do quadro
• Aprimorar a segurança do lançamento por meio da restrição do escopo dos tokens de acesso
• Experiência aprimorada de solicitação de pull
• Gatilhos em múltiplos repositórios em Pipelines

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

• Placas
• Repos
• Pipelines
• Artefatos

---

Quadros

Regras de restrição de transição de estado

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

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

Copiar item de trabalho para copiar filhos

Um dos principais recursos solicitados para Azure Boards é a capacidade de copiar um item de trabalho que também copia os itens de trabalho filho. Adicionamos uma nova opção para "Incluir itens de trabalho filho" na caixa de diálogo de cópia de item de trabalho. Quando selecionada, essa opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).

Regras aprimoradas para campos ativados e resolvidos

Até agora, as regras para Ativado por, Data de Ativação, Resolvido por e 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 você tenha um estado personalizado de "Precisa de teste" na categoria Resolvido. Quando o item de trabalho muda de "Ativo" para "Precisa de Testes", as regras Resolvido por e a Data Resolvida são disparadas.

Isso permite que os clientes criem valores de estado personalizados e ainda gerem os campos Ativado por, Data de Ativação, Resolvido por e Data de Resolução, sem a necessidade de usar regras personalizadas.

Os participantes podem mover itens de trabalho entre colunas de quadro

As partes interessadas sempre foram capazes de alterar o estado dos itens de trabalho. Mas quando eles vão para o quadro Kanban, eles 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. Esse tem sido um ponto problemático para os clientes, e temos o prazer de anunciar que agora você pode mover itens de trabalho entre colunas do quadro.

Tipos de item de trabalho do sistema em listas de pendências e painéis

Agora você pode adicionar um tipo de item de trabalho do sistema ao nível de lista de pendências de sua escolha. Historicamente, esses tipos de itens de trabalho estavam disponíveis apenas por meio de consultas.

Processo	Tipo de Item de Trabalho
Ágil	Problema
Scrum	Impedimento
CMMI	Alterar pedido
	Problema
	Revisão
	Risco

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

Limite de repositório para o aplicativo do GitHub para Azure Boards aumentado

O limite de repositório para o aplicativo Azure Boards no GitHub Marketplace foi aumentado de 100 para 250.

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

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

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

Vincule seu item de trabalho aos builds em outro projeto

Agora você pode acompanhar facilmente suas dependências de compilação no projeto apenas vinculando seu item de trabalho a uma compilação, encontrada na compilação ou integrada na compilação.

Como editar uma descrição (texto de ajuda) em campos do sistema

Você sempre foi capaz de editar a descrição dos 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 recursos entre o XML hospedado e o herdado que impedia que alguns clientes migrassem 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 de pull for mesclada

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

Campo principal no quadro de tarefas

Devido à solicitação popular, agora você pode adicionar o campo de pai aos cartões de filho e de pai no Quadro de Tarefas.

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

Há várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho no Agile, Scrum e CMMI. Essas regras existem há mais de uma década e geralmente funcionam bem sem reclamações. No entanto, existem 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. Essa regra existe no tipo de item de trabalho Bug no processo Agile.

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

Recebemos muitos de seus comentários sobre essa regra. Em resposta, fomos em frente e removemos essa regra do tipo de item de trabalho Bug no processo Agile. Essa alteração afetará todos os projetos que usam um processo Agile herdado ou um processo Agile herdado personalizado. Para os clientes que gostam e dependem dessa regra atual, consulte nossa postagem do 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 localizar rapidamente itens que você criou ou que estão atribuídos a você, entre outras coisas. Ele fornece vários pivôs e filtros personalizados. Uma das principais reclamações para a aba "Atribuído a mim" é que ela exibe itens de trabalho removidos (ou seja, itens de trabalho no estado de '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í-los 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.

Repos

Preferência para nome padrão do branch

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

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

Configuração de nível da organização para ramificação padrão

Agora há uma configuração de nível de coleção para definir o nome inicial preferido do branch para novos repositórios. Se um projeto não tiver escolhido um nome de ramificação inicial, essa configuração no nível da organização será usada. Se você não especificou o nome do branch 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 comentários de contribuição em PR

Esta versão adiciona um novo escopo OAuth para ler/escrever comentários de pull request. Se você tiver um bot ou automação que só precisa interagir com comentários, poderá dar a ele um PAT apenas com esse 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 de Pull Request

A nova experiência de solicitação de pull foi aprimorada com o seguinte:

• 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 tique verde nas checagens necessárias mascara as falhas nas checagens opcionais. Os usuários só podiam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores não costumam fazer isso quando não há indicação de um problema. Nessa implantação, tornamos o status das verificações opcionais mais visível no resumo.

• Ctrl-clique em itens de menu

Os menus de abas em uma PR não davam suporte a Ctrl+clique. Os usuários geralmente abrem novas guias do navegador enquanto analisam um pull request. Esse problema foi corrigido.

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

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

• Atualizações do menu suspenso do PR recuperam informações temporais

A lista suspensa para selecionar, atualizar e comparar arquivos em uma PR perdeu um elemento importante na experiência de visualização. Não apareceu quando essa atualização foi feita. Esse problema foi corrigido.

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

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

• Navegação para commits ancestrais

Na página Commits, você pode comparar as alterações feitas em um commit específico com seu commit pai. No entanto, talvez você queira navegar até o commit pai e entender como esse commit difere de seu próprio pai. Isso geralmente é necessário quando você deseja entender todas as alterações em uma versão. Adicionamos um cartão de pai a um commit para ajudá-lo a conseguir isso.

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

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 modificando o recuo da árvore para corresponder ao nó raiz e ocultando o botão de reticências da página, exceto ao passar o mouse.

Imagem da nova árvore de arquivos:

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 de arquivos de PR

Ao redimensionar o painel de diferenças lado a lado na aba Arquivos do PR, a posição de rolagem do usuário seria perdida. Esse problema foi corrigido; a posição de rolagem do usuário agora é mantida durante o redimensionamento do painel de comparação.

• Pesquisar um commit em um dispositivo móvel

Ao exibir 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 pelo seu hash e abri-lo. Isso foi corrigido agora.

• Uso aprimorado do espaço para a visualização móvel das diferenças de arquivo de PR

Atualizamos esta página para fazer melhor uso do espaço para que os usuários possam ver mais do arquivo em exibições móveis em vez de ter 40% da tela ocupada por um cabeçalho.

• Imagens aprimoradas na exibição de resumo de PR

As imagens editadas em um PR não estavam sendo exibidas na visualização de resumo do PR, mas eram exibidas corretamente na visualização de arquivos do PR. Esse problema foi resolvido.

• Experiência de branch aprimorada ao criar um 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.

Tubulações

Plataforma de agente adicional: ARM64

Adicionamos Linux/ARM64 à lista de plataformas com suporte para o agente do 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 ao filtro de tags para recursos de pipeline

Agora adicionamos 'tags' em 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) executada quando a execução do pipeline de CD (implantação contínua) não é iniciada por alguma outra origem/recurso ou um gatilho de execução agendado.

Por exemplo, se você tiver um gatilho agendado definido para o pipeline de CD que só deseja executar se o IC tiver a tag de produção, as tags na seção de gatilhos garantem que o pipeline de CD só seja acionado se a condição de marcação for satisfeita no evento de conclusão do IC.

Controlar quais tarefas são permitidas nos pipelines

Agora você pode desabilitar as tarefas do Marketplace. Alguns de vocês podem permitir extensões do Marketplace, mas não as tarefas do Pipelines que vêm junto. Para ainda mais controle, também permitimos que você desative todas as tarefas integradas de forma independente (exceto o checkout, que é uma ação especial). Com essas duas 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 de bloqueio exclusivo de implantação

Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente por vez. Ao marcar a opção "Bloqueio exclusivo" no ambiente, apenas uma execução continuará. As execuções subsequentes que desejam implantar nesse ambiente serão pausadas. Assim que a execução com o bloqueio exclusivo for concluída, a próxima execução será iniciada. Quaisquer processos intermediários serão cancelados.

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 escolher acionar seu pipeline de CD após a conclusão de um estágio específico em seu 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 concluídos com êxito no pipeline de CI, uma nova execução é disparada automaticamente para o pipeline de CD.

Gatilhos genéricos baseados em webhook para pipelines YAML

Hoje, temos vários recursos (como pipelines, contêineres, compilações 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 para gatilhos de webhook em pipelines YAML para permitir a integração da automação de pipelines com qualquer serviço externo. Você pode se inscrever em qualquer evento externo por meio de seus webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) e acionar seus pipelines.

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

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

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

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

   • Nome do webhook: 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 de hash da carga para verificação da solicitação. Por exemplo, no caso do GitHub, o cabeçalho da solicitação será "X-Hub-Signature"
   • Segredo - 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 do webhook, precisará fornecer a mesma chave secreta

   

3. Um novo tipo de recurso chamado webhooks foi introduzido em pipelines YAML. Para assinar um evento de webhook, você precisa definir um recurso de webhook em seu pipeline e apontá-lo para a conexão de serviço de webhook de entrada. Você também pode definir filtros adicionais no recurso de webhook com base nos dados de carga JSON para personalizar ainda mais os gatilhos para cada pipeline e pode consumir os dados de carga na forma de variáveis em seus trabalhos.

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 de webhook for recebido pela conexão de serviço de Webhook de entrada, uma nova execução será disparada para todos os pipelines inscritos no evento de webhook.

Suporte e rastreabilidade para problemas de acionamento de recursos YAML

Pode ser confuso quando os gatilhos de pipeline não funcionam como você esperava. 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 ao serem executados 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 aparecem 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 de múltiplos repositórios

Você pode especificar vários repositórios em um arquivo YAML e fazer com que um pipeline seja disparado 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 o arquivo YAML em um repositório separado do código do aplicativo. Você deseja disparar o pipeline sempre que uma atualização é enviada por push para o repositório de aplicativos.

Com essa atualização, os gatilhos de múltiplos repositórios só funcionarão 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 em relação a:

• main branch no repositório self que contém o arquivo YAML
• main ou release ramificações em tools repositório

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

Aprimoramento dos carregamentos de log do agente

Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que ele estava executando é abandonado. Se você estivesse olhando os logs do console de streaming, talvez tenha obtido algumas pistas sobre o que o agente estava fazendo antes de parar de responder. Mas se você não estivesse, ou se atualizasse a página, esses logs do console desapareceriam. 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 podem ocasionalmente estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a resolver problemas em seus próprios pipelines e certamente ajudará nossos engenheiros de suporte quando eles ajudarem na solução de problemas.

Opcionalmente, montar volumes de contêiner em modo somente leitura.

Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o workspace, as tarefas e outros materiais são mapeados como volumes. Esses volumes têm como padrão acesso de leitura/gravação. Para aumentar a segurança, você pode montar os volumes somente para leitura alterando a especificação do contêiner no YAML. Cada chave abaixo mountReadOnly pode ser definida como true somente leitura (o padrão é false).

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

Controle refinado sobre o início/a parada do contêiner

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 iniciá-los e interrompê-los sozinho. Com esta versão, incorporamos esse recurso à tarefa do Docker.

Aqui está um pipeline de exemplo 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 em cadeia de caracteres que mapeia o nome do recurso ("builder" do exemplo acima) para a ID do contêiner que o agente gerencia.

Descompactar pacotes de tarefas para cada etapa

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

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

Com base em nossa iniciativa de aprimorar as configurações de segurança do Azure Pipelines, agora damos suporte à restrição do escopo de tokens de acesso para releases.

Cada trabalho que é executado em liberações obtém um token de acesso. O token de acesso é usado para suas tarefas e por seus scripts para se conectar novamente ao 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 para o Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.

Com esta atualização, trabalhamos para aprimorar a segurança do pipeline restringindo o escopo dos tokens de acesso e estendendo essa melhoria 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 coleção Configurações > Pipelines >. > Limite o escopo de autorização do trabalho ao projeto atual para pipelines de lançamento. Saiba mais aqui.

Aprimoramentos da API de versão prévia do YAML

Agora você pode visualizar o YAML completo de um pipeline sem executá-lo. Além disso, criamos uma nova URL dedicada para o recurso de visualização. Agora você pode POST em https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview para recuperar o corpo YAML finalizado. Essa nova API usa os mesmos parâmetros que o enfileiramento de uma execução, mas não requer mais a permissão "Builds de fila".

Execute este trabalho em seguida

Você já teve uma correção de bug que precisava implantar neste minuto , mas teve que esperar por trabalhos de CI e RP? Com esta atualização, agora permitimos que você priorize a execução de uma tarefa que está na fila. Os usuários com a permissão "Gerenciar" no pool — normalmente administradores de pool — verão um novo botão "Executar em seguida" na página de detalhes da tarefa. 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 YAML resources

Anteriormente, expressões de tempo de compilação () não eram permitidas na seção resources de um arquivo YAML do Azure Pipelines. Com esta versão, suspendemos essa restrição para contêineres. Isso permite que você use o parâmetro de tempo de execução nos seus recursos, por exemplo, para escolher um contêiner no momento da fila. Planejamos estender esse suporte a outros recursos ao longo do tempo.

Controle sobre atualizações de tarefas automatizadas do Marketplace

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

Não recomendamos que você faça isso regularmente e sugere-se usá-lo apenas como uma solução temporária quando descobrir que uma tarefa mais recente interrompe seus pipelines. Além disso, isso não instalará uma versão mais antiga de uma tarefa do Marketplace. Ele já deve existir em sua coleção ou seu pipeline falhará.

Exemplo:

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

Suporte à versão 10 do Node no agente e nas 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% das tarefas da caixa de entrada para o Node 10. O agente agora pode executar tarefas tanto no Node.js 6 quanto no Node.js 10. Em uma atualização futura, removeremos totalmente o Nó 6 do agente. Para se preparar para a remoção do Node 6 do agente, solicitamos que você atualize suas extensões internas e tarefas personalizadas para que também comecem a usar o Node 10 em breve. Para usar o Node 10 para sua tarefa, em task.json, dentro de execution, atualize de Node para Node10.

Aprimorar a conversão de YAML no designer de build clássico

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

A nova função de exportação substitui a função "Exibir como YAML" encontrada anteriormente no designer de build 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 essa 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 adicionado. Você também pode exibir políticas de nível de projeto e a lista de políticas entre repositórios na guia Políticas.

Se você clicar em um repositório, poderá visualizar políticas e permissões definidas no nível do repositório. Na aba de políticas, você pode visualizar uma lista de cada branch em que a política está definida. Agora, clique no branch 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 superior ao que você está utilizando, mostramos ao lado de cada política individual de onde ela foi herdada. Você também pode navegar até a página em que 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 recolhíveis! Para melhorar a experiência de procurar uma política específica de Validação de Build, Verificação de Status ou Revisor Automático, adicionamos filtros de pesquisa para cada seção.

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

O aplicativo Azure Pipelines para ServiceNow ajuda você a integrar o Azure Pipelines e o Gerenciamento de Alterações do ServiceNow. Com essa atualização, levamos nossa jornada de tornar o Azure Pipelines ciente do processo de gerenciamento de alterações gerenciado no ServiceNow além dos pipelines YAML.

Ao configurar a verificação "Gerenciamento de Alterações do ServiceNow" 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.

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

Artefatos

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

Estamos trazendo de volta a capacidade dos clientes de criar e gerenciar feeds com escopo de coleção por meio da interface do usuário da Web para serviços locais e hospedados.

Agora você pode criar feeds no escopo da organização por meio da interface do usuário, indo para Artefatos -> Criar Feed e escolhendo um tipo de feed no Escopo.

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

A API REST de atualização da versão do pacote já está disponível para pacotes do Maven

Agora você pode usar a API REST "Atualizar Versão do Pacote" do Azure Artifacts para atualizar as versões do pacote Maven. Anteriormente, você podia usar a API REST para atualizar versões de pacote 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	In	Obrigatório	Tipo	Descrição
artifactId	caminho	VERDADEIRO	string	ID do artefato do pacote
feed de notícias	caminho	VERDADEIRO	string	Nome ou ID do feed
ID do grupo	caminho	VERDADEIRO	string	ID do grupo do pacote
coleção	caminho	VERDADEIRO	string	O nome da coleção do Azure DevOps
versão	caminho	VERDADEIRO	string	Versão do pacote
projeto	caminho		string	ID do projeto ou nome do projeto
versão da API	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

Corpo da solicitação

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

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

Comentários

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

---

Início da página