Azure DevOpsServer 2020 Atualização 1 Notas de versão
Comunidade de Desenvolvedores | Requisitos do Sistema | Termos de Licença | DevOps Blog | Hashes SHA-1
Neste artigo, você encontrará informações sobre a versão mais recente do Azure DevOps Server.
Para saber mais sobre como instalar ou atualizar uma implantação Azure DevOps Server, consulte Azure DevOps Server Requisitos. Para baixar produtos do Azure DevOps, visite a página de Downloads do Azure DevOps Server.
A atualização direta para o Azure DevOps Server 2020 é compatível com o Azure DevOps Server 2019 ou o Team Foundation Server 2015 ou posterior. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps local.
Atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020
Azure DevOps Server 2020 apresenta um novo modelo de retenção para execuções de pipeline que funciona com base nas configurações de nível de projeto.
Azure DevOps Server 2020 lida com a retenção de build de forma diferente, com base nas políticas de retenção no nível do pipeline. Determinadas configurações de política levam à exclusão de execuções de pipeline após a atualização. As execuções de pipeline que foram retidas manualmente ou são mantidas por uma liberação não serão excluídas após a atualização.
Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 14: 12 de novembro de 2024
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch14.exe | 89AF4B1FCA1E2BD813A42F0D3E568E64AB470E5FD0A2F87F9E4894B8CA361420 |
Lançamos o Patch 14 para o Azure DevOps Server 2020 Atualização 1.2 para incluir uma correção para uma dependência vulnerável.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 13: 12 de março de 2024
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch13.exe | 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6 |
Lançamos o Patch 13 para a Atualização 1.2 do Azure DevOps Server de 2020, que inclui correções para o seguinte:
- Resolvido um problema em que o servidor proxy parava de funcionar após a instalação do patch 12.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 12: 13 de fevereiro de 2024
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch12.exe | C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53 |
Lançamos o Patch 12 para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte:
- Corrigido um bug em que o espaço em disco usado pela pasta de cache do proxy era calculado incorretamente e a pasta não era limpa corretamente.
- CVE-2024-20667: vulnerabilidade de execução remota de código do Azure DevOps Server.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 11: 12 de dezembro de 2023
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch11.exe | C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87 |
Lançamos o Patch 11 para Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte:
- Corrigido um bug em que a herança de aprovação de segurança de pré-despacho não estava funcionando nas etapas dos pipelines.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 10: 14 de novembro de 2023
Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte.
- A lista de caracteres permitidos para tarefas do PowerShell foi estendida para Habilitar a validação dos parâmetros de argumentos das tarefas do shell.
Observação
Para implementar correções para este patch, você terá que seguir uma série de etapas para atualizar manualmente as tarefas.
Instalar correções
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 8 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 8, recomendamos que você instale essas atualizações antes de instalar o Patch 10. A nova versão do agente após a instalação do Patch 8 será 3.225.0.
Configurar o TFX
- Siga as etapas na documentação de upload de tarefas para a coleção de projetos para instalar e fazer login com o tfx-cli.
Atualizar tarefas usando o TFX
Arquivo | Hash SHA-256 |
---|---|
Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 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
precisa ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia Variável do pipeline.
Exemplo de YAML:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 9: 10 de outubro de 2023
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 8 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 8, recomendamos que você instale essas atualizações antes de instalar o Patch 9. A nova versão do agente após a instalação do Patch 8 será 3.225.0.
Lançamos um patch. para o Azure DevOps Server 2020 Atualização 1.2, que inclui correções para o seguinte.
- Corrigido um bug em que a identidade "Proprietário da Análise" é exibida como Identidade Inativa em máquinas de atualização de patch.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 8: 12 de setembro de 2023
Lançamos um patch para o Azure DevOps Server 2020, Atualização 1.2, que inclui correções para os seguintes problemas.
- CVE-2023-33136: vulnerabilidade de execução de código remoto do Azure DevOps Server.
- CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.
Importante
Implante o patch em um ambiente de teste e verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.
Observação
Para implementar correções para este patch, você terá que seguir várias etapas para atualizar manualmente o agente e as tarefas.
Instalar correções
- Baixe e instale Azure DevOps Server 2020 Atualização 1.2 patch 8.
Atualizar o agente do Azure Pipelines
- Baixe o agente em: 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
AZP_AGENT_DOWNGRADE_DISABLED precisa ser definido como “true” para impedir o downgrade do agente. No Windows, o comando a seguir pode ser usado em um prompt de comando administrativo, seguido por uma reinicialização. setx AZP_AGENT_DOWNGRADE_DISABLED true /M
Configurar TFX
- Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar e logar com o tfx-cli.
Atualizar tarefas usando o TFX
- 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 Canalização
Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true
precisa ser definida em pipelines que usam as tarefas afetadas.
Sobre o clássico:
Defina a variável na aba de variáveis no pipeline.
Exemplo de YAML:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 7: 8 de agosto de 2023
Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte.
- CVE-2023-36869: vulnerabilidade de falsificação do Azure DevOps Server.
- Atualize o serviço SSH para dar suporte a SHA2-256 e SHA2-512. Se você tiver arquivos de configuração SSH codificados para usar RSA, atualize para SHA2 ou remova a entrada.
- Foi resolvido um problema em que os links relativos não funcionavam em arquivos markdown.
- Corrigido um bug com a navegação de comentários em uma página de confirmação.
- Corrigido um bug em que a identidade do Proprietário da Análise era exibida como Identidade Inativa.
- Corrigido o bug de loop infinito em CronScheduleJobExtension.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 6: 13 de junho de 2023
Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte.
- CVE-2023-21565: vulnerabilidade de falsificação do Azure DevOps Server.
- CVE-2023-21569: vulnerabilidade de falsificação do Azure DevOps Server.
- Corrigido um erro que interferia no envio de pacotes ao realizar a atualização de versões de 2018 ou anteriores.
- Corrigido um bug onde, ao desanexar ou anexar uma coleção, ocorre a falha relatando o seguinte erro: 'TF246018: a operação do banco de dados excedeu o limite de tempo e foi cancelada.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 5: 14 de fevereiro de 2023
Lançamos um patch para Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte.
- CVE-2023-21553: vulnerabilidade de execução remota de código do Azure DevOps Server
- Corrigido o problema de acessibilidade dos conjuntos de alterações por meio da interface do usuário da web
- Os clientes precisam reiniciar o serviço tfsjobagent e o pool de aplicativos Azure DevOps Server depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento Azure DevOps Server.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 4: 13 de dezembro de 2022
Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui as seguintes correções.
- Corrigida a exibição de caracteres especiais no IdentityPicker.
- Os dados de teste não estavam sendo excluídos, fazendo com que o banco de dados crescesse. Com essa correção, atualizamos a retenção de compilação para impedir a criação de novos dados de teste residuais.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 3: 18 de outubro de 2022
Lançamos um patch para o Azure DevOps Server 2020 Atualização 1.2 que inclui correções para os seguintes problemas.
- Resolva o problema com identidades do Active Directory adicionadas recentemente que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
- Correção de um problema com o filtro Solicitado pelo membro do grupo nas configurações do web hook.
- Correção do erro em construções de check-in com controle restrito quando as configurações da organização para o pipeline tinham o escopo de autorização de trabalho configurado como Limitar o escopo de autorização de trabalho ao projeto atual para pipelines que não são de lançamento.
- Corrija a recuperação do token de acesso do Azure ao estabelecer a conexão de serviço por trás do proxy autenticado.
Azure DevOps Server 2020 Atualização 1.2 Patch 2 Data de lançamento: 9 de agosto de 2022
Lançamos um patch para a Atualização 1.2 do Azure DevOps Server 2020 que inclui correções para o seguinte.
- Corrija o erro de valor de identidade ao atribuir um item de trabalho a uma identidade que aparece em domínios diferentes.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 1: 12 de julho de 2022
Lançamos um patch para Azure DevOps Server 2020, Atualização 1.2, que inclui correções para o seguinte.
- Nas APIs de Execuções de Teste, o token de continuação retornado era maior que o valor "maxLastUpdatedDate" especificado.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento: 17 de maio de 2022
Azure DevOps Server 2020 Update 1.2 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.2 ou atualizar de Azure DevOps Server 2020 ou Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para a Atualização 1.2 do Azure DevOps Server 2020 cerca de três semanas após esta publicação. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Esta versão inclui correções para o seguinte:
Azure DevOps Server 2020.1.2 desativa o novo modelo de retenção (introduzido no Azure DevOps Server 2020) para evitar a perda das execuções de pipelines (builds). Isso significa que o sistema irá:
- Criar concessões para as 3 compilações mais recentes geradas durante a execução do Server 2020
- Para pipelines YAML e pipelines Classic sem políticas de retenção por pipeline, os builds serão mantidos de acordo com as configurações máximas de retenção ao nível da coleção.
- Para Pipelines Clássicos com políticas de retenção personalizadas para cada pipeline, os builds serão retidos conforme a política de retenção específica do pipeline.
- As compilações com concessões não contam para o Mínimo necessário para manter a configuração.
Os links de comentários do conjunto de alterações e do shelveset não estavam redirecionando corretamente. Quando os comentários eram adicionados a arquivos em conjuntos de alterações ou shelvesets, selecionar esses comentários não os redirecionava para o local correto na visualização do arquivo.
Não é possível pular a fila de compilação usando o botão "Executar a seguir". Anteriormente, o botão "Executar a seguir" estava habilitado apenas para administradores de coleção de projetos.
Revogue todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário for desabilitada.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 4: 26 de janeiro de 2022
Lançamos um patch para Azure DevOps Server 2020.1.1 que inclui correções para o seguinte.
- As notificações por email não foram enviadas ao usar o @mention controle em um item de trabalho.
- O endereço de email preferencial não estava sendo atualizado no perfil do usuário. Isso resultava no envio de emails para o endereço de email anterior.
- O cabeçalho não foi mostrado na página Resumo do projeto. O cabeçalho foi mostrado por alguns milissegundos e depois desapareceu.
- Melhoria na sincronização de usuários do Active Directory.
- Resolução da vulnerabilidade do Elasticsearch pela remoção da classe jndilookup dos binários do Log4j.
Etapas de instalação
- 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 presente, 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 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.
- 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 presente, 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 em
C:\Program Files\{TFS Version Folder}\Search\zip
, para a pasta de arquivos remotos do Elasticsearch. - Execute
Configure-TFSSearch.ps1 -Operation update
no computador do servidor do Elasticsearch.
Hash SHA-256: 451F0BB73132EFCD2B3D2922F0040DBF2BCF2808C35D3C37CA5A3CD8F65F29D6
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 3: 15 de dezembro de 2021
O Patch 3 para Azure DevOps Server 2020.1.1 inclui correções para o seguinte.
- Corrija a macro do item de trabalho para consultas com "Contém Palavras". Anteriormente, as consultas retornavam resultados incorretos para valores que continham uma quebra de linha.
- Aumente os limites para o comprimento de caracteres da versão do pacote Maven.
- Problema de localização nos estados de layout de itens de trabalho personalizados.
- Problema de localização no modelo de notificação por e-mail.
- Problema com a avaliação de regras NOTSAMEAS quando várias regras NOTSAMEAS foram definidas para um campo.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 2: 26 de outubro de 2021
O Patch 2 para Azure DevOps Server 2020.1.1 inclui correções para o seguinte.
- Anteriormente, Azure DevOps Server só podia criar conexões com GitHub Enterprise Server. Com esse patch, os administradores de projeto podem criar conexões entre Azure DevOps Server e repositórios no GitHub.com. Você pode encontrar essa configuração na página de conexões do GitHub em Configurações do Projeto.
- Resolva o problema com o widget Plano de teste. O relatório de execução de teste estava mostrando um usuário incorreto nos resultados.
- Correção de um problema com a falha de carregamento da página de resumo da Visão Geral do Projeto.
- Correção de um problema com e-mails que não eram enviados para confirmar a atualização do produto.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 1: 14 de setembro de 2021
O Patch 1 para Azure DevOps Server 2020.1.1 inclui correções para o seguinte.
- Corrija a falha de download/upload de artefatos.
- Resolva o problema com dados inconsistentes dos Resultados dos Testes.
Azure DevOps Server 2020 Atualização 1.1 Data de lançamento: 17 de agosto de 2021
Azure DevOps Server 2020 Update 1.1 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.1 ou atualizar de Azure DevOps Server 2020 ou Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server Atualização 1.1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Essa versão inclui correções para os seguintes bugs:
Azure Boards
- O hiperlink "Exibir item de trabalho" nos emails de notificação não está usando a URL pública.
Azure Repos
- Corrigida a exibição das caixas de seleção de herança de tipos de mesclagem limitados para permitir a modificação dos tipos de mesclagem limitados após a definição de políticas de repositório cruzado.
Azure Pipelines
- Ao alterar a configuração da Atualização do Agente, as configurações não estavam sendo propagadas para outras camadas de aplicativo no ambiente.
Geral
- Corrigida a ortografia no assistente de configuração do servidor.
- Aumento do tamanho do pacote de extensão e permite que você altere o tamanho no registro.
Azure Test Plans
- Não é possível navegar de volta para os resultados do teste depois de voltar do histórico para a página de resumo.
Azure DevOps Server 2020.1 Data de lançamento do Patch 2: 10 de agosto de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
- Corrija o erro na interface de usuário da definição de build.
- Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.
Azure DevOps Server 2020.1 Data de lançamento do Patch 1: 15 de junho de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
Cookies seguros usados em fluxos de autorização que declaram
SameSite=None
.Resolva o problema com o SDK do Notifications. Anteriormente, as assinaturas de notificações que usavam o filtro Caminho da Área não estavam sendo analisadas corretamente.
Azure DevOps Server 2020.1 RTW Data de lançamento: 25 de maio de 2021
Resumo das novidades no Azure DevOps Server 2020.1 RTW
Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2020.1 RC2 lançado anteriormente. Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020.1 ou atualizar de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server Atualização 1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Azure DevOps Server 2020.1 RC2 Data de lançamento: 13 de abril de 2021
Resumo das novidades em Azure DevOps Server 2020.1 RC2
Azure DevOps Server 2020.1 RC2 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2020.1 RC1 lançado anteriormente.
Azure DevOps Server 2020.1 RC1 Data de lançamento: 23 de março de 2021
Resumo das novidades em Azure DevOps Server 2020.1 RC1
Azure DevOps Server 2020.1 RC1 apresenta muitos novos recursos. Alguns dos destaques incluem:
- Regras de restrição de transição estadual nos Conselhos
- Os participantes agora podem mover itens de trabalho entre colunas do quadro
- Aprimorar a segurança do lançamento por meio da restrição do escopo dos tokens de acesso
- Experiência aprimorada de solicitação de pull
- Gatilhos em múltiplos repositórios em Pipelines
Você também pode pular para seções individuais para ver todos os novos recursos de cada serviço:
Quadros
Regras de restrição de transição de estado
Continuamos a fechar a lacuna de paridade de recursos entre o XML hospedado e o modelo de processo herdado. Essa nova regra de tipo de item de trabalho permite que você restrinja que os itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode impedir que os bugs passem de Novo para Resolvido. Em vez disso, eles devem ir de Novo -> Ativo -> Resolvido
Você também pode criar uma regra para restringir as transições de estado por associação de grupo. Por exemplo, somente os usuários do grupo "Aprovadores" podem mover histórias de usuário de Novo -> Aprovado.
Copiar item de trabalho para copiar filhos
Um dos principais recursos solicitados para Azure Boards é a capacidade de copiar um item de trabalho que também copia os itens de trabalho filho. Adicionamos uma nova opção para "Incluir itens de trabalho filho" na caixa de diálogo de cópia de item de trabalho. Quando selecionada, essa opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).
Regras aprimoradas para campos ativados e resolvidos
Até agora, as regras para Ativado por, Data de Ativação, Resolvido por e Data de Resolução têm sido um mistério. Eles são definidos apenas para tipos de item de trabalho do sistema e são específicos para o valor de estado de "Ativo" e "Resolvido". Mudamos a lógica para que essas regras não sejam mais para um estado específico. Em vez disso, eles são acionados pela categoria (categoria de estado) em que o estado reside. Por exemplo, digamos que você tenha um estado personalizado de "Precisa de teste" na categoria Resolvido. Quando o item de trabalho muda de "Ativo" para "Precisa de Testes", as regras Resolvido por e a Data Resolvida são disparadas.
Isso permite que os clientes criem valores de estado personalizados e ainda gerem os campos Ativado por, Data de Ativação, Resolvido por e Data de Resolução, sem a necessidade de usar regras personalizadas.
Os participantes podem mover itens de trabalho entre colunas de quadro
As partes interessadas sempre foram capazes de alterar o estado dos itens de trabalho. Mas quando eles vão para o quadro Kanban, eles não conseguem mover os itens de trabalho de uma coluna para outra. Em vez disso, as partes interessadas teriam que abrir cada item de trabalho, um de cada vez, e atualizar o valor do estado. Esse tem sido um ponto problemático para os clientes, e temos o prazer de anunciar que agora você pode mover itens de trabalho entre colunas do quadro.
Tipos de item de trabalho do sistema em listas de pendências e painéis
Agora você pode adicionar um tipo de item de trabalho do sistema ao nível de lista de pendências de sua escolha. Historicamente, esses tipos de itens de trabalho estavam disponíveis apenas por meio de consultas.
Processo | Tipo de Item de Trabalho |
---|---|
Ágil | Problema |
Scrum | Impedimento |
CMMI | Alterar pedido |
Problema | |
Revisão | |
Risco |
Adicionar um tipo de item de trabalho do sistema a um nível de lista de pendências é simples. Basta entrar em seu processo personalizado e clicar na guia Níveis de Backlog. Selecione o nível de backlog de sua escolha (exemplo: Lista de Pendências de Requisitos) e escolha a opção de editar. Em seguida, adicione o tipo de item de trabalho.

Limite de repositório para o aplicativo do GitHub para Azure Boards aumentado
O limite de repositório para o aplicativo Azure Boards no GitHub Marketplace foi aumentado de 100 para 250.
Personalizar o estado do item de trabalho quando a solicitação de pull for mesclada
Nem todos os fluxos de trabalho são iguais. Alguns clientes desejam fechar seus itens de trabalho relacionados quando uma solicitação de pull é concluída. Outros desejam definir os itens de trabalho para outro estado a serem validados antes do fechamento. Devemos permitir ambos.
Temos um novo recurso que permite definir os itens de trabalho para o estado desejado quando a solicitação de pull é mesclada e concluída. Para fazer isso, examinamos a descrição da solicitação de pull e procuramos o valor do estado seguido pela #menção dos itens de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvidas e fechando duas tarefas.

Vincule seu item de trabalho aos builds em outro projeto
Agora você pode acompanhar facilmente suas dependências de compilação no projeto apenas vinculando seu item de trabalho a uma compilação, encontrada na compilação ou integrada na compilação.
Como editar uma descrição (texto de ajuda) em campos do sistema
Você sempre foi capaz de editar a descrição dos campos personalizados. Mas para campos do sistema como prioridade, gravidade e atividade, a descrição não era editável. Essa era uma lacuna de recursos entre o XML hospedado e o herdado que impedia que alguns clientes migrassem para o modelo herdado. Agora você pode editar a descrição nos campos do sistema. O valor editado afetará apenas esse campo no processo e para esse tipo de item de trabalho. Isso lhe dá a flexibilidade de ter descrições diferentes para o mesmo campo em diferentes tipos de item de trabalho.
Personalizar o estado do item de trabalho quando a solicitação de pull for mesclada
As solicitações de pull geralmente se referem a vários itens de trabalho. Ao criar ou atualizar uma solicitação de pull, talvez você queira fechar algumas delas, resolver algumas delas e manter o restante aberto. Agora você pode usar comentários como os mostrados na figura abaixo para fazer isso. Consulte a documentação para obter mais detalhes.

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

Removendo a regra "Atribuído a" no tipo de item de trabalho Bug
Há várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho no Agile, Scrum e CMMI. Essas regras existem há mais de uma década e geralmente funcionam bem sem reclamações. No entanto, existem algumas regras que já não são bem-vindas. Uma regra em particular causou muita dor para clientes novos e existentes e decidimos que era hora de removê-la. Essa regra existe no tipo de item de trabalho Bug no processo Agile.
"Defina o valor Atribuído como Criado por quando o estado for alterado para Resolvido"
Recebemos muitos de seus comentários sobre essa regra. Em resposta, fomos em frente e removemos essa regra do tipo de item de trabalho Bug no processo Agile. Essa alteração afetará todos os projetos que usam um processo Agile herdado ou um processo Agile herdado personalizado. Para os clientes que gostam e dependem dessa regra atual, consulte nossa postagem do blog sobre as etapas que você pode seguir para adicionar novamente a regra usando regras personalizadas.
Itens removidos na página Itens de trabalho
A página Itens de Trabalho é um ótimo lugar para localizar rapidamente itens que você criou ou que estão atribuídos a você, entre outras coisas. Ele fornece vários pivôs e filtros personalizados. Uma das principais reclamações para a aba "Atribuído a mim" é que ela exibe itens de trabalho removidos (ou seja, itens de trabalho no estado de 'Removido'). E nós concordamos! Os itens removidos são trabalhos que não têm mais valor e, portanto, foram removidos da lista de pendências, portanto, incluí-los nessa exibição não é útil.
Agora você pode ocultar todos os itens removidos do pivô Atribuído a mim na página Itens de Trabalho.
Repos
Preferência para nome padrão do branch
Azure Repos agora oferece um nome de branch padrão personalizável para o Git. Nas configurações do repositório, você pode escolher qualquer nome de ramificação legal a ser usado quando um repositório for inicializado. Azure Repos sempre deu suporte à alteração do nome do branch padrão para um repositório existente.
Para obter mais informações, consulte Gerenciar ramos e Alterar o ramo padrão.
Configuração de nível da organização para ramificação padrão
Agora há uma configuração de nível de coleção para definir o nome inicial preferido do branch para novos repositórios. Se um projeto não tiver escolhido um nome de ramificação inicial, essa configuração no nível da organização será usada. Se você não especificou o nome do branch inicial nas configurações da organização ou nas configurações do projeto, os novos repositórios usarão um padrão definido pelo Azure DevOps.

Adicionar um novo escopo de autenticação para comentários de contribuição em PR
Esta versão adiciona um novo escopo OAuth para ler/escrever comentários de pull request. Se você tiver um bot ou automação que só precisa interagir com comentários, poderá dar a ele um PAT apenas com esse escopo. Esse processo reduz o raio de explosão se a automação tiver um bug ou se o token for comprometido.
Melhorias na experiência de Pull Request
A nova experiência de solicitação de pull foi aprimorada com o seguinte:
- Tornar as verificações opcionais mais visíveis
Os clientes usam verificações opcionais para chamar a atenção de um desenvolvedor para possíveis problemas. Na experiência anterior, costumava ser óbvio quando essas verificações falhavam. No entanto, esse não é o caso na experiência de pré-visualização. Um grande tique verde nas checagens necessárias mascara as falhas nas checagens opcionais. Os usuários só podiam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores não costumam fazer isso quando não há indicação de um problema. Nessa implantação, tornamos o status das verificações opcionais mais visível no resumo.
- Ctrl-clique em itens de menu
Os menus de abas em uma PR não davam suporte a Ctrl+clique. Os usuários geralmente abrem novas guias do navegador enquanto analisam um pull request. Esse problema foi corrigido.
- Localização da anotação [+]
A lista em árvore de arquivos em uma PR mostra uma anotação [+] para ajudar autores e revisores a identificar novos arquivos. Como a anotação estava após as reticências, muitas vezes não era visível para nomes de arquivos mais longos.
- Atualizações do menu suspenso do PR recuperam informações temporais
A lista suspensa para selecionar, atualizar e comparar arquivos em uma PR perdeu um elemento importante na experiência de visualização. Não apareceu quando essa atualização foi feita. Esse problema foi corrigido.
- **Layout de filtro de comentários aprimorado**
Ao filtrar comentários na página de resumo de uma solicitação de pull, a lista suspensa estava à direita, mas o texto estava alinhado à esquerda. Esse problema foi corrigido.
- Navegação para commits ancestrais
Na página Commits, você pode comparar as alterações feitas em um commit específico com seu commit pai. No entanto, talvez você queira navegar até o commit pai e entender como esse commit difere de seu próprio pai. Isso geralmente é necessário quando você deseja entender todas as alterações em uma versão. Adicionamos um cartão de pai a um commit para ajudá-lo a conseguir isso.
- Mais espaço para pastas e arquivos com nomes longos na guia de arquivos de PR
Pastas e arquivos com nomes longos foram cortados devido à falta de espaçamento horizontal na árvore de arquivos. Recuperamos algum espaço adicional na árvore modificando o recuo da árvore para corresponder ao nó raiz e ocultando o botão de reticências da página, exceto ao passar o mouse.
Imagem da nova árvore de arquivos:
Imagem da árvore de arquivos ao passar o mouse sobre um diretório:
- Preservar a posição de rolagem ao redimensionar o painel de comparação na guia de arquivos de PR
Ao redimensionar o painel de diferenças lado a lado na aba Arquivos do PR, a posição de rolagem do usuário seria perdida. Esse problema foi corrigido; a posição de rolagem do usuário agora é mantida durante o redimensionamento do painel de comparação.
- Pesquisar um commit em um dispositivo móvel
Ao exibir a página Confirmações em um dispositivo móvel, a caixa de pesquisa está ausente na nova experiência. Como resultado, é difícil para você encontrar um commit pelo seu hash e abri-lo. Isso foi corrigido agora.
- Uso aprimorado do espaço para a visualização móvel das diferenças de arquivo de PR
Atualizamos esta página para fazer melhor uso do espaço para que os usuários possam ver mais do arquivo em exibições móveis em vez de ter 40% da tela ocupada por um cabeçalho.
- Imagens aprimoradas na exibição de resumo de PR
As imagens editadas em um PR não estavam sendo exibidas na visualização de resumo do PR, mas eram exibidas corretamente na visualização de arquivos do PR. Esse problema foi resolvido.
- Experiência de branch aprimorada ao criar um PR
Antes dessa atualização, essa experiência não era ideal, pois comparava as alterações com a ramificação padrão do repositório em vez da ramificação de comparação.
Tubulações
Plataforma de agente adicional: ARM64
Adicionamos Linux/ARM64 à lista de plataformas com suporte para o agente do Azure Pipelines. Embora as mudanças de código tenham sido mínimas, muito trabalho nos bastidores teve que ser concluído primeiro, e estamos entusiasmados em anunciar seu lançamento!
Suporte ao filtro de tags para recursos de pipeline
Agora adicionamos 'tags' em pipelines YAML. Você pode usar tags para definir o pipeline de CI para ser executado ou quando disparar automaticamente.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags: ### This filter is used for resolving default version
- Production ### Tags are AND'ed
trigger:
tags: ### This filter is used for triggering the pipeline run
- Production ### Tags are AND'ed
- Signed
O trecho acima mostra que as tags podem ser usadas para determinar a versão padrão do pipeline de CI (integração contínua) executada quando a execução do pipeline de CD (implantação contínua) não é iniciada por alguma outra origem/recurso ou um gatilho de execução agendado.
Por exemplo, se você tiver um gatilho agendado definido para o pipeline de CD que só deseja executar se o IC tiver a tag de produção, as tags na seção de gatilhos garantem que o pipeline de CD só seja acionado se a condição de marcação for satisfeita no evento de conclusão do IC.
Controlar quais tarefas são permitidas nos pipelines
Agora você pode desabilitar as tarefas do Marketplace. Alguns de vocês podem permitir extensões do Marketplace, mas não as tarefas do Pipelines que vêm junto. Para ainda mais controle, também permitimos que você desative todas as tarefas integradas de forma independente (exceto o checkout, que é uma ação especial). Com essas duas configurações habilitadas, as únicas tarefas permitidas para serem executadas em um pipeline seriam aquelas carregadas usando tfx. Visite https://dev.azure.com/<your_org>/_settings/pipelinessettings
e procure a seção chamada "Restrições de tarefas" para começar.
Política de bloqueio exclusivo de implantação
Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente por vez. Ao marcar a opção "Bloqueio exclusivo" no ambiente, apenas uma execução continuará. As execuções subsequentes que desejam implantar nesse ambiente serão pausadas. Assim que a execução com o bloqueio exclusivo for concluída, a próxima execução será iniciada. Quaisquer processos intermediários serão cancelados.
Filtros de estágios para gatilhos de recursos de pipeline
Adicionamos suporte para 'estágios' como um filtro para recursos de pipeline no YAML. Com esse filtro, você não precisa esperar que todo o pipeline de CI seja concluído para acionar o pipeline de CD. Agora você pode escolher acionar seu pipeline de CD após a conclusão de um estágio específico em seu pipeline de CI.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Production
Quando os estágios fornecidos no filtro de gatilho são concluídos com êxito no pipeline de CI, uma nova execução é disparada automaticamente para o pipeline de CD.
Gatilhos genéricos baseados em webhook para pipelines YAML
Hoje, temos vários recursos (como pipelines, contêineres, compilações e pacotes) através dos quais você pode consumir artefatos e habilitar gatilhos automatizados. Até agora, no entanto, você não podia automatizar seu processo de implantação com base em outros eventos ou serviços externos. Nesta versão, estamos introduzindo o suporte para gatilhos de webhook em pipelines YAML para permitir a integração da automação de pipelines com qualquer serviço externo. Você pode se inscrever em qualquer evento externo por meio de seus webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) e acionar seus pipelines.
Aqui estão as etapas para configurar os gatilhos de webhook:
Configure um webhook em seu serviço externo. Ao criar seu webhook, você precisa fornecer as seguintes informações:
- URL da solicitação - "ADO collectionhttps://dev.azure.com/</_apis/public/distributedtask/webhooks/>WebHook Name<?api-version=6.0-preview">
- Segredo - Isso é opcional. Se você precisar proteger sua carga JSON, forneça o valor Secret
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
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}}
- Sempre que um evento de webhook for recebido pela conexão de serviço de Webhook de entrada, uma nova execução será disparada para todos os pipelines inscritos no evento de webhook.
Suporte e rastreabilidade para problemas de acionamento de recursos YAML
Pode ser confuso quando os gatilhos de pipeline não funcionam como você esperava. Para ajudar a entender melhor isso, adicionamos um novo item de menu na página de definição de pipeline chamado "Problemas de gatilho", onde são exibidas informações sobre por que os gatilhos não estão sendo executados.
Os gatilhos de recursos podem falhar ao serem executados por dois motivos.
Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado. Estes aparecem como erros.
Se as condições do gatilho não forem correspondidas, o gatilho não será executado. Sempre que isso ocorrer, um aviso será exibido para que você possa entender por que as condições não foram correspondidas.
Gatilhos de múltiplos repositórios
Você pode especificar vários repositórios em um arquivo YAML e fazer com que um pipeline seja disparado por atualizações em qualquer um dos repositórios. Esse recurso é útil, por exemplo, nos seguintes cenários:
- Você consome uma ferramenta ou uma biblioteca de um repositório diferente. Você deseja executar testes para seu aplicativo sempre que a ferramenta ou biblioteca for atualizada.
- Você mantém o arquivo YAML em um repositório separado do código do aplicativo. Você deseja disparar o pipeline sempre que uma atualização é enviada por push para o repositório de aplicativos.
Com essa atualização, os gatilhos de múltiplos repositórios só funcionarão para repositórios Git no Azure Repos. Eles não funcionam para recursos de repositório GitHub ou BitBucket.
Aqui está um exemplo que mostra como definir vários recursos de repositório em um pipeline e como configurar gatilhos em todos eles.
trigger:
- main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
O pipeline neste exemplo será acionado se houver atualizações em relação a:
-
main
branch no repositórioself
que contém o arquivo YAML -
main
ourelease
ramificações emtools
repositório
Para obter mais informações, consulte Vários repositórios no seu pipeline.
Aprimoramento dos carregamentos de log do agente
Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que ele estava executando é abandonado. Se você estivesse olhando os logs do console de streaming, talvez tenha obtido algumas pistas sobre o que o agente estava fazendo antes de parar de responder. Mas se você não estivesse, ou se atualizasse a página, esses logs do console desapareceriam. Com esta versão, se o agente parar de responder antes de enviar seus logs completos, manteremos os logs do console como a próxima melhor coisa. Os logs do console são limitados a 1000 caracteres por linha e podem ocasionalmente estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a resolver problemas em seus próprios pipelines e certamente ajudará nossos engenheiros de suporte quando eles ajudarem na solução de problemas.
Opcionalmente, montar volumes de contêiner em modo somente leitura.
Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o workspace, as tarefas e outros materiais são mapeados como volumes. Esses volumes têm como padrão acesso de leitura/gravação. Para aumentar a segurança, você pode montar os volumes somente para leitura alterando a especificação do contêiner no YAML. Cada chave abaixo mountReadOnly
pode ser definida como true
somente leitura (o padrão é false
).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
Controle refinado sobre o início/a parada do contêiner
Em geral, recomendamos que você permita que o Azure Pipelines gerencie o ciclo de vida de seus contêineres de trabalho e serviço. No entanto, em alguns cenários incomuns, você pode querer iniciá-los e interrompê-los sozinho. Com esta versão, incorporamos esse recurso à tarefa do Docker.
Aqui está um pipeline de exemplo usando o novo recurso:
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
Além disso, incluímos a lista de contêineres em uma variável de pipeline, Agent.ContainerMapping
. Você pode usar isso se quiser inspecionar a lista de contêineres em um script, por exemplo. Ele contém um objeto JSON em cadeia de caracteres que mapeia o nome do recurso ("builder" do exemplo acima) para a ID do contêiner que o agente gerencia.
Descompactar pacotes de tarefas para cada etapa
Quando o agente executa um trabalho, ele primeiro baixa todos os pacotes de tarefas exigidos pelas etapas do trabalho. Normalmente, para melhorar o desempenho, ele descompacta as tarefas uma vez por trabalho, mesmo que a tarefa seja usada em várias etapas. Se você tiver preocupações sobre o código não confiável que possa alterar o conteúdo descompactado, poderá sacrificar um pouco de performance solicitando que o agente descompacte a tarefa a cada uso. Para habilitar esse modo, passe --alwaysextracttask
ao configurar o agente.
Melhorar a segurança do lançamento restringindo o escopo dos tokens de acesso
Com base em nossa iniciativa de aprimorar as configurações de segurança do Azure Pipelines, agora damos suporte à restrição do escopo de tokens de acesso para releases.
Cada trabalho que é executado em liberações obtém um token de acesso. O token de acesso é usado para suas tarefas e por seus scripts para se conectar novamente ao Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, baixar artefatos, carregar logs, resultados de teste ou fazer chamadas REST para o Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.
Com esta atualização, trabalhamos para aprimorar a segurança do pipeline restringindo o escopo dos tokens de acesso e estendendo essa melhoria para versões clássicas.
Esse recurso estará ativado por padrão para novos projetos e coleções. Para coleções existentes, você deve habilitá-lo em Configurações de coleção Configurações > Pipelines >. > Limite o escopo de autorização do trabalho ao projeto atual para pipelines de lançamento. Saiba mais aqui.
Aprimoramentos da API de versão prévia do YAML
Agora você pode visualizar o YAML completo de um pipeline sem executá-lo. Além disso, criamos uma nova URL dedicada para o recurso de visualização. Agora você pode POST em https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview
para recuperar o corpo YAML finalizado. Essa nova API usa os mesmos parâmetros que o enfileiramento de uma execução, mas não requer mais a permissão "Builds de fila".
Execute este trabalho em seguida
Você já teve uma correção de bug que precisava implantar neste minuto , mas teve que esperar por trabalhos de CI e RP? Com esta atualização, agora permitimos que você priorize a execução de uma tarefa que está na fila. Os usuários com a permissão "Gerenciar" no pool — normalmente administradores de pool — verão um novo botão "Executar em seguida" na página de detalhes da tarefa. Clicar no botão definirá o trabalho a ser executado o mais rápido possível. (Você ainda precisará de paralelismo disponível e um agente adequado, é claro.)
Expressões de modelo permitidas no bloco YAML resources
Anteriormente, expressões de tempo de compilação () não eram permitidas na seção resources
de um arquivo YAML do Azure Pipelines. Com esta versão, suspendemos essa restrição para contêineres. Isso permite que você use o parâmetro de tempo de execução nos seus recursos, por exemplo, para escolher um contêiner no momento da fila. Planejamos estender esse suporte a outros recursos ao longo do tempo.
Controle sobre atualizações de tarefas automatizadas do Marketplace
Quando você escreve um pipeline YAML, normalmente especifica apenas o número de versão principal das tarefas incluídas. Isso permite que seus pipelines absorvam automaticamente as adições mais recentes de recursos e das correções de bugs. Ocasionalmente, pode ser necessário reverter para uma versão pontual anterior de uma tarefa, e com esta atualização, adicionamos a possibilidade de fazê-lo. Agora você pode especificar uma versão completa da tarefa major.minor.patch em seus pipelines YAML.
Não recomendamos que você faça isso regularmente e sugere-se usá-lo apenas como uma solução temporária quando descobrir que uma tarefa mais recente interrompe seus pipelines. Além disso, isso não instalará uma versão mais antiga de uma tarefa do Marketplace. Ele já deve existir em sua coleção ou seu pipeline falhará.
Exemplo:
steps:
- task: MyTask@1 # a normal, major-version only reference
- task: MyOtherTask@2.3.4 # pinned to a precise version
Suporte à versão 10 do Node no agente e nas tarefas
Como o Nó 6 não é mais suportado, estamos migrando as tarefas para trabalhar com o Nó 10. Para esta atualização, migramos quase 50% das tarefas da caixa de entrada para o Node 10. O agente agora pode executar tarefas tanto no Node.js 6 quanto no Node.js 10. Em uma atualização futura, removeremos totalmente o Nó 6 do agente. Para se preparar para a remoção do Node 6 do agente, solicitamos que você atualize suas extensões internas e tarefas personalizadas para que também comecem a usar o Node 10 em breve. Para usar o Node 10 para sua tarefa, em task.json
, dentro de execution
, atualize de Node
para Node10
.
Aprimorar a conversão de YAML no designer de build clássico
Com esta versão, introduzimos um novo recurso de "exportação para YAML" para pipelines de build do designer. Salve a definição do pipeline e encontre "Exportar para YAML" no ...
menu.
A nova função de exportação substitui a função "Exibir como YAML" encontrada anteriormente no designer de build clássico. Essa função estava incompleta, pois só podia inspecionar o que a interface do usuário da Web sabia sobre a compilação, o que às vezes levava à geração de YAML incorreto. A nova função de exportação leva em conta exatamente como o pipeline será processado e gera YAML com total fidelidade ao pipeline do designer.
Nova conversão de plataforma web – Configurações do repositório
Convertemos as duas páginas de configurações do repositório em uma única experiência que foi atualizada para uma nova plataforma Web. Essa atualização não apenas torna a experiência mais rápida e moderna, mas essas páginas também fornecem um único ponto de entrada para todas as políticas, desde o nível do projeto até o nível da ramificação.
Com essa nova experiência, a navegação para projetos com um número substancial de repositórios tornou-se mais fácil devido aos tempos de carregamento mais rápidos e a um filtro de pesquisa adicionado. Você também pode exibir políticas de nível de projeto e a lista de políticas entre repositórios na guia Políticas.
Se você clicar em um repositório, poderá visualizar políticas e permissões definidas no nível do repositório. Na aba de políticas, você pode visualizar uma lista de cada branch em que a política está definida. Agora, clique no branch para ver as políticas sem nunca sair da página de configurações do repositório.
Agora, quando as políticas são herdadas de um escopo superior ao que você está utilizando, mostramos ao lado de cada política individual de onde ela foi herdada. Você também pode navegar até a página em que a política de nível superior foi definida clicando no nome do escopo.
A própria página de política também foi atualizada para a nova plataforma web com seções recolhíveis! Para melhorar a experiência de procurar uma política específica de Validação de Build, Verificação de Status ou Revisor Automático, adicionamos filtros de pesquisa para cada seção.
Integração do gerenciamento de alterações do ServiceNow com pipelines do YAML
O aplicativo Azure Pipelines para ServiceNow ajuda você a integrar o Azure Pipelines e o Gerenciamento de Alterações do ServiceNow. Com essa atualização, levamos nossa jornada de tornar o Azure Pipelines ciente do processo de gerenciamento de alterações gerenciado no ServiceNow além dos pipelines YAML.
Ao configurar a verificação "Gerenciamento de Alterações do ServiceNow" em um recurso, agora você pode pausar para que a alteração seja aprovada antes de implantar a compilação nesse recurso. Você pode criar automaticamente uma nova alteração para um estágio ou aguardar uma solicitação de alteração existente.
Você também pode adicionar a tarefa UpdateServiceNowChangeRequest
em um trabalho de servidor para atualizar a solicitação de alteração com o status da implantação, notas etc.
Artefatos
Capacidade de criar feeds com escopo organizacional a partir da interface do usuário
Estamos trazendo de volta a capacidade dos clientes de criar e gerenciar feeds com escopo de coleção por meio da interface do usuário da Web para serviços locais e hospedados.
Agora você pode criar feeds no escopo da organização por meio da interface do usuário, indo para Artefatos -> Criar Feed e escolhendo um tipo de feed no Escopo.
Embora recomendemos o uso de feeds no escopo do projeto em alinhamento com o restante das ofertas do Azure DevOps, você novamente pode criar, gerenciar e usar feeds no escopo da coleção por meio da interface e de várias APIs REST. Consulte nossa documentação de feeds para obter mais informações.
A API REST de atualização da versão do pacote já está disponível para pacotes do Maven
Agora você pode usar a API REST "Atualizar Versão do Pacote" do Azure Artifacts para atualizar as versões do pacote Maven. Anteriormente, você podia usar a API REST para atualizar versões de pacote para NuGet, Maven, npm e Pacotes Universais, mas não pacotes Maven.
Para atualizar pacotes Maven, use o comando HTTP PATCH da seguinte maneira.
PATCH
https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
Você pode definir o seguinte:
Parâmetros de URI
Nome | In | Obrigatório | Tipo | Descrição |
---|---|---|---|---|
artifactId | caminho | VERDADEIRO | string | ID do artefato do pacote |
feed de notícias | caminho | VERDADEIRO | string | Nome ou ID do feed |
ID do grupo | caminho | VERDADEIRO | string | ID do grupo do pacote |
coleção | caminho | VERDADEIRO | string | O nome da coleção do Azure DevOps |
versão | caminho | VERDADEIRO | string | Versão do pacote |
projeto | caminho | string | ID do projeto ou nome do projeto | |
versão da API | Consulta | VERDADEIRO | string | Versão da API a ser usada. Isso deve ser definido como '5.1-preview.1' para usar esta versão da API |
Corpo da solicitação
Nome | Tipo | Descrição |
---|---|---|
visualizações | JsonPatchOperation | A visualização à qual a versão do pacote será adicionada |
Para obter mais informações, consulte a documentação da API REST à medida que ela é atualizada.
Comentários
Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la por meio da Comunidade de Desenvolvedores e obter conselhos sobre o Stack Overflow.