Azure DevOps Server 2022 Notas de versão

---

| Comunidade | de desenvolvedores Requisitos do sistema e compatibilidade | Termos | de licença DevOps Blog | Hashes SHA-256 |

---

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 Azure DevOps Server, visite a página Downloads do Azure DevOps Server.

A atualização direta para Azure DevOps Server 2022 tem suporte de Azure DevOps Server 2019 ou Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2013 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.

---

Azure DevOps Server 2022 Atualização 0.1 Patch 5 Data de lançamento: 14 de novembro de 2023

Observação

Azure DevOps Server os patches são cumulativos, se você não instalou o Patch 3, esse patch incluirá atualizações para o agente do Azure Pipelines. A nova versão do agente após a instalação do Patch 5 será 3.225.0.

Arquivo	Hash SHA-256
devops2022.0.1patch5.exe	DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022

Lançamos um patch para Azure DevOps Server Atualização 0.1 de 2022 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.
• Correção de um problema que fazia com que as edições de conexões de serviço fossem persistentes após clicar no botão cancelar.

Azure DevOps Server 2022 Atualização 0.1 Patch 4 Data de lançamento: 10 de outubro de 2023

Observação

Azure DevOps Server os patches são cumulativos, se você não instalou o Patch 3, esse patch incluirá atualizações para o agente do Azure Pipelines. A nova versão do agente após a instalação do Patch 5 será 3.225.0.

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

• Corrigido um bug que fazia com que os pipelines ficassem presos ao atualizar o modelo de execução de pipeline.
• Corrigido um bug em que a identidade "Proprietário da Análise" era exibida como Identidade Inativa em máquinas de atualização de patch.
• O trabalho de limpeza de compilação contém muitas tarefas, cada uma das quais exclui um artefato para uma compilação. Se alguma dessas tarefas falhar, nenhuma das tarefas subsequentes será executada. Alteramos esse comportamento para ignorar falhas de tarefas e limpar o máximo de artefatos possível.

Azure DevOps Server 2022 Atualização 0.1 Data de lançamento do Patch 3: 12 de setembro de 2023

Observação

Este patch inclui atualizações para o agente do Azure Pipelines. A nova versão do agente após a instalação do Patch 3 será 3.225.0.

Lançamos um patch para Azure DevOps Server Atualização 0.1 de 2022 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.

Azure DevOps Server 2022 Atualização 0.1 Patch 2 Data de lançamento: 8 de agosto de 2023

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

• CVE-2023-36869: vulnerabilidade de falsificação do Azure DevOps Server.
• Corrigido um bug em chamadas SOAP em que ArithmeticException pode ser gerado para resposta XML de metadados grandes.
• Implementadas alterações no editor de conexões de serviço para que o estado do terminal seja liberado no descarte do componente.
• Foi resolvido um problema em que as ligações relativas não funcionavam em ficheiros markdown.
• Corrigido um problema de desempenho relacionado à camada de aplicativo demorando mais do que o normal para inicializar quando há um grande número de marcas definidas.
• Resolvidos TF400367 erros na página Pools de Agentes.
• 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 2022 Atualização 0.1 Patch 1 Data de lançamento: 13 de junho de 2023

Lançamos um patch para Azure DevOps Server Atualização 0.1 de 2022 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 com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é liberado na dispensa do componente.
• 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 2022 Data de lançamento da Atualização 0.1: 9 de maio de 2023

Azure DevOps Server 2022.0.1 é um pacote cumulativo de correções de bugs. Ele inclui todas as correções no Azure DevOps Server 2022.0.1 RC lançado anteriormente. Você pode instalar diretamente Azure DevOps Server 2022.0.1 ou atualizar de Azure DevOps Server 2022 ou Team Foundation Server 2015 ou mais recente.

Azure DevOps Server 2022 Atualização 0.1 RC Data de lançamento: 11 de abril de 2023

Azure DevOps Server 2022.0.1 RC é um pacote cumulativo de correções de bugs. Ele inclui todas as correções nos patches do Azure DevOps Server 2022 lançados anteriormente. Você pode instalar diretamente Azure DevOps Server 2022.0.1 ou atualizar de Azure DevOps Server 2022 ou Team Foundation Server 2015 ou mais recente.

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

• Atualização do Git Virtual File System (GVFS) para v2.39.1.1-micorosoft.2 para resolver uma vulnerabilidade de segurança.
• 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.
• Atualizações para o AnalyticCleanupJob, o status do trabalho foi Interrompido e agora relatamos Bem-sucedido.
• Corrigido o comando "tfx extension publish" falhando com o erro "A chave fornecida não estava presente no dicionário".
• Implementada uma solução alternativa para resolver um erro ao acessar a extensão Calendário da Equipe.
• CVE-2023-21564: vulnerabilidade de script entre sites do Azure DevOps Server
• CVE-2023-21553: vulnerabilidade de execução remota de código do Azure DevOps Server
• Tarefas do MSBuild e do VSBuild atualizadas para dar suporte ao Visual Studio 2022.
• Atualização da metodologia de carregamento de reautenticação para evitar vetor de ataque XSS.
• Azure DevOps Server 2022 Proxy relata o seguinte erro: VS800069: esse serviço só está disponível no Azure DevOps local.
• Corrigido o problema de acessibilidade dos check-ins particulares por meio da interface do usuário da Web.
• Resolução de um problema que exigia a reinicialização do serviço tfsjobagent e do pool de aplicativos Azure DevOps Server após atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Azure DevOps Server.
• As notificações não estavam sendo enviadas para o PAT sete dias antes da data de expiração.

Azure DevOps Server 2022 Data de lançamento do Patch 4: 13 de junho de 2023

Lançamos um patch para Azure DevOps Server 2022 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 com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é liberado na dispensa do componente.
• 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 2022 Data de lançamento do Patch 3: 21 de março de 2023

Lançamos um patch(19.205.33506.1) para Azure DevOps Server 2022 que inclui correções para o seguinte.

• Resolução de um problema que exigia a reinicialização do serviço tfsjobagent e do pool de aplicativos Azure DevOps Server após atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Azure DevOps Server.
• Copie o estado do ponto de extremidade para o painel de edição do ponto de extremidade de serviço em vez de passá-lo por referência.
• Anteriormente, ao editar conexões de serviço, as edições eram mantidas na interface do usuário após selecionar o botão cancelar. Com esse patch, corrigimos no SDK de Notificação quando uma equipe tem a entrega de notificação definida como Não entregar. Nesse cenário, se a assinatura de notificação estiver configurada com a opção Entrega de preferência de equipe, os membros da equipe não receberão as notificações. Não há necessidade de expandir ainda mais as identidades da equipe para verificar as preferências dos membros.

Azure DevOps Server 2022 Data de lançamento do Patch 2: 14 de fevereiro de 2023

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

• CVE-2023-21564: vulnerabilidade de script entre sites do Azure DevOps Server
• Tarefas do MSBuild e do VSBuild atualizadas para dar suporte ao Visual Studio 2022.
• Atualização da metodologia de carregamento de reautenticação para evitar possível vetor de ataque XSS.
• Azure DevOps Server 2022 Proxy relata o seguinte erro: VS800069: esse serviço só está disponível no Azure DevOps local.

Azure DevOps Server 2022 Data de lançamento do Patch 1: 24 de janeiro de 2023

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

• 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.
• Atualizações para o AnalyticCleanupJob, o status do trabalho foi Interrompido e agora relatamos Bem-sucedido.
• Corrigido o comando "tfx extension publish" falhando com o erro "A chave fornecida não estava presente no dicionário".
• Implementada uma solução alternativa para resolver um erro ao acessar a extensão Calendário da Equipe.

Azure DevOps Server 2022 Data de lançamento: 6 de dezembro de 2022

Azure DevOps Server 2022 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2022 RC2 e RC1 lançados anteriormente.

Azure DevOps Server 2022 RC2 Data de lançamento: 25 de outubro de 2022

Azure DevOps Server 2022 RC2 é um pacote cumulativo de correções de bugs. Ele inclui todos os recursos do Azure DevOps Server 2022 RC1 lançado anteriormente.

Observação

Novos algoritmos SSH RSA ativados

O suporte à chave pública RSA foi aprimorado para oferecer suporte aos tipos de chave pública SHA2, além do SHA1 SSH-RSA que suportamos anteriormente.

Agora, os tipos de chave pública com suporte incluem:

• SSH-RSA
• RSA-SHA2-256
• RSA-SHA2-512

Ação necessária 

Se você implementou a solução alternativa para habilitar o SSH-RSA especificando-o explicitamente no .ssh/config1 arquivo, será necessário remover o PubkeyAcceptedTypes, ou modificá-lo para usar RSA-SHA2-256 ou RSA-SHA2-512 ou ambos. Você pode encontrar detalhes sobre o que fazer se ainda for solicitada sua senha e GIT_SSH_COMMAND="ssh -v" git fetch não mostrar nenhum algoritmo de assinatura mútua na documentação aqui.

O suporte a teclas elípticas ainda não foi adicionado e continua sendo um recurso altamente solicitado em nossa lista de pendências.

Azure DevOps Server 2022 RC1 Data de lançamento: 9 de agosto de 2022

Resumo das novidades em Azure DevOps Server 2022

Importante

O Warehouse and Analysis Service foi preterido na versão anterior do Azure DevOps Server (2020). Em Azure DevOps Server 2022, o Warehouse and Analysis Service foi removido do produto. O Google Analytics agora oferece a experiência de geração de relatórios no produto.

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

• Planos de Entrega
• Exibir persona correta em links de commit
• Novos controles para variáveis de ambiente em pipelines
• Gerar token irrestrito para builds de bifurcação
• Novas páginas TFVC
• Agrupar por Tags disponíveis em widgets de gráfico

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

• Boards
• Repos
• Pipelines
• Relatório

---

Boards

Planos de entrega

Temos o prazer de anunciar que os Planos de Entrega agora estão incluídos em Azure DevOps Server. Os Planos de Entrega oferecem 3 cenários principais:

• Uma visão do cronograma do plano
• Andamento dos trabalhos
• Acompanhamento de dependência

Abaixo estão as principais características. Filtragem, Marcadores e Critérios de Campo também fazem parte dos Planos de Entrega.

Existem duas visões principais: condensada e expandida

Os Planos de Entrega 2.0 permitem exibir todos os itens de trabalho em seu plano em uma linha do tempo, usando datas de início e destino ou datas de iteração. A ordem de precedência é as datas de início e destino seguidas pela iteração. Isso permite adicionar itens de trabalho no nível do portfólio, comoEpic, que geralmente não são definidos para uma iteração.

Existem duas visualizações principais: a visualização condensada e a visualização expandida. Você também pode aumentar e diminuir o zoom do plano clicando na lupa no lado direito do plano.

Existem duas visualizações principais: a visualização condensada e a visualização expandida. Você também pode aumentar e diminuir o zoom do plano clicando na lupa no lado direito do plano.

• Visualização condensada

  A exibição condensada mostra todos os cartões de item de trabalho recolhidos , o que significa que nem todas as informações do cartão são mostradas. Essa visão é útil para uma visão geral do trabalho no plano. Para recolher os campos do cartão, clique no ícone do cartão ao lado dos ícones de lupa no lado direito do plano.

  Aqui está um exemplo de um plano alternando entre as exibições condensadas e expandidas.

  

• Visualização expandida

  A exibição expandida mostra o progresso de um item de trabalho contando o número de itens filho e vinculados e mostrando a porcentagem concluída. Atualmente, o progresso é determinado pela contagem de itens de trabalho.

  Aqui está um exemplo de um plano usando uma exibição expandida. Observe as barras de progresso e a porcentagem concluída.

  

Acompanhamento de dependência

O rastreamento de dependência é baseado em links predecessores e sucessores definidos em itens de trabalho. Se esses links não estiverem definidos, nenhuma linha de dependência será exibida. Quando há um problema de dependência com um item de trabalho, o ícone de link de dependência é colorido em vermelho.

• Exibindo dependências

  Dependências específicas são visualizadas por meio do painel de dependências que mostra todas as dependências desse item de trabalho, incluindo a direção. Um ponto de exclamação vermelho indica um problema de dependência. Para abrir o painel, basta clicar no ícone do link de dependência no canto superior direito do cartão. Aqui estão exemplos de dependências.

  

  

• Linhas de dependência

  As dependências entre itens de trabalho são visualizadas com linhas de seta direcionais entre os respectivos itens de trabalho. Várias dependências serão exibidas como várias linhas. Uma linha vermelha indica um problema.

  Aqui estão alguns exemplos.

  

  Aqui está um exemplo de um item de trabalho com várias dependências e também funciona usando a exibição condensada.

  

  Quando há um problema, a cor da linha é vermelha, assim como o ícone de dependência.

  Veja um exemplo.

  

Estilo do cartão

Os cartões agora podem ser estilizados usando regras, como os quadros Kanban. Abra as configurações do plano e clique em Estilos. No painel Estilos, clique em + Adicionar regra de estilo para adicionar a regra e clique em Salvar. Pode haver até 10 regras e cada regra pode ter até 5 cláusulas.

• Antes

• Depois

Para saber mais sobre os Planos de Entrega, confira a documentação aqui.

Itens removidos no Hub de Itens de Trabalho

O Hub de Itens de Trabalho é o local para ver uma lista de itens que você criou ou que são atribuídos a você. Ele fornece várias funções personalizadas de pivô e filtro para simplificar a listagem de itens de trabalho. Uma das principais reclamações do pivô Atribuído a mim é que ele exibe itens de trabalho removidos. Concordamos que os itens de trabalho removidos não têm mais valor e não devem estar na lista de pendências. Neste sprint, estamos ocultando todos os itens removidos das exibições Atribuído a mim no Hub de Itens de Trabalho.

Exibir persona correta em links de commit

A seção de desenvolvimento em um item de trabalho mostra a lista de confirmações e solicitações de pull relevantes. Você pode exibir o autor da solicitação de confirmação ou pull junto com o tempo associado. Com esta atualização, corrigimos um problema com o avatar do autor sendo exibido incorretamente na visualização.

Remover a capacidade de baixar um anexo excluído do histórico de itens de trabalho

Corrigimos um pequeno problema em que os usuários conseguiam baixar anexos do histórico do item de trabalho, mesmo depois que o anexo era removido do formulário. Agora, depois que o anexo for removido, ele não poderá ser baixado do histórico, nem a URL de download estará disponível na resposta da API REST.

Adicionado o valor "Não corrigirá" ao campo Motivo do bug

Assim como acontece com todos os outros tipos de item de trabalho, o tipo de item de trabalho Bug tem um fluxo de trabalho bem definido. Cada fluxo de trabalho é composto por três ou mais Estados e um Motivo. Os motivos especificam por que o item fez a transição de um Estado para outro. Com essa atualização, adicionamos um valor de motivo não corrigirá para os tipos de item de trabalho Bug no processo Agile. O valor estará disponível como um motivo ao mover Bugs de Novo ou Ativo para Resolvido. Você pode saber mais sobre como definir, capturar, fazer a triagem e gerenciar bugs de software na documentação do Azure Boards.

Pipelines

Remoção de políticas de retenção por pipeline em builds clássicos

Agora você pode configurar políticas de retenção para builds clássicos e pipelines YAML nas configurações do projeto do Azure DevOps. Não há mais suporte para regras de retenção por pipeline para pipelines de build clássicos. Embora essa seja a única maneira de configurar a retenção para pipelines YAML, você também pode configurar a retenção para pipelines de build clássicos por pipeline. Removemos todas as regras de retenção por pipeline para pipelines de build clássicos em uma versão futura.

O que isso significa para você: qualquer pipeline de build clássico que costumava ter regras de retenção por pipeline será regido pelas regras de retenção no nível do projeto.

Para garantir que você não perca nenhuma compilação durante a atualização, criaremos uma concessão para todas as compilações existentes no momento da atualização que não tenham uma concessão.

Recomendamos que você verifique as configurações de retenção no nível do projeto após a atualização. Se o pipeline exigir especificamente regras personalizadas, você poderá usar uma tarefa personalizada no pipeline. Para obter informações sobre como adicionar concessões de retenção por meio de uma tarefa, consulte a documentação definir políticas de retenção para builds, versões e testes.

Novos controles para variáveis de ambiente em pipelines

O agente do Azure Pipelines verifica a saída padrão em busca de comandos de log especiais e os executa. O setVariable comando pode ser usado para definir uma variável ou modificar uma variável definida anteriormente. Isso pode ser potencialmente explorado por um ator fora do sistema. Por exemplo, se o pipeline tiver uma etapa que imprime a lista de arquivos em um servidor ftp, uma pessoa com acesso ao servidor ftp poderá adicionar um novo arquivo, cujo nome contém o setVariable comando e fazer com que o pipeline altere seu comportamento.

Temos muitos usuários que dependem da configuração de variáveis usando o comando logging em seu pipeline. Com esta versão, estamos fazendo as seguintes alterações para reduzir o risco de usos indesejados do setVariable comando.

• Adicionamos uma nova construção para autores de tarefas. Ao incluir um snippet como o seguinte no task.json, um autor de tarefa pode controlar se alguma variável é definida por sua tarefa.

{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 

• Além disso, estamos atualizando várias tarefas integradas, como ssh, para que não possam ser exploradas.

• Por fim, agora você pode usar construções YAML para controlar se uma etapa pode definir variáveis.

steps:
- script: echo hello
  target:
    settableVariables: none

steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Gerar token irrestrito para builds de bifurcação

Os usuários do GitHub Enterprise geralmente usam bifurcações para contribuir com um repositório upstream. Quando o Azure Pipelines cria contribuições de uma bifurcação de um repositório GitHub Enterprise, ele restringe as permissões concedidas ao token de acesso ao trabalho e não permite que os segredos do pipeline sejam acessados por esses trabalhos. Você pode encontrar mais informações sobre a segurança da construção de bifurcações em nossa documentação.

Isso pode ser mais restritivo do que o desejado em ambientes fechados, onde os usuários ainda podem se beneficiar de um modelo de colaboração de origem interna. Embora você possa definir uma configuração em um pipeline para disponibilizar segredos para bifurcações, não há nenhuma configuração para controlar o escopo do token de acesso ao trabalho. Com esta versão, estamos dando a você o controle para gerar um token de acesso de trabalho regular, mesmo para compilações de bifurcações.

Você pode alterar essa configuração em Gatilhos no editor de pipeline. Antes de alterar essa configuração, certifique-se de entender completamente as implicações de segurança de habilitar essa configuração.

Repositórios como um recurso protegido em pipelines YAML

Você pode organizar seu projeto do Azure DevOps para hospedar muitos subprojetos, cada um com seu próprio repositório Git do Azure DevOps e um ou mais pipelines. Nessa estrutura, talvez você queira controlar quais pipelines podem acessar quais repositórios. Por exemplo, digamos que você tenha dois repositórios A e B no mesmo projeto e dois pipelines X e Y que normalmente criam esses repositórios. Talvez você queira impedir que o pipeline Y acesse o repositório A. Em geral, você deseja que os colaboradores de A controlem a quais pipelines eles desejam fornecer acesso.

Embora isso fosse parcialmente possível com repositórios e pipelines do Azure Git, não havia experiência para gerenciá-lo. Esse recurso aborda essa lacuna. Os repositórios do Azure Git agora podem ser tratados como recursos protegidos em pipelines YAML, assim como conexões de serviço e pools de agentes.

Como colaborador do repositório A, você pode adicionar verificações e permissões de pipeline ao seu repositório. Para fazer isso, navegue até as configurações do projeto, selecione Repositórios e, em seguida, seu repositório. Você notará um novo menu chamado "Verificações", onde você pode configurar qualquer uma das verificações prontas ou personalizadas na forma de funções do Azure.

Na guia "Segurança", você pode gerenciar a lista de pipelines que podem acessar o repositório.

Sempre que um pipeline YAML usa um repositório, a infraestrutura do Azure Pipelines verifica e garante que todas as verificações e permissões sejam atendidas.

Observação

Essas permissões e verificações são aplicáveis apenas a pipelines YAML. Os pipelines clássicos não reconhecem esses novos recursos.

Permissões e verificações em grupos de variáveis e arquivos seguros

Você pode usar diferentes tipos de recursos compartilhados em pipelines YAML. Os exemplos incluem conexões de serviço, grupos de variáveis, arquivos seguros, pools de agentes, ambientes ou repositórios. Para proteger um pipeline de acessar um recurso, o proprietário do recurso pode configurar permissões e verificações nesse recurso. Sempre que um pipeline tenta acessar o recurso, todas as permissões e verificações configuradas são avaliadas. Essas proteções estão disponíveis em conexões de serviço, ambientes e pools de agentes há algum tempo. Eles foram adicionados recentemente aos repositórios. Com esta versão, estamos adicionando as mesmas proteções a grupos de variáveis e arquivos seguros.

Para restringir o acesso a um grupo de variáveis ou a um arquivo seguro a um pequeno conjunto de pipelines, use o recurso Permissões de pipelines.

Para configurar verificações ou aprovações que devem ser avaliadas sempre que um pipeline for executado, use o recurso Aprovações e verificações da Biblioteca .

Alterações na criação automática de ambientes

Quando você cria um pipeline YAML e se refere a um ambiente que não existe, o Azure Pipelines cria automaticamente o ambiente. Essa criação automática pode ocorrer no contexto do usuário ou no contexto do sistema. Nos fluxos a seguir, o Azure Pipelines sabe sobre o usuário que executa a operação:

• Você usa o assistente de criação de pipeline YAML na experiência Web do Azure Pipelines e se refere a um ambiente que ainda não foi criado.
• Atualize o arquivo YAML usando o editor Web do Azure Pipelines e salve o pipeline depois de adicionar uma referência a um ambiente que não existe. Em cada um dos casos acima, o Azure Pipelines tem uma compreensão clara do usuário que executa a operação. Portanto, ele cria o ambiente e adiciona o usuário à função de administrador do ambiente. Esse usuário tem todas as permissões para gerenciar o ambiente e/ou incluir outros usuários em várias funções para gerenciar o ambiente.

Nos fluxos a seguir, o Azure Pipelines não tem informações sobre o usuário que está criando o ambiente: você atualiza o arquivo YAML usando outro editor de código externo, adiciona uma referência a um ambiente que não existe e, em seguida, faz com que um pipeline de integração contínua seja disparado. Nesse caso, o Azure Pipelines não conhece o usuário. Anteriormente, tratamos desse caso adicionando todos os colaboradores do projeto à função de administrador do ambiente. Qualquer membro do ambiente poderia alterar essas permissões e impedir que outras pessoas acessassem o ambiente.

Recebemos seus comentários sobre a concessão de permissões de administrador em um ambiente a todos os membros de um projeto. Ao ouvirmos seus comentários, ouvimos que não devemos criar automaticamente um ambiente se não estiver claro quem é o usuário que executa a operação. Com esta versão, fizemos alterações em como os ambientes serão criados automaticamente:

• No futuro, as execuções de pipeline não criarão automaticamente um ambiente se ele não existir e se o contexto do usuário não for conhecido. Nesses casos, o pipeline falhará com um erro Ambiente não encontrado. Você precisa pré-criar os ambientes com a segurança correta e verificar a configuração antes de usá-lo em um pipeline.
• Os pipelines com contexto de usuário conhecido ainda criarão ambientes automaticamente, assim como faziam no passado.
• Por fim, deve-se notar que o recurso para criar automaticamente um ambiente foi adicionado apenas para simplificar o processo de introdução ao Azure Pipelines. Ele foi feito para cenários de teste e não para cenários de produção. Você deve sempre pré-criar ambientes de produção com as permissões e verificações corretas e, em seguida, usá-los em pipelines.

Remover a caixa de diálogo Insights do Build Pipeline

Com base em seus comentários, a caixa de diálogo Insights de tarefa/pipeline exibida ao navegar no Pipeline de Build foi removida para melhorar o fluxo de trabalho. A análise de pipeline ainda está disponível para que você tenha os insights necessários.

Suporte para implantações sequenciais em vez de mais recentes apenas ao usar verificações de bloqueio exclusivas

Em pipelines YAML, as verificações são usadas para controlar a execução de estágios em recursos protegidos. Uma das verificações comuns que você pode usar é uma verificação de bloqueio exclusiva. Essa verificação permite que apenas uma única execução do pipeline prossiga. Quando várias execuções tentam implantar em um ambiente ao mesmo tempo, a verificação cancela todas as execuções antigas e permite que a execução mais recente seja implantada.

Cancelar execuções antigas é uma boa abordagem quando suas versões são cumulativas e contêm todas as alterações de código de execuções anteriores. No entanto, há alguns pipelines nos quais as alterações de código não são cumulativas. Com esse novo recurso, você pode optar por permitir que todas as execuções prossigam e sejam implantadas sequencialmente em um ambiente ou preservar o comportamento anterior de cancelar execuções antigas e permitir apenas as mais recentes. Você pode especificar esse comportamento usando uma nova propriedade chamada lockBehavior no arquivo YAML do pipeline. Um valor de sequential implica que todas as execuções adquirem o bloqueio sequencialmente para o recurso protegido. Um valor de runLatest implica que somente a execução mais recente adquire o bloqueio para o recurso.

Para usar a verificação de bloqueio exclusivo com implantações sequential ou runLatest, siga estas etapas:

1. Habilite a verificação de bloqueio exclusivo no ambiente (ou em outro recurso protegido).
2. No arquivo YAML do pipeline, especifique uma nova propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para uma determinada fase:

Definir em uma fase:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Definir no pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Se você não especificar um lockBehavior, presume-se que seja runLatest.

Suporte para a versão Quebec do ServiceNow

O Azure Pipelines tem uma integração existente com o ServiceNow. A integração depende de um aplicativo no ServiceNow e uma extensão no Azure DevOps. Agora atualizamos o aplicativo para funcionar com a versão Quebec do ServiceNow. Os pipelines clássicos e YAML agora funcionam com Quebec. Para garantir que essa integração funcione, atualize para a nova versão do aplicativo (4.188.0) na loja Service Now. Para obter mais informações, consulte Integrar com o Gerenciamento de Alterações do ServiceNow.

Novas expressões condicionais YAML

Escrever expressões condicionais em arquivos YAML ficou mais fácil com o uso de ${{ else }} expressões and ${{ elseif }} . Abaixo estão exemplos de como usar essas expressões em arquivos de pipelines YAML.

steps:
- script: tool
  env:
    ${{ if parameters.debug }}:
      TOOL_DEBUG: true
      TOOL_DEBUG_DIR: _dbg
    ${{ else }}:
      TOOL_DEBUG: false
      TOOL_DEBUG_DIR: _dbg

variables:
  ${{ if eq(parameters.os, 'win') }}:
    testsFolder: windows
  ${{ elseif eq(parameters.os, 'linux' }}:
    testsFolder: linux
  ${{ else }}:
    testsFolder: mac

Suporte para curingas em filtros de caminho

Os curingas podem ser usados ao especificar ramificações de inclusão e exclusão para gatilhos de CI ou PR em um arquivo YAML de pipeline. No entanto, eles não podem ser usados ao especificar filtros de caminho. Por exemplo, você não pode incluir todos os caminhos que correspondem a src/app/**/myapp*. Isso foi apontado como um inconveniente por vários clientes. Esta atualização preenche essa lacuna. Agora, você pode usar caracteres curinga (**, *ou ?) ao especificar filtros de caminho.

A especificação padrão do agente para pipelines será Windows-2022

A windows-2022 imagem está pronta para ser a versão padrão do windows-latest rótulo nos agentes hospedados pela Microsoft do Azure Pipelines. Até agora, esse rótulo apontava para agentes do Windows-2019. Essa mudança será implementada ao longo de um período de várias semanas a partir de 17 de janeiro. Planejamos concluir a migração até março.

O Azure Pipelines tem suporte windows-2022 desde setembro de 2021. Monitoramos seus comentários para melhorar a estabilidade da windows-2022 imagem e agora estamos prontos para defini-lo como o mais recente.

A windows-2022 imagem inclui o Visual Studio 2022. Para obter uma lista completa das diferenças entre windows-2022 e windows-2019, visite o problema do GitHub. Para obter uma lista completa do software instalado na imagem, verifique aqui.

A renomeação da pasta do pipeline valida as permissões

As pastas que contêm pipelines podem ser renomeadas. Renomear uma pasta agora só terá êxito se o usuário tiver permissões de edição em pelo menos um pipeline contido na pasta.

Planejamento de atualização de runtime do Agente de Pipelines

O que é o Agente de Pipeline?

O Azure DevOps Pipeline Agent é o produto de software executado em um host de pipeline para executar trabalhos de pipeline. Ele é executado em agentes hospedados pela Microsoft, agentes do Conjunto de Dimensionamento e agentes auto-hospedados. Neste último caso, você mesmo o instala. O Agente de Pipeline consiste em um Ouvinte e um Trabalhador (implementados no .NET), o Trabalhador executa tarefas que são implementadas no Node ou no PowerShell e, portanto, hospeda esses runtimes para eles.

Próxima atualização para o .NET 6 e descontinuação do Red Hat 6

Com o lançamento do .NET 6 , podemos aproveitar seus novos recursos de plataforma cruzada. Especificamente, poderemos fornecer compatibilidade nativa para Apple Silicon e Windows Arm64. Portanto, planejamos mudar para o .NET 6 para o Agente de Pipeline (Ouvinte e Trabalhador) nos próximos meses.

Devido a uma série de restrições que isso impõe, estamos descartando o suporte ao Red Hat Enterprise Linux 6 de nosso agente em 30 de abril de 2022.

Atualizações para a tarefa de Cópia de Arquivo do Azure

Estamos lançando uma nova versão da tarefa de Cópia de Arquivo do Azure. Essa tarefa é usada para copiar arquivos para blobs de armazenamento ou VMs (máquinas virtuais) do Microsoft Azure. A nova versão tem várias atualizações que têm sido frequentemente solicitadas pela comunidade:

• A versão da ferramenta AzCopy foi atualizada para 10.12.2, que tem suporte para tipos de conteúdo de arquivo. Como resultado, quando você copia PDF, Excel, PPT ou um dos tipos MIME suportados, o tipo de conteúdo do arquivo é definido corretamente.

• Com a nova versão do AzCopy, você também pode definir uma configuração para limpar o destino quando o tipo de destino for Blob do Azure. Definir esta opção excluirá todas as pastas/arquivos nesse contêiner. Ou, se um prefixo de blob for fornecido, todas as pastas/arquivos nesse prefixo serão excluídos.

• A nova versão da tarefa depende de módulos Az instalados no agente em vez de módulos AzureRM. Isso removerá um aviso desnecessário em alguns casos ao usar a tarefa.

As alterações fazem parte de uma atualização de versão principal para esta tarefa. Você teria que atualizar explicitamente seus pipelines para usar a nova versão. Fizemos essa escolha de atualizar a versão principal para garantir que não interrompamos nenhum pipeline que ainda dependa dos módulos do AzureRM.

Novos pontos de extensão para a exibição de detalhes do Pipelines

Adicionamos dois novos pontos de extensibilidade que você pode direcionar em suas extensões. Esses pontos de extensibilidade permitem adicionar um botão personalizado no cabeçalho do pipeline e um menu personalizado em uma pasta de pipeline:

• Botão personalizado no cabeçalho do pipeline: ms.vss-build-web.pipelines-header-menu
• Menu personalizado em uma pasta de pipeline: ms.vss-build-web.pipelines-folder-menu

Para usar esses novos pontos de extensibilidade, basta adicionar uma nova contribuição direcionada a eles no arquivo de manifesto da extensão do Azure DevOpsvss-extension.json.

Por exemplo:

"contributions": [
        {
            "id": "pipelinesFolderContextMenuTestItem",
            "type": "ms.vss-web.action",
            "description": "Custom menu on a pipeline folder",
            "targets": [
                "ms.vss-build-web.pipelines-folder-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        },
        {
            "id": "pipelinesHeaderTestButton",
            "type": "ms.vss-web.action",
            "description": "Custom button in the pipeline header",
            "targets": [
                "ms.vss-build-web.pipelines-header-menu"
            ],
            "properties": {
                "text": "Test item",
                "title": "ms.vss-code-web.source-item-menu",
                "icon": "images/show-properties.png",
                "group": "actions",
                "uri": "main.html",
                "registeredObjectId": "showProperties"
            }
        }
]

O resultado será:

• Botão personalizado no cabeçalho do pipeline

  

• Menu personalizado em uma pasta de pipeline

  

Migração aprimorada para Azure DevOps Services

Ao executar uma importação de Azure DevOps Server para Azure DevOps Services, você deve considerar que Azure DevOps não dá mais suporte a regras de retenção por pipeline. Com essa atualização, removemos essas políticas quando você migra para Azure DevOps Services do Azure DevOps Server local. Para saber mais sobre como configurar políticas de retenção, consulte nossa documentação sobre como definir políticas de retenção para builds, versões e testes.

Melhoria na API REST de execuções de pipelines

Anteriormente, a API REST de execuções de pipelines retornava apenas o self repositório. Com essa atualização, a API REST de Execuções de Pipelines retorna todos os recursos do repositório de um build.

Os modelos estendidos do YAML Pipelines agora podem receber informações de contexto para estágios, trabalhos e implantações

Com essa atualização, estamos adicionando uma nova templateContext propriedade para jobcomponentes de pipeline , deploymente e stage YAML destinados a serem usados em conjunto com modelos.

Aqui está um cenário para usar templateContext:

• Você usa modelos para reduzir a duplicação de código ou melhorar a segurança de seus pipelines

• Seu modelo usa como parâmetro uma lista de stages, jobs, ou deployments

• O modelo processa a lista de entrada e executa algumas transformações em cada um dos estágios, trabalhos ou implantações. Por exemplo, ele define o ambiente no qual cada trabalho é executado ou adiciona etapas adicionais para impor a conformidade

• O processamento requer que informações adicionais sejam passadas pelo autor do pipeline para o modelo para cada estágio, trabalho ou implantação na lista

Vejamos um exemplo. Digamos que você esteja criando um pipeline que executa testes de ponta a ponta para validação de solicitação de pull. Seu objetivo é testar apenas um componente do sistema, mas, como você planeja executar testes de ponta a ponta, precisa de um ambiente em que mais componentes do sistema estejam disponíveis e precisa especificar seu comportamento.

Você percebe que outras equipes terão necessidades semelhantes, então decide extrair as etapas para configurar o ambiente em um modelo. Seu código é semelhante ao seguinte:

testing-template.yml

parameters: 
- name: testSet
  type: jobList

jobs:
- ${{ each testJob in parameters.testSet }}:
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
    - job:
      steps:
        - script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
    - job:
      steps:
        - script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
        - ${{ testJob.steps }}

O que o modelo faz é, para cada trabalho no testSet parâmetro, ele define a resposta dos componentes do sistema especificados por ${{ testJob.templateContext.requiredComponents }} para retornar ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Em seguida, você pode criar seu próprio pipeline que se estende testing-template.yml como no exemplo a seguir.

sizeapi.pr_validation.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml
  parameters:
    testSet:
    - job: positive_test
      templateContext:
        expectedHTTPResponseCode: 200
        requiredComponents: dimensionsapi
      steps:
      - script: ./runPositiveTest.sh
    - job: negative_test
      templateContext:
        expectedHTTPResponseCode: 500
        requiredComponents: dimensionsapi
      steps:
      - script: ./runNegativeTest.sh

Este pipeline executa dois testes, um positivo e um negativo. Ambos os testes exigem que o dimensionsapi componente esteja disponível. O positive_test trabalho espera que o código HTTP de retorno 200 seja retornado, enquanto negative_test espera que ele retorne o dimensionsapi código HTTP 500.

Contas de serviço gerenciado do grupo de suporte como conta de serviço do agente

O agente do Azure Pipelines agora dá suporte a Contas de Serviço Gerenciado de Grupo em agentes auto-hospedados no Windows.

As Contas de Serviço Gerenciado de Grupo fornecem gerenciamento centralizado de senhas para contas de domínio que atuam como contas de serviço. O Agente do Azure Pipelines pode reconhecer esse tipo de conta, portanto, uma senha não é necessária durante a configuração:

.\config.cmd --url https://dev.azure.com/<Organization> `
             --auth pat --token <PAT> `
             --pool <AgentPool> `
             --agent <AgentName> --replace `
             --runAsService `
             --windowsLogonAccount <DOMAIN>\<gMSA>

Execuções informativas

Uma execução informativa informa que o Azure DevOps falhou ao recuperar o código-fonte de um pipeline YAML. Essa corrida se parece com a seguinte.

O Azure DevOps recupera o código-fonte de um pipeline YAML em resposta a eventos externos, por exemplo, uma confirmação por push ou em resposta a gatilhos internos, por exemplo, para verificar se há alterações de código e iniciar uma execução agendada ou não. Quando essa etapa falha, o sistema cria uma execução informativa. Essas execuções serão criadas somente se o código do pipeline estiver em um repositório GitHub ou BitBucket.

A recuperação do código YAML de um pipeline pode falhar devido a:

• Uma interrupção em um provedor de repositório
• Limitação de solicitação
• Problemas de autenticação
• Não é possível recuperar o conteúdo do arquivo .yml do pipeline

Leia mais sobre execuções informativas.

A propriedade da API retentionRules REST de definição de compilação está obsoleta

No tipo de BuildDefinition resposta da API REST de Definição de Build, a retentionRules propriedade agora está marcada como obsoleta, pois essa propriedade sempre retorna um conjunto vazio.

Repos

Novas páginas TFVC

Atualizamos várias páginas no Azure DevOps para usar uma nova plataforma Web com o objetivo de tornar a experiência mais consistente e acessível entre os vários serviços. As páginas do TFVC foram atualizadas para usar a nova plataforma Web. Com esta versão, estamos disponibilizando as novas páginas do TFVC para o público em geral.

Desabilitar um repositório

Os clientes geralmente solicitam uma maneira de desabilitar um repositório e impedir que os usuários acessem seu conteúdo. Por exemplo, você pode querer fazer isso quando:

• Você encontrou um segredo no repositório.
• Uma ferramenta de verificação de terceiros descobriu que um repositório estava fora de conformidade.

Nesses casos, talvez você queira desativar temporariamente o repositório enquanto trabalha para resolver o problema. Com esta atualização, você pode desabilitar um repositório se tiver permissões de exclusão de repositório . Ao desabilitar um repositório, você:

• Pode listar o repositório na lista de repositórios
• Não é possível ler o conteúdo do repositório
• Não é possível atualizar o conteúdo do repositório
• Veja uma mensagem informando que o repositório foi desabilitado quando eles tentam acessar o repositório na interface do usuário do Azure Repos

Depois que as etapas de mitigação necessárias forem executadas, os usuários com a permissão Excluir repositório poderão reabilitar o repositório. Para desabilitar ou habilitar um repositório, vá para Configurações do Projeto, selecione Repositórios e, em seguida, o repositório específico.

Configurar criadores de branch para não receber "Permissões para gerenciar" em suas ramificações

Ao criar um novo branch, você obtém "Gerenciar permissões" nesse branch. Essa permissão permite alterar as permissões de outros usuários ou admitir usuários adicionais para contribuir com essa ramificação. Por exemplo, um criador de branch pode usar essa permissão para permitir que outro usuário externo faça alterações no código. Ou eles podem permitir que um pipeline (identidade de serviço de build) altere o código nesse branch. Em certos projetos com requisitos de conformidade mais altos, os usuários não devem ser capazes de fazer tais alterações.

Com essa atualização, você pode configurar todo e qualquer repositório em seu projeto de equipe e impedir que os criadores de branch obtenham a permissão "Gerenciar permissões". Para fazer isso, navegue até as configurações do projeto, selecione Repositórios e, em seguida, Configurações para todos os repositórios ou um repositório específico.

Essa configuração está ativada por padrão para imitar o comportamento existente. Mas você pode desativá-lo se desejar usar esse novo recurso de segurança.

Impedir que os usuários do branch votem em seus PRs upstream

Com Azure Repos, os usuários com permissão de "leitura" em um repositório podem bifurcar o repositório e fazer alterações em sua bifurcação. Para enviar uma solicitação de pull com suas alterações no upstream, os usuários precisam da permissão "contribuir para solicitações de pull" no upstream. No entanto, essa permissão também rege quem pode votar em solicitações de pull no repositório upstream. Como resultado, você pode acabar em situações em que um usuário, que não é um colaborador do repositório, pode enviar uma solicitação de pull e fazer com que ela seja mesclada, dependendo de como você configura as políticas de branch.

Em projetos que promovem um modelo de fonte interna, bifurcar e contribuir é um padrão comum. Para proteger e promover ainda mais esse padrão, estamos alterando a permissão para votar em uma solicitação de pull de "contribuir para solicitações de pull" para "contribuir". No entanto, essa alteração não está sendo feita por padrão em todos os projetos. Você precisa aceitar e selecionar uma nova política em seu repositório, chamada "Modo de votação estrita" para alternar essa permissão. Recomendamos que você faça isso se depender de bifurcações no Azure Repos.

Reporting

Agrupar por Tags disponíveis em widgets de gráfico

O widget de gráfico Agrupar por Tags agora está disponível por padrão para todos os clientes. Ao usar o widget de gráfico, agora há uma opção disponível para tags. Os usuários podem visualizar suas informações selecionando todas as tags ou um conjunto de tags no widget.

Exibir tipos de item de trabalho personalizados no widget de burndown

Anteriormente, você não conseguia ver os tipos de item de trabalho personalizados configurados no widget de burndown e somados ou contados por um campo personalizado. Com essa atualização, corrigimos esse problema e agora você pode ver os tipos de item de trabalho personalizados no widget de burndown.

---

Comentários

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

---

Início da página