Compartilhar via

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

  • Artigo

Requisitos | do sistema da comunidade | de desenvolvedores 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 Downloads do Azure DevOps Server.

A atualização direta para Azure DevOps Server 2020 tem suporte de Azure DevOps Server 2019 ou Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para 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 de execução (build) de pipeline que funciona com base nas configurações no nível do projeto.

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

Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança 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 Azure DevOps Server Atualização 1.2 de 2020 para incluir uma atualizaçã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 Azure DevOps Server Atualização 1.2 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 Azure DevOps Server Atualização 1.2 de 2020 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 segurança de aprovação de pré-implantação não estava funcionando nos estágios de 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 Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.

  • Estendida a lista de caracteres permitidos de tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de 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 patches

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 da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.

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 Azure DevOps Server Atualização 1.2 de 2020 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 Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.

  • 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 patches

  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 evitar 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 o TFX

  1. Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.

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 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 7: 8 de agosto de 2023

Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 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 as ligações relativas não funcionavam em ficheiros 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 Azure DevOps Server Atualização 1.2 de 2020 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 bug que interferia no envio de pacotes ao atualizar de 2018 ou anterior.
  • Corrigido um bug em que desanexar ou anexar coleção falha, 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 Data de lançamento do Patch 5: 14 de fevereiro de 2023

Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 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 check-ins particulares 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 Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.

  • Corrigida a exibição de caracteres especiais no IdentityPicker.

Gif para demonstrar caracteres especiais no IndetityPicker.

  • 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 Data de lançamento do Patch 3: 18 de outubro de 2022

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

  • Resolva o problema com identidades do AD recém-adicionadas que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
  • Correção de um problema com o filtro Solicitado pelo membro do grupo nas configurações do web hook.
  • Correção do erro de builds de check-in 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 de não 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 Azure DevOps Server Atualização 1.2 de 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 Atualização 1.2 de 2020 que inclui correções para o seguinte.

  • Nas APIs de Execuções de Teste, o token de continuação que está sendo 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 Atualização 1.2 de 2020 é 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 Azure DevOps Server Atualização 1.2 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.

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

  • Azure DevOps Server 2020.1.2 desabilita o novo modelo de retenção (introduzido em Azure DevOps Server 2020), para evitar a perda de execuções de pipeline (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 clássicos sem políticas de retenção por pipeline, os builds serão retidos de acordo com as configurações máximas de retenção no nível da coleção
    • Para pipelines clássicos com políticas de retenção personalizadas por pipeline, os builds serão retidos de acordo com a política de retenção específica do pipeline
    • As compilações com concessões não contam para o Mínimo para continuar definindo

  • Os links de comentários do conjunto de alterações e do check-in particular não estavam redirecionando corretamente. Quando os comentários eram adicionados a arquivos em conjuntos de alterações ou check-ins particulares, a seleção desses comentários não redirecionava para o local correto na exibiçã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 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 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 do Teste.

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

Azure DevOps Server Atualização 1.1 de 2020 é 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

  • Corrigidas as caixas de seleção de herança de tipos de mesclagem limitados exibidas para habilitar a modificação dos tipos de mesclagem de limite após a configuração de políticas de configuração cruzada.

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 da interface do usuário de definição de compilação.
  • 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:

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

Boards

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

img

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" à caixa de diálogo copiar item de trabalho. Quando selecionada, essa opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).

Esta página mostra a nova opção em Azure Boards para Incluir itens de trabalho filho em um item de trabalho copiado.

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 Teste", as regras Resolvido por e 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, os Stakeholders 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 item de trabalho só estavam disponíveis em consultas.

Processo Tipo de Item de Trabalho
Agile 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 lista de pendências de sua escolha (exemplo: Lista de Pendências de Requisitos) e escolha a opção de edição. Em seguida, adicione o tipo de item de trabalho.

Atrasos

Limite de repositório de aplicativo GitHub do Azure Boards gerado

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 pelo #mention dos itens de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvidas e fechando duas tarefas.

estado do item de trabalho

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.

Vincular itens de trabalho

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.

Editar Descrição

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.

Personalizar estado

Campo pai no painel de tarefas

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

Quadro de tarefas do campo pai

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 se esgotaram. 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 no blog sobre as etapas que você pode seguir para adicionar novamente a regra em 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 o pivô "Atribuído a mim" é que ele 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í-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 de nome de branch padrão

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 branches e Alterar o branch 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 o nome de branch inicial preferido 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.

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

Adicionar um novo escopo de autenticação para comentários de PR de contribuição

Esta versão adiciona um novo escopo OAuth para ler/gravar comentários de solicitação de pull. 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 solicitação de pull

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 visualização. Uma grande marca de seleção verde nas verificações necessárias mascara as falhas nas verificações 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.


mostrar as verificações opcionais


  • Ctrl-cliques em itens de menu

Os menus de guia em uma PR não davam suporte a Ctrl-clique. Os usuários geralmente abrem novas guias do navegador enquanto analisam uma solicitação de pull. 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.


Mostrar locais de anotações

  • Atualizações de PR suspensas recuperam informações de tempo

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.


Informações de tempo ausentes do menu suspenso de atualizações de PR

  • **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.


Layout de filtro de comentário aprimorado

  • Navegação para commits pai

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é a confirmação pai e entender melhor como essa confirmação 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.


Navegação para commits pai

  • 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:


Mais espaço para pastas e arquivos

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


Exibição do nome

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

Ao redimensionar o painel de comparação lado a lado na guia Arquivos de PR, o local de rolagem do usuário seria perdido. Esse problema foi corrigido; O local de rolagem do usuário agora é mantido em um 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 por seu hash e abri-lo. Isso foi corrigido agora.


Pesquisar um commit em um dispositivo móvel

  • Uso aprimorado de espaço para o novo arquivo de PR com exibição móvel de comparação

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.


Uso aprimorado do novo nome de arquivo PR do espaço

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

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

  • Experiência de branch aperfeiçoada durante a criação de uma 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.


Aprimoramento da experiência da filial

Pipelines

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 snippet acima mostra que as marcas podem ser usadas para determinar a versão padrão do pipeline de CI (integração contínua) a ser executada quando a execução do pipeline de CD (implantação contínua) não é disparada 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 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 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 elas trazem. Para ainda mais controle, também permitimos que você desative de forma independente todas as tarefas prontas para uso (exceto 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 de implantação exclusiva

Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente por vez. Ao escolher a verificação "Bloqueio exclusivo" em um 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 última execução continuará. Quaisquer execuções intermediárias serão canceladas.

Na página Adicionar verificação, selecione Bloqueio Exclusivo para garantir que apenas uma única execução seja implantada em um ambiente por vez.

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 disparar o pipeline de CD. Agora você pode optar por disparar 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, build e pacotes) por meio 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 ao gatilho 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 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 collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"https://dev.azure.com/<
    • 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

    Na página Editar conexão de serviço, configure gatilhos de webhook.

  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}}
  1. 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 de problemas de gatilho de recurso 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 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 são exibidos 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.

    Esta página de definição de pipeline chamada Problemas de gatilho exibe informações sobre por que os gatilhos não estão em execução.

Gatilhos de vários 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 vários repositórios só funcionarão para repositórios Git em 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á disparado se houver atualizações para:

  • main branch no self repositório 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 em 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 solucionar problemas de seus próprios pipelines e certamente ajudará nossos engenheiros de suporte quando eles ajudarem na solução de problemas.

Montar volumes de contêiner somente leitura opcionalmente

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 usam como padrão o acesso de leitura/gravação. Para aumentar a segurança, você pode montar os volumes somente 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 desempenho, ele descompacta as tarefas uma vez por trabalho, mesmo que a tarefa seja usada em várias etapas. Se você tiver dúvidas sobre o código não confiável alterar o conteúdo descompactado, poderá trocar um pouco de desempenho fazendo com que o agente descompacte a tarefa em cada uso. Para habilitar esse modo, passe --alwaysextracttask ao configurar o agente.

Aprimorar a segurança da versão por meio da restrição do 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 versões.

Cada trabalho executado em versões obtém um token de acesso. O token de acesso é usado pelas tarefas e por seus scripts para chamar de volta 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 para o Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.

Com essa atualização, aprimoramos 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 coleção Configurações de pipelines>. > Limite o escopo de autorização de 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 para https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview 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".

Executar este trabalho a seguir

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 versão, agora permitimos que você aumente a prioridade de um trabalho 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 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 YAML resources

Anteriormente, as resources expressões de tempo de compilação (${{ }}) não eram permitidas na seção de um arquivo YAML do Azure Pipelines. Com esta versão, suspendemos essa restrição para contêineres. Isso permite que você use o conteúdo do parâmetro de tempo de execução dentro de 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 usem automaticamente as adições de recursos e correções de bugs mais recentes. Ocasionalmente, pode ser necessário reverter para uma versão pontual anterior de uma tarefa e, com essa atualização, adicionamos a capacidade de fazer isso. 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 use-o 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 ao nó 10 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 in-box para o Nó 10. O agente agora pode executar tarefas do Nó 6 e do Nó 10. Em uma atualização futura, removeremos totalmente o Nó 6 do agente. Para se preparar para a remoção do Nó 6 do agente, solicitamos que você atualize suas extensões internas e tarefas personalizadas para também usar o Nó 10 em breve. Para usar o Nó 10 para sua tarefa, em , em execution, task.jsonatualize 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.

Conversão de nova plataforma web.

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.

Exiba as políticas de repositório cruzado 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 guia políticas, você pode exibir 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.

Selecione branch para ver as políticas.

Agora, quando as políticas são herdadas de um escopo mais alto do que o que você está trabalhando, mostramos de onde a política foi herdada ao lado de cada política individual. 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.

Mostre de onde a política foi herdada.

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.

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.


Integração do gerenciamento de alterações do ServiceNow

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

Artifacts

Capacidade de criar feeds no escopo da organização 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, acessando Artefatos -> Criar feed e escolhendo um tipo de feed no Escopo.

Crie feeds com escopo de coleção selecionando Artefatos, Criar Feed e selecionando um tipo de feed em Escopo.

Embora recomendemos o uso de feeds no escopo do projeto em alinhamento com o restante das ofertas do Azure DevOps, você pode criar, gerenciar e usar novamente feeds no escopo da coleção por meio da interface do usuário 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 TRUE string ID do artefato do pacote
feed caminho TRUE string Nome ou ID do feed
groupId caminho TRUE string ID do grupo do pacote
collection caminho TRUE string O nome da coleção do Azure DevOps
version caminho TRUE string Versão do pacote
project caminho string ID do projeto ou nome do projeto
api-version Consulta TRUE 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
Modos de exibição 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