Notas de versão do Azure DevOpsServer 2020 Atualização 1
| Developer Community System Requirements | License Terms | DevOps Blog | SHA-1 Hashes
Neste artigo, você encontrará informações sobre a versão mais recente para Azure DevOps Server.
Para saber mais sobre como instalar ou atualizar uma implantação de Azure DevOps Server, consulte Requisitos de Azure DevOps Server. Para baixar produtos do Azure DevOps, visite a página Azure DevOps Server Downloads.
Há suporte para a atualização direta para Azure DevOps Server 2020 do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para o Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps localmente.
Atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020
Azure DevOps Server 2020 introduz um novo modelo de retenção de execução de pipeline (build) 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 em 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 retidas por uma versão não serão excluídas após a atualização.
Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020.
Azure DevOps Server Atualização 1.2 de 2020 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 depois de instalar o Patch 12.
Azure DevOps Server atualização 1.2 data de lançamento do Patch 12 do Azure DevOps Server 2020: 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 proxy era calculado incorretamente e a pasta não era limpa corretamente.
- CVE-2024-20667: Azure DevOps Server vulnerabilidade de execução remota de código.
Azure DevOps Server Atualização 1.2 de 2020 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 Atualização 1.2 de 2020 que inclui correções para o seguinte:
- Correção de um bug em que a herança de segurança de aprovação de pré-implantação não estava funcionando em estágios de pipelines.
Azure DevOps Server Atualização 1.2 de 2020 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.
- Estendeu a lista de caracteres permitido das tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas de shell.
Observação
Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente as tarefas.
Instalar patches
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 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á a 3.225.0.
Configurar o TFX
- Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.
Atualizar tarefas usando TFX
| Arquivo | Hash SHA-256 |
|---|---|
| Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- Baixe e extraia Tasks20231103.zip.
- Altere o diretório para os arquivos extraídos.
- Execute os seguintes comandos para carregar as tarefas:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip
Requisitos de pipeline
Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true deve ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia variável no pipeline.
Exemplo de YAML:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
data de lançamento do Patch 9 da atualização 1.2 do Azure DevOps Server 2020: 10 de outubro de 2023
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 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á a 3.225.0.
Lançamos um patch. para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Correção de um bug em que a identidade "Proprietário da Análise" aparece como Identidade Inativa em computadores de atualização de patch.
data de lançamento do Patch 8 da atualização 1.2 do Azure DevOps Server 2020: 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: Azure DevOps Server vulnerabilidade de execução remota de código.
- CVE-2023-38155: Azure DevOps Server e a Vulnerabilidade de Elevação de Privilégio do Team Foundation Server.
Importante
Implante o patch em um ambiente de teste e verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.
Observação
Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente o agente e as tarefas.
Instalar patches
- Baixe e instale Azure DevOps Server patch 8 da Atualização 1.2 de 2020.
Atualizar o agente do Azure Pipelines
- Baixe o agente de: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
- Use as etapas descritas na documentação de agentes auto-hospedados do Windows para implantar o agente.
Observação
O AZP_AGENT_DOWNGRADE_DISABLED deve ser definido como "true" para impedir que o agente seja rebaixado. No Windows, o comando a seguir pode ser usado em um prompt de comando administrativo, seguido de uma reinicialização. setx AZP_AGENT_DOWNGRADE_DISABLED true /M
Configurar o TFX
- Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.
Atualizar tarefas usando TFX
- Baixe e extraia Tasks_20230825.zip.
- Altere o diretório para os arquivos extraídos.
- Execute os seguintes comandos para carregar as tarefas:
tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip
Requisitos de pipeline
Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true deve ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia variável no pipeline.
Exemplo de YAML:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server Atualização 1.2 data de lançamento do Patch 7 de 2020: 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: Azure DevOps Server vulnerabilidade de falsificação.
- 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 o RSA, atualize para SHA2 ou remova a entrada.
- Resolvido o problema com links relativos que não funcionam em arquivos markdown.
- Correção de um bug com navegação de comentário em uma página de confirmação.
- Correção de um bug em que a identidade do Proprietário da Análise era mostrada como Identidade Inativa.
- Correção do bug de loop infinito em CronScheduleJobExtension.
data de lançamento do Patch 6 da atualização 1.2 do Azure DevOps Server 2020: 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: Azure DevOps Server vulnerabilidade de falsificação.
- CVE-2023-21569: Azure DevOps Server vulnerabilidade de falsificação.
- Corrigido um bug que interferia no envio de pacotes por push durante a atualização de 2018 ou anterior.
- Corrigido um bug em que a coleção de desanexação ou anexação falha ao relatar o seguinte erro: 'TF246018: a operação de banco de dados excedeu o limite de tempo limite e foi cancelada.
data de lançamento do Patch 5 da atualização 1.2 do Azure DevOps Server 2020: 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: Azure DevOps Server vulnerabilidade de execução remota de código
- Correção do problema de acessibilidade de conjuntos de prateleiras por meio da interface do usuário da Web
- Os clientes precisam reiniciar o serviço tfsjobagent e Azure DevOps Server pool de aplicativos depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento de Azure DevOps Server.
Azure DevOps Server atualização 1.2 data de lançamento do Patch 4 da atualização 2020: 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.
- Exibição fixa de caracteres especiais no IdentityPicker.
- Os dados de teste não estavam sendo excluídos, fazendo com que o banco de dados crescesse. Com essa correção, atualizamos a retenção de build para evitar a criação de novos dados de teste órfãos.
data de lançamento do Patch 3 da atualização 1.2 do Azure DevOps Server 2020: 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.
- Corrija um problema com o filtro Solicitado por Membro do Grupo nas configurações do web hook.
- Corrija o erro de builds de marcar em gated quando as configurações da organização para pipeline tinham o escopo de autorização de trabalho configurado como Escopo de autorização de trabalho limite para o projeto atual para pipelines de não lançamento.
- Correção da recuperação do token de acesso do Azure ao estabelecer a conexão de serviço por trás do proxy autenticado.
data de lançamento do Patch 2 Azure DevOps Server 2020: 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.
data de lançamento do Patch 1 da atualização 1.2 do Azure DevOps Server 2020: 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.
- Em APIs de Execuções de Teste, o token de continuação que está sendo retornado era maior que o valor "maxLastUpdatedDate" especificado.
data de lançamento da Atualização 1.2 do Azure DevOps Server 2020: 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 Atualização 1.2 de 2020 ou atualizar do Azure DevOps Server 2020 ou do Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 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 no Azure DevOps Server 2020), para evitar a perda de execuções de pipeline (builds). Isso significa que o sistema:
- Criar concessões para os três builds mais recentes gerados durante a execução do Server 2020
- Para pipelines YAML e pipelines clássicos sem políticas de retenção por pipeline, as compilações serão mantidas de acordo com as configurações de retenção máxima no nível da coleção
- Para pipelines clássicos com políticas de retenção por pipeline personalizadas, os builds serão retidos de acordo com a política de retenção específica do pipeline
- Os builds com concessões não contam para o Mínimo para manter a configuração
Os links de comentários de conjunto de alterações e de conjunto de prateleiras não estavam redirecionando corretamente. Quando os comentários foram adicionados aos arquivos em conjuntos de alterações ou conjuntos de prateleiras, a seleção desses comentários não estava redirecionando para o lugar correto no modo de exibição de arquivo.
Não é possível ignorar a fila de build usando o botão "Executar próximo". Anteriormente, o botão "Executar em seguida" era habilitado apenas para administradores de coleção de projetos.
Revogue todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário estiver 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.
- Email notificações 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 resultou 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, em seguida, desapareceu.
- Melhoria na sincronização de usuários do Active Directory.
- Resolvido a vulnerabilidade do Elasticsearch removendo a classe jndilookup dos binários log4j.
Etapas de instalação
- Atualize o servidor com o Patch 4.
- Verifique o valor do Registro em
HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1). - Execute o comando
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation updateupdate conforme fornecido no arquivo readme. Ele pode retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização está executando novas tentativas até que ela seja concluída.
Observação
Se Azure DevOps Server e Elasticsearch estiverem instalados em computadores diferentes, siga as etapas descritas abaixo.
- Atualize o servidor com o Patch 4.
- Verifique o valor do Registro em
HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1). - Copie o conteúdo da pasta chamada zip, localizada na
C:\Program Files\{TFS Version Folder}\Search\zippasta de arquivo remoto Elasticsearch. - Execute
Configure-TFSSearch.ps1 -Operation updateno computador do servidor 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.
- Correção da 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 do caractere de 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 email.
- 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 o GitHub Enterprise Server. Com esse patch, os administradores de projeto podem criar conexões entre Azure DevOps Server e repositórios em 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 do problema com a página resumo de Visão Geral do Projeto falhando ao carregar.
- Corrija o problema com emails que não estão sendo 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.
- Corrigir falha de download/upload do Artifacts.
- Resolva o problema com dados inconsistentes dos Resultados do Teste.
data de lançamento da Atualização 1.1 do Azure DevOps Server 2020: 17 de agosto de 2021
Azure DevOps Server Atualização 1.1 de 2020 é um acúmulo de correções de bugs. Você pode instalar diretamente Azure DevOps Server Atualização 1.1 de 2020 ou atualizar do Azure DevOps Server 2020 ou do Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 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
- Correção das caixas de seleção de herança de tipos de mesclagem limitadas exibidas para habilitar a modificação de tipos de mesclagem de limite após a configuração de políticas de repositório cruzado.
Azure Pipelines
- Ao alterar a configuração de Atualização do Agente, as configurações não eram propagadas para outras camadas de aplicativo no ambiente.
Geral
- Correção da 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.
data de lançamento do Patch 2 do Azure DevOps Server 2020.1: 10 de agosto de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
- Correção do erro de interface do usuário da definição de build.
- Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.
data de lançamento do Patch 1 do Azure DevOps Server 2020.1: 15 de junho de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
Proteger cookies usados em fluxos de autorização que declaram
SameSite=None.Resolva o problema com o SDK de Notificações. Anteriormente, as assinaturas de notificações usando o filtro Caminho da Área não estavam sendo analisadas corretamente.
data de lançamento do RTW Azure DevOps Server 2020.1: 25 de maio de 2021
Resumo das novidades no Azure DevOps Server 2020.1 RTW
Azure DevOps Server RTW 2020.1 é um acúmulo de correções de bugs. Ele inclui todos os recursos no Azure DevOps Server 2020.1 RC2 lançado anteriormente. Azure DevOps Server RTW 2020.1 é um acúmulo de correções de bugs. Você pode instalar diretamente o Azure DevOps Server 2020.1 ou atualizar do Azure DevOps Server 2020, 2019 ou do 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 data de lançamento do RC2 2020.1: 13 de abril de 2021
Resumo das novidades no Azure DevOps Server 2020.1 RC2
Azure DevOps Server RC2 2020.1 é um acúmulo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server RC1 2020.1 lançado anteriormente.
data de lançamento do RC1 Azure DevOps Server 2020.1: 23 de março de 2021
Resumo das novidades no Azure DevOps Server RC1 2020.1
Azure DevOps Server RC1 2020.1 apresenta muitos novos recursos. Alguns dos destaques incluem:
- Regras de restrição de transição de estado em Quadros
- Os stakeholders agora podem mover itens de trabalho entre colunas de quadro
- Melhorar a segurança da versão restringindo o escopo dos tokens de acesso
- Experiência de solicitação de pull aprimorada
- Gatilhos de vários repositórios em pipelines
Você também pode ir para seções individuais para ver todos os novos recursos para 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 itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode restringir bugs de ir de Novo para Resolvido. Em vez disso, eles devem ir de Novo –> Ativo –> Resolvido
Você também pode criar uma regra para restringir as transições de estado por associação de grupo. Por exemplo, somente usuários no grupo "Aprovadores" podem mover histórias de usuários 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).
Regras aprimoradas para campos ativados e resolvidos
Até agora, as regras para Ativado por, Data Ativada, Resolvido por e Data Resolvida 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 "Ativo" e "Resolvido". Alteramos a lógica para que essas regras não sejam mais para um estado específico. Em vez disso, eles são disparados pela categoria (categoria de estado) na qual 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 Ativada, Resolvido por e Data Resolvida , sem a necessidade de usar regras personalizadas.
Os stakeholders podem mover itens de trabalho entre colunas de quadro
Os stakeholders sempre foram capazes de alterar o estado dos itens de trabalho. Mas quando eles vão para o quadro Kanban, eles são incapazes de 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 de estado. Este tem sido um ponto problemático para os clientes, e estamos felizes em anunciar que agora você pode mover itens de trabalho entre colunas de quadro.
Tipos de item de trabalho do sistema em listas de pendências e placas
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ó estão disponíveis em consultas.
| Processar | Tipo de Item de Trabalho |
|---|---|
| Agile | Problema |
| Scrum | Impedimento |
| CMMI | Solicitação de Mudança |
| 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 no processo personalizado e clicar na guia Níveis de Lista de Pendências. Selecione o nível de lista de pendências de sua escolha (exemplo: Lista de pendências de requisitos) e escolha a opção editar. Em seguida, adicione o tipo de item de trabalho.
Azure Boards limite de repositório de aplicativos do GitHub gerado
O limite de repositório para o aplicativo Azure Boards no marketplace do GitHub 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 for concluída. Outras pessoas desejam definir os itens de trabalho para outro estado a serem validados antes do fechamento. Devemos permitir para 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 de estado seguido pelo #menção dos itens de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvido e fechando duas tarefas.
Vincular seu item de trabalho a builds em outro projeto
Agora você pode acompanhar facilmente suas dependências de build no projeto apenas vinculando seu item de trabalho a um Build, Encontrado no build ou Integrado no build.
Editando a descrição (texto da ajuda) nos 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 Herdado que impedia alguns clientes de migrar para o modelo Herdado. Agora você pode editar a descrição nos campos do sistema. O valor editado afetará apenas esse campo no processo e para esse tipo de item de trabalho. Isso oferece 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
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, resolve algumas delas e manter o restante aberto. Agora você pode usar comentários como os mostrados na figura abaixo para fazer isso. Confira a documentação para obter mais detalhes.
Campo pai no quadro de tarefas
Devido à solicitação popular, agora você pode adicionar o campo Pai aos cartões filho e pai no Quadro de Tarefas.
Removendo a regra "Atribuído a" no tipo de item de trabalho bug
Há várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho em Agile, Scrum e CMMI. Essas regras existem há mais de uma década e geralmente funcionam bem sem reclamações. No entanto, há algumas regras que acabaram suas boas-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 usando um 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 executar 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 os itens que você criou ou que são atribuídos a você, entre outras coisas. Ele fornece vários pivôs e filtros personalizados. Uma das principais reclamações do 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 são mais de 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 da tabela dinâmica 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 Git. Nas configurações do repositório, você pode escolher qualquer nome de branch legal a ser usado quando um repositório é inicializado. Azure Repos sempre deu suporte à alteração do nome do branch padrão para um repositório existente. Visite Gerenciar branches para obter mais detalhes.
Observação: se você não habilitar esse recurso, seus repositórios serão inicializados com o nome padrão do Azure Repos. No momento, esse padrão é master. Para respeitar o compromisso da Microsoft e as solicitações do cliente para uma linguagem inclusiva, vamos nos juntar aos pares do setor para alterar esse padrão para main. Essa mudança ocorrerá no final deste verão. Se quiser continuar usando master, você deverá ativar esse recurso agora e defini-lo como master.
Configuração no nível da organização para branch padrão
Agora há uma configuração de nível de coleção para seu nome de branch inicial preferencial para novos repositórios. Se um projeto não tiver escolhido um nome de branch 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 contribuir com comentários de PR
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 tiver sido 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 falham. No entanto, esse não é o caso na experiência de visualização. Uma marca de seleção grande e verde nas verificações necessárias mascara as falhas em verificações opcionais. Os usuários só puderam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores geralmente não fazem isso quando não há indicação de um problema. Nesta implantação, tornamos a status de verificações opcionais mais visível no resumo.
- Ctrl-clicks em itens de menu
Os menus de tabulação em uma PR não dão suporte a Ctrl-click. Os usuários geralmente abrem novas guias do navegador à medida que examinam uma solicitação de pull. Esse problema foi corrigido.
- Local da anotação [+]
A lista de árvores 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 arquivo mais longos.
- As 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. Ele não mostrou quando essa atualização foi feita. Esse problema foi corrigido.
- **Layout de filtro de comentário 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 pai
Na página Confirmações, você pode comparar as alterações feitas em um commit específico com sua confirmação pai. No entanto, talvez você queira navegar até o commit 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 pai a um commit para ajudá-lo a conseguir isso.
- Mais espaço para pastas e arquivos com nomes longos na guia 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 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 é retido em um painel de comparação redimensionar.
- 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 encontrar um commit por seu hash e abri-lo. Isso foi corrigido agora.
- Melhor uso de espaço para o novo modo de exibição móvel de comparação de arquivos de PR
Atualizamos esta página para fazer melhor uso do espaço para que os usuários possam ver mais do arquivo em modos de exibição móveis em vez de ter 40% da tela tomada por um cabeçalho.
- Imagens aprimoradas na exibição de resumo de PR
As imagens editadas em uma PR não eram exibidas na exibição de resumo de PR, mas eram mostradas corretamente na exibição de arquivos de PR. Esse problema foi resolvido.
- Experiência de branch aprimorada ao criar uma nova PR
Antes dessa atualização, essa experiência não era ideal, pois comparava as alterações com o branch padrão do repositório em vez do comparar branches.
Pipelines
Plataforma de agente adicional: ARM64
Adicionamos o Linux/ARM64 à lista de plataformas com suporte para o agente do Azure Pipelines. Embora as alterações de código tenham sido mínimas, muitos trabalhos nos bastidores tiveram que ser concluídos primeiro, e estamos animados para anunciar seu lançamento!
Suporte a filtro de marca para recursos de pipeline
Agora adicionamos 'tags' em pipelines YAML. Você pode usar marcas para definir o pipeline de CI a ser executado ou quando disparar automaticamente.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: master
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 algum outro recurso/origem ou um gatilho de execução agendado.
Por exemplo, se você tiver um gatilho agendado definido para o pipeline de CD que você só deseja executar se a CI tiver a marca de produção, as marcas na seção gatilhos garantirão que o pipeline de CD só seja disparado se a condição de marcação for atendida pelo evento de conclusão da CI.
Controlar quais tarefas são permitidas em pipelines
Agora você pode desabilitar tarefas do Marketplace. Alguns de vocês podem permitir extensões do Marketplace, mas não as tarefas de Pipelines que elas trazem. Para obter ainda mais controle, também permitimos que você desabilite independentemente todas as tarefas in-the-box (exceto o check-out, que é uma ação especial). Com essas duas configurações habilitadas, as únicas tarefas permitidas para execução 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 tarefa" 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 o marcar "Bloqueio exclusivo" em um ambiente, apenas uma execução continuará. As execuções subsequentes que desejam implantar nesse ambiente serão pausadas. Depois que a execução com o bloqueio exclusivo for concluída, a execução mais recente continuará. Todas as execuções intermediárias serão canceladas.
Filtros de estágios para gatilhos de recursos de pipeline
Adicionamos suporte para "estágios" como um filtro para recursos de pipeline no YAML. Com esse filtro, você não precisa aguardar a conclusão de todo o pipeline de CI para disparar o pipeline de CD. Agora você pode optar por disparar o pipeline de CD após a conclusão de um estágio específico no pipeline de CI.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Production
Quando os estágios fornecidos no filtro de gatilho são 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 pôde automatizar seu processo de implantação com base em outros eventos ou serviços externos. Nesta versão, estamos introduzindo o suporte a gatilhos de webhook em pipelines YAML para habilitar a integração da automação de pipeline com qualquer serviço externo. Você pode assinar eventos externos por meio de seus webhooks (Github, Github Enterprise, Nexus, Aritfactory etc.) e disparar seus pipelines.
Estas são as etapas para configurar os gatilhos de webhook:
Configure um webhook em seu serviço externo. Ao criar o webhook, você precisa fornecer as seguintes informações:
- Url de Solicitação – "https://dev.azure.com/<Coleção> do ADO/_apis/public/distributedtask/webhooks/<Nome >do WebHook?api-version=6.0-preview"
- Segredo – isso é opcional. Se você precisar proteger seu conteúdo JSON, forneça o valor de Segredo
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 de conteúdo para verificação de 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 conteúdo usado para verificação da solicitação de entrada (isso é opcional). Se você tiver usado um segredo na criação do webhook, precisará fornecer a mesma chave secreta
Um novo tipo de recurso chamado
webhooksfoi 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 conteúdo JSON para personalizar ainda mais os gatilhos para cada pipeline, e você 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}}
- Sempre que um evento de webhook for recebido pela conexão de serviço 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 chamada "Problemas de gatilho" em que são exibidas informações sobre por que os gatilhos não estão sendo executados.
Os gatilhos de recurso podem falhar ao serem executados por dois motivos.
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. Eles são exibidos como erros.
Se as condições de 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 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 para 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 funcionarão apenas para repositórios Git em Azure Repos. Eles não funcionam para recursos do 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:
mainbranch noselfrepositório que contém o arquivo YAMLmainoureleasebranches notoolsrepositório
Para obter mais informações, consulte Vários repositórios em seu pipeline.
Uploads de log do agente aprimorados
Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho em execução fica abandonado. Se você estava olhando para 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 estava, ou se você atualizou a página, esses logs de console tinham sumido. Com essa 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 1.000 caracteres por linha e, ocasionalmente, podem estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a solucionar 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 somente leitura
Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o workspace, tarefas e outros materiais são mapeados como volumes. Esses volumes são padrão para acesso de leitura/gravação. Para aumentar a segurança, você pode montar os volumes somente leitura alterando sua especificação de contêiner no YAML. Cada chave em mountReadOnly pode ser definida true como 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/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, talvez você queira iniciá-los e pará-los por conta própria. Com esta versão, criamos essa funcionalidade na tarefa do Docker.
Aqui está um exemplo de pipeline usando a nova funcionalidade:
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 mapeando o nome do recurso ("construtor" do exemplo acima) para a ID de 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 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 com o código não confiável que altera 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.
Melhorar a segurança da versão restringindo o escopo dos tokens de acesso
Com base em nossa iniciativa para 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 pelos 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 no Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.
Com essa atualização, nos baseamos em melhorar a segurança do pipeline restringindo o escopo dos tokens de acesso e estendendo o mesmo para versões clássicas.
Esse recurso estará ativado por padrão para novos projetos e coleções. Para coleções existentes, você deve habilitá-la na coleção Configurações Configurações > de Pipelines > Configurações. > Limite o escopo de autorização de trabalho ao projeto atual para pipelines de lançamento. Saiba mais aqui.
Aprimoramentos da API de visualização do YAML
Agora você pode visualizar o YAML completo de um pipeline sem executá-lo. Além disso, criamos uma NOVA URL dedicada para a funcionalidade de visualização. Agora você pode POSTAR 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 enfileirar uma execução, mas não requer mais a permissão "Compilações de fila".
Execute este trabalho em seguida
Você já teve um bugfix que precisava implantar neste minuto, mas teve que esperar por trás dos trabalhos de CI e PR? 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 próximo" 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 de 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 resources seção de um arquivo YAML do Azure Pipelines. Com esta versão, levantamos essa restrição para contêineres. Isso permite que você use o conteúdo do parâmetro de runtime 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
Ao escrever um pipeline YAML, normalmente você especifica apenas o número de versão principal das tarefas incluídas. Isso permite que seus pipelines executem automaticamente as adições de recursos e correções de bugs mais recentes. Ocasionalmente, talvez seja necessário reverter para uma versão de ponto 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 alternativa temporária quando descobrir que uma tarefa mais recente quebra 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 o 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 em tarefas e agente
Como o Nó 6 não tem mais suporte, estamos migrando as tarefas para trabalhar com o Nó 10. Para essa 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 Node 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 task.jsonexecution, atualize de Node para Node10.
Melhorar a conversão yaml no designer de build clássico
Com esta versão, apresentamos um novo recurso "exportar para YAML" para pipelines de build de designer. Salve a definição do pipeline e localize "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 o build, o que às vezes levava à geração incorreta de YAML. 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 só torna a experiência mais rápida e moderna, mas também fornece um ponto de entrada único para todas as políticas do nível do projeto até o nível do branch.
Com essa nova experiência, a navegação para projetos com um número substancial de repositórios tornou-se mais fácil devido a tempos de carga mais rápidos e 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á exibir 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 todas as políticas sem sair da página Configurações do Repositório.
Agora, quando as políticas são herdadas de um escopo mais alto do que o que você está trabalhando, mostramos 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.
A própria página de política também foi atualizada para a nova plataforma Web com seções recolhidas! 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 de gerenciamento de alterações do ServiceNow com pipelines YAML
O aplicativo Azure Pipelines para ServiceNow ajuda você a integrar o Azure Pipelines e o ServiceNow Change Management. Com essa atualização, fazemos nosso percurso de tornar o Azure Pipelines ciente do processo de gerenciamento de alterações gerenciado no ServiceNow ainda mais para pipelines YAML.
Ao configurar o "ServiceNow Change Management" marcar em um recurso, agora você pode pausar para que a alteração seja aprovada antes de implantar o build nesse recurso. Você pode criar automaticamente uma nova alteração para um estágio ou aguardar em uma solicitação de alteração existente.
Você também pode adicionar a UpdateServiceNowChangeRequest tarefa em um trabalho de servidor para atualizar a solicitação de alteração com status de implantação, anotações etc.
Artifacts
Capacidade de criar feeds no escopo da organização 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 local 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.
Embora seja recomendável o uso de feeds no escopo do projeto em alinhamento com o restante das ofertas do Azure DevOps, você pode criar, gerenciar e usar feeds com escopo de coleção por meio da interface do usuário e várias APIs REST. Consulte nossa documentação de feeds para obter mais informações.
Atualizar a API REST da versão do pacote agora disponível para pacotes 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 as versões do pacote para Pacotes NuGet, Maven, npm e Universal, mas não pacotes Maven.
Para atualizar os pacotes do Maven, use o comando PATCH HTTP 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 | Necessá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 exibição à qual a versão do pacote será adicionada |
Para obter mais informações, consulte a documentação da API REST conforme ela é atualizada.
Comentários
Adoraríamos ouvir sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo por meio de Developer Community e obter conselhos sobre o Stack Overflow.