Azure DevOpsServer 2020 Atualização 1 Notas de versão
Requisitos | do sistema da comunidade | de desenvolvedores Termos | de licença DevOps Blog | Hashes SHA-1
Neste artigo, você encontrará informações sobre a versão mais recente do Azure DevOps Server.
Para saber mais sobre como instalar ou atualizar uma implantação Azure DevOps Server, consulte Azure DevOps Server Requisitos. Para baixar produtos do Azure DevOps, visite a página Downloads do Azure DevOps Server.
A atualização direta para Azure DevOps Server 2020 tem suporte de Azure DevOps Server 2019 ou Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps local.
Atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020
Azure DevOps Server 2020 apresenta um novo modelo de retenção de execução (build) de pipeline que funciona com base nas configurações no nível do projeto.
Azure DevOps Server 2020 lida com a retenção de build de forma diferente, com base nas políticas de retenção no nível do pipeline. Determinadas configurações de política levam à exclusão de execuções de pipeline após a atualização. As execuções de pipeline que foram retidas manualmente ou são retidas por uma versão não serão excluídas após a atualização.
Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 13: 12 de março de 2024
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch13.exe | 55B0A30EABD66EB22AA6093B7750EF3CFEFE79423018E304503CE728158F56F6 |
Lançamos o Patch 13 para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte:
- Resolvido um problema em que o servidor proxy parava de funcionar após a instalação do patch 12.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 12: 13 de fevereiro de 2024
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch12.exe | C4C9EEBBDD3B07C36658C9F78AEA57A980AA633F99DF2A3AD5036F957F095E53 |
Lançamos o Patch 12 para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte:
- Corrigido um bug em que o espaço em disco usado pela pasta de cache do proxy era calculado incorretamente e a pasta não era limpa corretamente.
- CVE-2024-20667: vulnerabilidade de execução remota de código do Azure DevOps Server.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 11: 12 de dezembro de 2023
Arquivo | Hash SHA-256 |
---|---|
devops2020.1.2patch11.exe | C47B9C898C2E08527F1DDC3E7A5E67F1A11C3AFF860DE9B5FF3DD8718C3AAE87 |
Lançamos o Patch 11 para Azure DevOps Server 2020 Atualização 1.2 que inclui correções para o seguinte:
- Corrigido um bug em que a herança de segurança de aprovação de pré-implantação não estava funcionando nos estágios de pipelines.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 10: 14 de novembro de 2023
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Estendida a lista de caracteres permitidos de tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas do shell.
Observação
Para implementar correções para este patch, você terá que seguir uma série de etapas para atualizar manualmente as tarefas.
Instalar patches
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 8 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 8, recomendamos que você instale essas atualizações antes de instalar o Patch 10. A nova versão do agente após a instalação do Patch 8 será 3.225.0.
Configurar o TFX
- Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.
Atualizar tarefas usando o TFX
Arquivo | Hash SHA-256 |
---|---|
Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- 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 Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Corrigido um bug em que a identidade "Proprietário da Análise" é exibida como Identidade Inativa em máquinas de atualização de patch.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 8: 12 de setembro de 2023
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- CVE-2023-33136: vulnerabilidade de execução de código remoto do Azure DevOps Server.
- CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.
Importante
Implante o patch em um ambiente de teste e verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.
Observação
Para implementar correções para este patch, você terá que seguir várias etapas para atualizar manualmente o agente e as tarefas.
Instalar patches
- 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 evitar o downgrade do agente. No Windows, o comando a seguir pode ser usado em um prompt de comando administrativo, seguido por uma reinicialização. setx AZP_AGENT_DOWNGRADE_DISABLED true /M
Configurar o TFX
- Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.
Atualizar tarefas usando o TFX
- 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
precisa ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia Variável do pipeline.
Exemplo de YAML:
variables:
- name: AZP_75787_ENABLE_NEW_LOGIC
value: true
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 7: 8 de agosto de 2023
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- CVE-2023-36869: vulnerabilidade de falsificação do Azure DevOps Server.
- Atualize o serviço SSH para dar suporte a SHA2-256 e SHA2-512. Se você tiver arquivos de configuração SSH codificados para usar RSA, atualize para SHA2 ou remova a entrada.
- Foi resolvido um problema em que as ligações relativas não funcionavam em ficheiros markdown.
- Corrigido um bug com a navegação de comentários em uma página de confirmação.
- Corrigido um bug em que a identidade do Proprietário da Análise era exibida como Identidade Inativa.
- Corrigido o bug de loop infinito em CronScheduleJobExtension.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 6: 13 de junho de 2023
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- CVE-2023-21565: vulnerabilidade de falsificação do Azure DevOps Server.
- CVE-2023-21569: vulnerabilidade de falsificação do Azure DevOps Server.
- Corrigido um bug que interferia no envio de pacotes ao atualizar de 2018 ou anterior.
- Corrigido um bug em que desanexar ou anexar coleção falha, relatando o seguinte erro: 'TF246018: a operação do banco de dados excedeu o limite de tempo limite e foi cancelada.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 5: 14 de fevereiro de 2023
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- CVE-2023-21553: vulnerabilidade de execução remota de código do Azure DevOps Server
- Corrigido o problema de acessibilidade dos check-ins particulares por meio da interface do usuário da Web
- Os clientes precisam reiniciar o serviço tfsjobagent e o pool de aplicativos Azure DevOps Server depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento Azure DevOps Server.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 4: 13 de dezembro de 2022
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Corrigida a exibição de caracteres especiais no IdentityPicker.
- Os dados de teste não estavam sendo excluídos, fazendo com que o banco de dados crescesse. Com essa correção, atualizamos a retenção de compilação para evitar a criação de novos dados de teste órfãos.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 3: 18 de outubro de 2022
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Resolva o problema com identidades do AD recém-adicionadas que não aparecem nos seletores de identidade da caixa de diálogo de segurança.
- Correção de um problema com o filtro Solicitado pelo membro do grupo nas configurações do web hook.
- Correção do erro de builds de check-in restrito quando as configurações da organização para o pipeline tinham o escopo de autorização de trabalho configurado como Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de não lançamento.
- Corrija a recuperação do token de acesso do Azure ao estabelecer a conexão de serviço por trás do proxy autenticado.
Azure DevOps Server 2020 Atualização 1.2 Patch 2 Data de lançamento: 9 de agosto de 2022
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Corrija o erro de valor de identidade ao atribuir um item de trabalho a uma identidade que aparece em domínios diferentes.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento do Patch 1: 12 de julho de 2022
Lançamos um patch para Azure DevOps Server Atualização 1.2 de 2020 que inclui correções para o seguinte.
- Nas APIs de Execuções de Teste, o token de continuação que está sendo retornado era maior que o valor "maxLastUpdatedDate" especificado.
Azure DevOps Server 2020 Atualização 1.2 Data de lançamento: 17 de maio de 2022
Azure DevOps Server Atualização 1.2 de 2020 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.2 ou atualizar de Azure DevOps Server 2020 ou Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server Atualização 1.2 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Esta versão inclui correções para o seguinte:
Azure DevOps Server 2020.1.2 desabilita o novo modelo de retenção (introduzido em Azure DevOps Server 2020), para evitar a perda de execuções de pipeline (builds). Isso significa que o sistema irá:
- Criar concessões para as 3 compilações mais recentes geradas durante a execução do Server 2020
- Para pipelines YAML e pipelines clássicos sem políticas de retenção por pipeline, os builds serão retidos de acordo com as configurações máximas de retenção no nível da coleção
- Para pipelines clássicos com políticas de retenção personalizadas por pipeline, os builds serão retidos de acordo com a política de retenção específica do pipeline
- As compilações com concessões não contam para o Mínimo para continuar definindo
Os links de comentários do conjunto de alterações e do check-in particular não estavam redirecionando corretamente. Quando os comentários eram adicionados a arquivos em conjuntos de alterações ou check-ins particulares, a seleção desses comentários não redirecionava para o local correto na exibição do arquivo.
Não é possível pular a fila de compilação usando o botão "Executar a seguir". Anteriormente, o botão "Executar a seguir" estava habilitado apenas para administradores de coleção de projetos.
Revogue todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário for desabilitada.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 4: 26 de janeiro de 2022
Lançamos um patch para Azure DevOps Server 2020.1.1 que inclui correções para o seguinte.
- As notificações por email não foram enviadas ao usar o @mention controle em um item de trabalho.
- O endereço de email preferencial não estava sendo atualizado no perfil do usuário. Isso resultava no envio de emails para o endereço de email anterior.
- O cabeçalho não foi mostrado na página Resumo do projeto. O cabeçalho foi mostrado por alguns milissegundos e depois desapareceu.
- Melhoria na sincronização de usuários do Active Directory.
- Resolução da vulnerabilidade do Elasticsearch pela remoção da classe jndilookup dos binários do Log4j.
Etapas de instalação
- 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 para estados de layout de itens de trabalho personalizados.
- Problema de localização no modelo de notificação por e-mail.
- Problema com a avaliação de regras NOTSAMEAS quando várias regras NOTSAMEAS foram definidas para um campo.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 2: 26 de outubro de 2021
O Patch 2 para Azure DevOps Server 2020.1.1 inclui correções para o seguinte.
- Anteriormente, Azure DevOps Server só podia criar conexões com GitHub Enterprise Server. Com esse patch, os administradores de projeto podem criar conexões entre Azure DevOps Server e repositórios no GitHub.com. Você pode encontrar essa configuração na página de conexões do GitHub em Configurações do Projeto.
- Resolva o problema com o widget Plano de teste. O relatório de execução de teste estava mostrando um usuário incorreto nos resultados.
- Correção de um problema com a falha de carregamento da página de resumo da Visão Geral do Projeto.
- Correção de um problema com e-mails que não eram enviados para confirmar a atualização do produto.
Azure DevOps Server 2020.1.1 Data de lançamento do Patch 1: 14 de setembro de 2021
O Patch 1 para Azure DevOps Server 2020.1.1 inclui correções para o seguinte.
- Corrija a falha de download/upload de artefatos.
- Resolva o problema com dados inconsistentes dos Resultados do Teste.
Azure DevOps Server 2020 Atualização 1.1 Data de lançamento: 17 de agosto de 2021
Azure DevOps Server Atualização 1.1 de 2020 é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020 Atualização 1.1 ou atualizar de Azure DevOps Server 2020 ou Team Foundation Server 2013 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server Atualização 1.1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Essa versão inclui correções para os seguintes bugs:
Azure Boards
- O hiperlink "Exibir item de trabalho" nos emails de notificação não está usando a URL pública.
Azure Repos
- Corrigidas as caixas de seleção de herança de tipos de mesclagem limitados exibidas para habilitar a modificação dos tipos de mesclagem de limite após a configuração de políticas de configuração cruzada.
Azure Pipelines
- Ao alterar a configuração da Atualização do Agente, as configurações não estavam sendo propagadas para outras camadas de aplicativo no ambiente.
Geral
- Corrigida a ortografia no assistente de configuração do servidor.
- Aumento do tamanho do pacote de extensão e permite que você altere o tamanho no registro.
Azure Test Plans
- Não é possível navegar de volta para os resultados do teste depois de voltar do histórico para a página de resumo.
Azure DevOps Server 2020.1 Data de lançamento do Patch 2: 10 de agosto de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
- Corrija o erro da interface do usuário de definição de compilação.
- Histórico de navegação alterado para exibir arquivos em vez do repositório raiz.
Azure DevOps Server 2020.1 Data de lançamento do Patch 1: 15 de junho de 2021
Lançamos um patch para Azure DevOps Server 2020.1 que corrige o seguinte.
Cookies seguros usados em fluxos de autorização que declaram
SameSite=None
.Resolva o problema com o SDK do Notifications. Anteriormente, as assinaturas de notificações que usavam o filtro Caminho da Área não estavam sendo analisadas corretamente.
Azure DevOps Server 2020.1 RTW Data de lançamento: 25 de maio de 2021
Resumo das novidades no Azure DevOps Server 2020.1 RTW
Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2020.1 RC2 lançado anteriormente. Azure DevOps Server 2020.1 RTW é um pacote cumulativo de correções de bugs. Você pode instalar diretamente Azure DevOps Server 2020.1 ou atualizar de Azure DevOps Server 2020, 2019 ou Team Foundation Server 2015 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server Atualização 1 de 2020 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Azure DevOps Server 2020.1 RC2 Data de lançamento: 13 de abril de 2021
Resumo das novidades em Azure DevOps Server 2020.1 RC2
Azure DevOps Server 2020.1 RC2 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2020.1 RC1 lançado anteriormente.
Azure DevOps Server 2020.1 RC1 Data de lançamento: 23 de março de 2021
Resumo das novidades em Azure DevOps Server 2020.1 RC1
Azure DevOps Server 2020.1 RC1 apresenta muitos novos recursos. Alguns dos destaques incluem:
- Regras de restrição de transição estadual nos Conselhos
- Os participantes agora podem mover itens de trabalho entre colunas de quadro
- Aprimorar a segurança da versão por meio da restrição do escopo dos tokens de acesso
- Experiência aprimorada de solicitação de pull
- Gatilhos de vários repositórios em pipelines
Você também pode pular para seções individuais para ver todos os novos recursos de cada serviço:
Boards
Regras de restrição de transição de estado
Continuamos a fechar a lacuna de paridade de recursos entre o XML hospedado e o modelo de processo herdado. Essa nova regra de tipo de item de trabalho permite que você restrinja que os itens de trabalho sejam movidos de um estado para outro. Por exemplo, você pode impedir que os bugs passem de Novo para Resolvido. Em vez disso, eles devem ir de Novo -> Ativo -> Resolvido
Você também pode criar uma regra para restringir as transições de estado por associação de grupo. Por exemplo, somente os usuários do grupo "Aprovadores" podem mover histórias de usuário de Novo -> Aprovado.
Copiar item de trabalho para copiar filhos
Um dos principais recursos solicitados para Azure Boards é a capacidade de copiar um item de trabalho que também copia os itens de trabalho filho. Adicionamos uma nova opção para "Incluir itens de trabalho filho" à caixa de diálogo copiar item de trabalho. Quando selecionada, essa opção copiará o item de trabalho e copiará todos os itens de trabalho filho (até 100).
Regras aprimoradas para campos ativados e resolvidos
Até agora, as regras para Ativado por, Data de Ativação, Resolvido por e Data de Resolução têm sido um mistério. Eles são definidos apenas para tipos de item de trabalho do sistema e são específicos para o valor de estado de "Ativo" e "Resolvido". Mudamos a lógica para que essas regras não sejam mais para um estado específico. Em vez disso, eles são acionados pela categoria (categoria de estado) em que o estado reside. Por exemplo, digamos que você tenha um estado personalizado de "Precisa de teste" na categoria Resolvido. Quando o item de trabalho muda de "Ativo" para "Precisa de Teste", as regras Resolvido por e Data Resolvida são disparadas.
Isso permite que os clientes criem valores de estado personalizados e ainda gerem os campos Ativado por, Data de Ativação, Resolvido por e Data de Resolução, sem a necessidade de usar regras personalizadas.
Os participantes podem mover itens de trabalho entre colunas de quadro
As partes interessadas sempre foram capazes de alterar o estado dos itens de trabalho. Mas quando eles vão para o quadro Kanban, eles não conseguem mover os itens de trabalho de uma coluna para outra. Em vez disso, os Stakeholders teriam que abrir cada item de trabalho, um de cada vez, e atualizar o valor do estado. Esse tem sido um ponto problemático para os clientes, e temos o prazer de anunciar que agora você pode mover itens de trabalho entre colunas do quadro.
Tipos de item de trabalho do sistema em listas de pendências e painéis
Agora você pode adicionar um tipo de item de trabalho do sistema ao nível de lista de pendências de sua escolha. Historicamente, esses tipos de item de trabalho só estavam disponíveis em consultas.
Processo | Tipo de Item de Trabalho |
---|---|
Agile | Problema |
Scrum | Impedimento |
CMMI | Alterar pedido |
Problema | |
Revisão | |
Risco |
Adicionar um tipo de item de trabalho do sistema a um nível de lista de pendências é simples. Basta entrar em seu processo personalizado e clicar na guia Níveis de backlog. Selecione o nível de lista de pendências de sua escolha (exemplo: Lista de Pendências de Requisitos) e escolha a opção de edição. Em seguida, adicione o tipo de item de trabalho.
Limite de repositório de aplicativo GitHub do Azure Boards gerado
O limite de repositório para o aplicativo Azure Boards no GitHub Marketplace foi aumentado de 100 para 250.
Personalizar o estado do item de trabalho quando a solicitação de pull for mesclada
Nem todos os fluxos de trabalho são iguais. Alguns clientes desejam fechar seus itens de trabalho relacionados quando uma solicitação de pull é concluída. Outros desejam definir os itens de trabalho para outro estado a serem validados antes do fechamento. Devemos permitir ambos.
Temos um novo recurso que permite definir os itens de trabalho para o estado desejado quando a solicitação de pull é mesclada e concluída. Para fazer isso, examinamos a descrição da solicitação de pull e procuramos o valor do estado seguido pelo #mention dos itens de trabalho. Neste exemplo, estamos definindo duas histórias de usuário como Resolvidas e fechando duas tarefas.
Vincular seu item de trabalho a 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 pai no painel de tarefas
Devido à solicitação popular, agora você pode adicionar o campo Pai aos cartões filho e pai no Quadro de Tarefas.
Removendo a regra "Atribuído a" no tipo de item de trabalho Bug
Há várias regras de sistema ocultas em todos os diferentes tipos de item de trabalho no Agile, Scrum e CMMI. Essas regras existem há mais de uma década e geralmente funcionam bem sem reclamações. No entanto, existem algumas regras que se esgotaram. Uma regra em particular causou muita dor para clientes novos e existentes e decidimos que era hora de removê-la. Essa regra existe no tipo de item de trabalho Bug no processo Agile.
"Defina o valor Atribuído como Criado por quando o estado for alterado para Resolvido"
Recebemos muitos de seus comentários sobre essa regra. Em resposta, fomos em frente e removemos essa regra do tipo de item de trabalho Bug no processo Agile. Essa alteração afetará todos os projetos que usam um processo Agile herdado ou um processo Agile herdado personalizado. Para os clientes que gostam e dependem dessa regra atual, consulte nossa postagem no blog sobre as etapas que você pode seguir para adicionar novamente a regra em Usando regras personalizadas.
Itens removidos na página Itens de trabalho
A página Itens de Trabalho é um ótimo lugar para localizar rapidamente itens que você criou ou que estão atribuídos a você, entre outras coisas. Ele fornece vários pivôs e filtros personalizados. Uma das principais reclamações para o pivô "Atribuído a mim" é que ele exibe itens de trabalho removidos (ou seja, itens de trabalho no estado Removido). E nós concordamos! Os itens removidos são trabalhos que não têm mais valor e, portanto, foram removidos da lista de pendências, portanto, incluí-los nessa exibição não é útil.
Agora você pode ocultar todos os itens removidos do pivô Atribuído a mim na página Itens de Trabalho.
Repos
Preferência de nome de branch padrão
Azure Repos agora oferece um nome de branch padrão personalizável para o Git. Nas configurações do repositório, você pode escolher qualquer nome de ramificação legal a ser usado quando um repositório for inicializado. Azure Repos sempre deu suporte à alteração do nome do branch padrão para um repositório existente.
Para obter mais informações, consulte Gerenciar branches e Alterar o branch padrão.
Configuração de nível da organização para ramificação padrão
Agora há uma configuração de nível de coleção para o nome de branch inicial preferido para novos repositórios. Se um projeto não tiver escolhido um nome de ramificação inicial, essa configuração no nível da organização será usada. Se você não especificou o nome do branch inicial nas configurações da organização ou nas configurações do projeto, os novos repositórios usarão um padrão definido pelo Azure DevOps.
Adicionar um novo escopo de autenticação para comentários de PR de contribuição
Esta versão adiciona um novo escopo OAuth para ler/gravar comentários de solicitação de pull. Se você tiver um bot ou automação que só precisa interagir com comentários, poderá dar a ele um PAT apenas com esse escopo. Esse processo reduz o raio de explosão se a automação tiver um bug ou se o token for comprometido.
Melhorias na experiência de solicitação de pull
A nova experiência de solicitação de pull foi aprimorada com o seguinte:
- Tornar as verificações opcionais mais visíveis
Os clientes usam verificações opcionais para chamar a atenção de um desenvolvedor para possíveis problemas. Na experiência anterior, costumava ser óbvio quando essas verificações falhavam. No entanto, esse não é o caso na experiência de visualização. Uma grande marca de seleção verde nas verificações necessárias mascara as falhas nas verificações opcionais. Os usuários só podiam descobrir que as verificações opcionais falharam abrindo o painel de verificações. Os desenvolvedores não costumam fazer isso quando não há indicação de um problema. Nessa implantação, tornamos o status das verificações opcionais mais visível no resumo.
- Ctrl-cliques em itens de menu
Os menus de guia em uma PR não davam suporte a Ctrl-clique. Os usuários geralmente abrem novas guias do navegador enquanto analisam uma solicitação de pull. Esse problema foi corrigido.
- Localização da anotação [+]
A lista em árvore de arquivos em uma PR mostra uma anotação [+] para ajudar autores e revisores a identificar novos arquivos. Como a anotação estava após as reticências, muitas vezes não era visível para nomes de arquivos mais longos.
- Atualizações de PR suspensas recuperam informações de tempo
A lista suspensa para selecionar, atualizar e comparar arquivos em uma PR perdeu um elemento importante na experiência de visualização. Não apareceu quando essa atualização foi feita. Esse problema foi corrigido.
- **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 pai
Na página Commits, você pode comparar as alterações feitas em um commit específico com seu commit pai. No entanto, talvez você queira navegar até a confirmação pai e entender melhor como essa confirmação difere de seu próprio pai. Isso geralmente é necessário quando você deseja entender todas as alterações em uma versão. Adicionamos um cartão de pai a um commit para ajudá-lo a conseguir isso.
- 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 comparação lado a lado na guia Arquivos de PR, o local de rolagem do usuário seria perdido. Esse problema foi corrigido; O local de rolagem do usuário agora é mantido em um redimensionamento do painel de comparação.
- Pesquisar um commit em um dispositivo móvel
Ao exibir a página Confirmações em um dispositivo móvel, a caixa de pesquisa está ausente na nova experiência. Como resultado, é difícil para você encontrar um commit por seu hash e abri-lo. Isso foi corrigido agora.
- Uso aprimorado de espaço para o novo arquivo de PR com exibição móvel de comparação
Atualizamos esta página para fazer melhor uso do espaço para que os usuários possam ver mais do arquivo em exibições móveis em vez de ter 40% da tela ocupada por um cabeçalho.
- Imagens aprimoradas na exibição de resumo de PR
As imagens editadas em uma PR não estavam sendo exibidas na exibição de resumo de PR, mas eram exibidas corretamente na exibição de arquivos de PR. Esse problema foi resolvido.
- Experiência de branch aperfeiçoada durante a criação de uma PR
Antes dessa atualização, essa experiência não era ideal, pois comparava as alterações com a ramificação padrão do repositório em vez da ramificação de comparação.
Pipelines
Plataforma de agente adicional: ARM64
Adicionamos Linux/ARM64 à lista de plataformas com suporte para o agente do Azure Pipelines. Embora as mudanças de código tenham sido mínimas, muito trabalho nos bastidores teve que ser concluído primeiro, e estamos entusiasmados em anunciar seu lançamento!
Suporte ao filtro de tags para recursos de pipeline
Agora adicionamos 'tags' em pipelines YAML. Você pode usar tags para definir o pipeline de CI para ser executado ou quando disparar automaticamente.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags: ### This filter is used for resolving default version
- Production ### Tags are AND'ed
trigger:
tags: ### This filter is used for triggering the pipeline run
- Production ### Tags are AND'ed
- Signed
O snippet acima mostra que as marcas podem ser usadas para determinar a versão padrão do pipeline de CI (integração contínua) a ser executada quando a execução do pipeline de CD (implantação contínua) não é disparada por alguma outra origem/recurso ou um gatilho de execução agendado.
Por exemplo, se você tiver um gatilho agendado definido para o pipeline de CD que só deseja executar se o CI tiver a tag de produção, as tags na seção triggers garantirão que o pipeline de CD só seja acionado se a condição de marcação for atendida pelo evento de conclusão do IC.
Controlar quais tarefas são permitidas nos pipelines
Agora você pode desabilitar as tarefas do Marketplace. Alguns de vocês podem permitir extensões do Marketplace, mas não as tarefas do Pipelines que elas trazem. Para ainda mais controle, também permitimos que você desative de forma independente todas as tarefas prontas para uso (exceto checkout, que é uma ação especial). Com essas duas configurações habilitadas, as únicas tarefas permitidas para serem executadas em um pipeline seriam aquelas carregadas usando tfx. Visite https://dev.azure.com/<your_org>/_settings/pipelinessettings
e procure a seção chamada "Restrições de tarefas" para começar.
Política de bloqueio de implantação exclusiva
Com essa atualização, você pode garantir que apenas uma única execução seja implantada em um ambiente por vez. Ao escolher a verificação "Bloqueio exclusivo" em um ambiente, apenas uma execução continuará. As execuções subsequentes que desejam implantar nesse ambiente serão pausadas. Assim que a execução com o bloqueio exclusivo for concluída, a última execução continuará. Quaisquer execuções intermediárias serão canceladas.
Filtros de estágios para gatilhos de recursos de pipeline
Adicionamos suporte para 'estágios' como um filtro para recursos de pipeline no YAML. Com esse filtro, você não precisa esperar que todo o pipeline de CI seja concluído para disparar o pipeline de CD. Agora você pode optar por disparar seu pipeline de CD após a conclusão de um estágio específico em seu pipeline de CI.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages: ### This stage filter is used when evaluating conditions for triggering your CD pipeline
- PreProduction ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered.
- Production
Quando os estágios fornecidos no filtro de gatilho são concluídos com êxito no pipeline de CI, uma nova execução é disparada automaticamente para o pipeline de CD.
Gatilhos genéricos baseados em webhook para pipelines YAML
Hoje, temos vários recursos (como pipelines, contêineres, build e pacotes) por meio dos quais você pode consumir artefatos e habilitar gatilhos automatizados. Até agora, no entanto, você não podia automatizar seu processo de implantação com base em outros eventos ou serviços externos. Nesta versão, estamos introduzindo o suporte ao gatilho de webhook em pipelines YAML para permitir a integração da automação de pipeline com qualquer serviço externo. Você pode se inscrever em qualquer evento externo por meio de seus webhooks (Github, Github Enterprise, Nexus, Aritfactory, etc.) e acionar seus pipelines.
Aqui estão as etapas para configurar os gatilhos de webhook:
Configure um webhook em seu serviço externo. Ao criar seu webhook, você precisa fornecer as seguintes informações:
- URL da solicitação - "ADO collection>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview"https://dev.azure.com/<
- Segredo - Isso é opcional. Se você precisar proteger sua carga JSON, forneça o valor Secret
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 de problemas de gatilho de recurso YAML
Pode ser confuso quando os gatilhos de pipeline não são executados como você espera. Para ajudar a entender melhor isso, adicionamos um novo item de menu na página de definição de pipeline chamado "Problemas de gatilho", onde são exibidas informações sobre por que os gatilhos não estão sendo executados.
Os gatilhos de recursos podem falhar ao serem executados por dois motivos.
Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado. Estes são exibidos como erros.
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 vários repositórios
Você pode especificar vários repositórios em um arquivo YAML e fazer com que um pipeline seja disparado por atualizações em qualquer um dos repositórios. Esse recurso é útil, por exemplo, nos seguintes cenários:
- Você consome uma ferramenta ou uma biblioteca de um repositório diferente. Você deseja executar testes para seu aplicativo sempre que a ferramenta ou biblioteca for atualizada.
- Você mantém o arquivo YAML em um repositório separado do código do aplicativo. Você deseja disparar o pipeline sempre que uma atualização é enviada por push para o repositório de aplicativos.
Com essa atualização, os gatilhos de vários repositórios só funcionarão para repositórios Git em Azure Repos. Eles não funcionam para recursos de repositório GitHub ou BitBucket.
Aqui está um exemplo que mostra como definir vários recursos de repositório em um pipeline e como configurar gatilhos em todos eles.
trigger:
- main
resources:
repositories:
- repository: tools
type: git
name: MyProject/tools
ref: main
trigger:
branches:
include:
- main
- release
O pipeline neste exemplo será disparado se houver atualizações para:
main
branch noself
repositório que contém o arquivo YAMLmain
ourelease
ramificações emtools
repositório
Para obter mais informações, consulte Vários repositórios em seu pipeline.
Aprimoramento dos carregamentos de log do agente
Quando um agente para de se comunicar com o servidor do Azure Pipelines, o trabalho que ele estava executando é abandonado. Se você estivesse olhando os logs do console de streaming, talvez tenha obtido algumas pistas sobre o que o agente estava fazendo antes de parar de responder. Mas se você não estivesse, ou se atualizasse a página, esses logs do console desapareceriam. Com esta versão, se o agente parar de responder antes de enviar seus logs completos, manteremos os logs do console como a próxima melhor coisa. Os logs do console são limitados a 1000 caracteres por linha e podem ocasionalmente estar incompletos, mas são muito mais úteis do que não mostrar nada! Examinar esses logs pode ajudá-lo a solucionar problemas de seus próprios pipelines e certamente ajudará nossos engenheiros de suporte quando eles ajudarem na solução de problemas.
Montar volumes de contêiner somente leitura opcionalmente
Quando você executa um trabalho de contêiner no Azure Pipelines, vários volumes que contêm o workspace, as tarefas e outros materiais são mapeados como volumes. Esses volumes usam como padrão o acesso de leitura/gravação. Para aumentar a segurança, você pode montar os volumes somente leitura alterando a especificação do contêiner no YAML. Cada chave abaixo mountReadOnly
pode ser definida como true
somente leitura (o padrão é false
).
resources:
containers:
- container: example
image: ubuntu:18.04
mountReadOnly:
externals: true
tasks: true
tools: true
work: false
Controle refinado sobre o início/a parada do contêiner
Em geral, recomendamos que você permita que o Azure Pipelines gerencie o ciclo de vida de seus contêineres de trabalho e serviço. No entanto, em alguns cenários incomuns, você pode querer iniciá-los e interrompê-los sozinho. Com esta versão, incorporamos esse recurso à tarefa do Docker.
Aqui está um pipeline de exemplo usando o novo recurso:
resources:
containers:
- container: builder
image: ubuntu:18.04
steps:
- script: echo "I can run inside the container (it starts by default)"
target:
container: builder
- task: Docker@2
inputs:
command: stop
container: builder
# if any step tried to run in the container here, it would fail
Além disso, incluímos a lista de contêineres em uma variável de pipeline, Agent.ContainerMapping
. Você pode usar isso se quiser inspecionar a lista de contêineres em um script, por exemplo. Ele contém um objeto JSON em cadeia de caracteres que mapeia o nome do recurso ("builder" do exemplo acima) para a ID do contêiner que o agente gerencia.
Descompactar pacotes de tarefas para cada etapa
Quando o agente executa um trabalho, ele primeiro baixa todos os pacotes de tarefas exigidos pelas etapas do trabalho. Normalmente, para desempenho, ele descompacta as tarefas uma vez por trabalho, mesmo que a tarefa seja usada em várias etapas. Se você tiver dúvidas sobre o código não confiável alterar o conteúdo descompactado, poderá trocar um pouco de desempenho fazendo com que o agente descompacte a tarefa em cada uso. Para habilitar esse modo, passe --alwaysextracttask
ao configurar o agente.
Aprimorar a segurança da versão por meio da restrição do escopo dos tokens de acesso
Com base em nossa iniciativa de aprimorar as configurações de segurança do Azure Pipelines, agora damos suporte à restrição do escopo de tokens de acesso para versões.
Cada trabalho executado em versões obtém um token de acesso. O token de acesso é usado pelas tarefas e por seus scripts para chamar de volta para o Azure DevOps. Por exemplo, usamos o token de acesso para obter código-fonte, baixar artefatos, carregar logs, resultados de teste ou fazer chamadas REST para o Azure DevOps. Um novo token de acesso é gerado para cada trabalho e expira quando o trabalho é concluído.
Com essa atualização, aprimoramos a segurança do pipeline restringindo o escopo dos tokens de acesso e estendendo o mesmo para versões clássicas.
Esse recurso estará ativado por padrão para novos projetos e coleções. Para coleções existentes, você deve habilitá-lo em Configurações > de coleção Configurações de pipelines>. > Limite o escopo de autorização de trabalho ao projeto atual para pipelines de lançamento. Saiba mais aqui.
Aprimoramentos da API de versão prévia do YAML
Agora você pode visualizar o YAML completo de um pipeline sem executá-lo. Além disso, criamos uma nova URL dedicada para o recurso de visualização. Agora você pode POST para https://dev.azure.com/{collection}/{project}/_apis/pipelines/{pipelineId}/preview
recuperar o corpo YAML finalizado. Essa nova API usa os mesmos parâmetros que o enfileiramento de uma execução, mas não requer mais a permissão "Builds de fila".
Executar este trabalho a seguir
Você já teve uma correção de bug que precisava implantar neste minuto , mas teve que esperar por trabalhos de CI e RP? Com esta versão, agora permitimos que você aumente a prioridade de um trabalho na fila. Os usuários com a permissão "Gerenciar" no pool - normalmente administradores de pool - verão um novo botão "Executar em seguida" na página de detalhes do trabalho. Clicar no botão definirá o trabalho a ser executado o mais rápido possível. (Você ainda precisará de paralelismo disponível e um agente adequado, é claro.)
Expressões de modelo permitidas no bloco YAML resources
Anteriormente, as resources
expressões de tempo de compilação (${{ }}
) não eram permitidas na seção de um arquivo YAML do Azure Pipelines. Com esta versão, suspendemos essa restrição para contêineres. Isso permite que você use o conteúdo do parâmetro de tempo de execução dentro de seus recursos, por exemplo, para escolher um contêiner no momento da fila. Planejamos estender esse suporte a outros recursos ao longo do tempo.
Controle sobre atualizações de tarefas automatizadas do Marketplace
Quando você escreve um pipeline YAML, normalmente especifica apenas o número de versão principal das tarefas incluídas. Isso permite que seus pipelines usem automaticamente as adições de recursos e correções de bugs mais recentes. Ocasionalmente, pode ser necessário reverter para uma versão pontual anterior de uma tarefa e, com essa atualização, adicionamos a capacidade de fazer isso. Agora você pode especificar uma versão completa da tarefa major.minor.patch em seus pipelines YAML.
Não recomendamos que você faça isso regularmente e use-o apenas como uma solução temporária quando descobrir que uma tarefa mais recente interrompe seus pipelines. Além disso, isso não instalará uma versão mais antiga de uma tarefa do Marketplace. Ele já deve existir em sua coleção ou seu pipeline falhará.
Exemplo:
steps:
- task: MyTask@1 # a normal, major-version only reference
- task: MyOtherTask@2.3.4 # pinned to a precise version
Suporte ao nó 10 no agente e nas tarefas
Como o Nó 6 não é mais suportado, estamos migrando as tarefas para trabalhar com o Nó 10. Para esta atualização, migramos quase 50% das tarefas in-box para o Nó 10. O agente agora pode executar tarefas do Nó 6 e do Nó 10. Em uma atualização futura, removeremos totalmente o Nó 6 do agente. Para se preparar para a remoção do Nó 6 do agente, solicitamos que você atualize suas extensões internas e tarefas personalizadas para também usar o Nó 10 em breve. Para usar o Nó 10 para sua tarefa, em , em execution
, task.json
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 guia políticas, você pode exibir uma lista de cada branch em que a política está definida. Agora, clique no branch para ver as políticas sem nunca sair da página de configurações do repositório.
Agora, quando as políticas são herdadas de um escopo mais alto do que o que você está trabalhando, mostramos de onde a política foi herdada ao lado de cada política individual. Você também pode navegar até a página em que a política de nível superior foi definida clicando no nome do escopo.
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 UpdateServiceNowChangeRequest
tarefa em um trabalho de servidor para atualizar a solicitação de alteração com o status da implantação, notas etc.
Artifacts
Capacidade de criar feeds no escopo da organização a partir da interface do usuário
Estamos trazendo de volta a capacidade dos clientes de criar e gerenciar feeds com escopo de coleção por meio da interface do usuário da Web para serviços locais e hospedados.
Agora você pode criar feeds no escopo da organização por meio da interface do usuário, acessando Artefatos -> Criar feed e escolhendo um tipo de feed no Escopo.
Embora recomendemos o uso de feeds no escopo do projeto em alinhamento com o restante das ofertas do Azure DevOps, você pode criar, gerenciar e usar novamente feeds no escopo da coleção por meio da interface do usuário e de várias APIs REST. Consulte nossa documentação de feeds para obter mais informações.
A API REST de atualização da versão do pacote já está disponível para pacotes do Maven
Agora você pode usar a API REST "Atualizar Versão do Pacote" do Azure Artifacts para atualizar as versões do pacote Maven. Anteriormente, você podia usar a API REST para atualizar versões de pacote para NuGet, Maven, npm e Pacotes Universais, mas não pacotes Maven.
Para atualizar pacotes Maven, use o comando HTTP PATCH da seguinte maneira.
PATCH
https://pkgs.dev.azure.com/{collection}/{project?}/\_apis/packaging/feeds/{feedId}/maven/groups/{groupId}/artifacts/{artifactId}/versions/{packageVersion}?api-version=5.1-preview.1
Você pode definir o seguinte:
Parâmetros de URI
Nome | In | Obrigatório | Tipo | Descrição |
---|---|---|---|---|
artifactId | caminho | TRUE | string | ID do artefato do pacote |
feed | caminho | TRUE | string | Nome ou ID do feed |
groupId | caminho | TRUE | string | ID do grupo do pacote |
collection | caminho | TRUE | string | O nome da coleção do Azure DevOps |
version | caminho | TRUE | string | Versão do pacote |
project | caminho | string | ID do projeto ou nome do projeto | |
api-version | Consulta | TRUE | string | Versão da API a ser usada. Isso deve ser definido como '5.1-preview.1' para usar esta versão da API |
Corpo da solicitação
Nome | Tipo | Descrição |
---|---|---|
Modos de exibição | JsonPatchOperation | A visualização à qual a versão do pacote será adicionada |
Para obter mais informações, consulte a documentação da API REST à medida que ela é atualizada.
Comentários
Adoraríamos ouvir o que você tem para nos dizer! Você pode relatar um problema ou fornecer uma ideia e rastreá-la por meio da Comunidade de Desenvolvedores e obter conselhos sobre o Stack Overflow.