Notas de versão do Azure DevOps Server 2022

---

| | Developer Community Recursosdelicença | de compatibilidade | erequisitos de sistema DevOps blog | SHA-256 Hashes |

---

Neste artigo, você encontrará informações sobre a versão mais recente para Azure DevOps Server.

Para saber mais sobre como instalar ou atualizar uma implantação de Azure DevOps Server, confira Azure DevOps Server Requisitos.

Para baixar Azure DevOps Server produtos, visite a página Downloads do Azure DevOps Server.

A atualização direta para o Azure DevOps Server 2022 tem suporte do Azure DevOps Server 2019 ou do 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 o Azure DevOps Server 2022. Consulte a página Instalar para obter mais informações.

---

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

Observação

Azure DevOps Server 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á a 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.

• Estendeu a lista de caracteres permitidos das tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas de shell.
• Correção de um problema que fazia com que as edições de conexões de serviço fossem persistentes depois de clicar no botão Cancelar.

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

Observação

Azure DevOps Server 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á a 3.225.0.

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

• Correção de um bug que fazia com que os pipelines travassem atualizando o modelo de execução do pipeline.
• Correção de um bug em que a identidade do "Proprietário da Análise" era mostrada como Identidade Inativa em computadores de atualização de patch.
• O trabalho de limpeza de build contém muitas tarefas, cada uma das quais exclui um artefato para um build. Se alguma dessas tarefas falhou, nenhuma das tarefas subsequentes foi executada. Alteramos esse comportamento para ignorar falhas de tarefa e limpo o máximo de artefatos que pudermos.

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

Observação

Esse 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á a 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: Azure DevOps Server vulnerabilidade de execução remota de código.
• CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.

data de lançamento do Patch 2 do Azure DevOps Server 2022 Atualização 0.1: 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: Azure DevOps Server vulnerabilidade de falsificação.
• Correção de um bug em chamadas SOAP em que ArithmeticException pode ser gerado para uma resposta XML de metadados grandes.
• Alterações implementadas no editor de conexões de serviço para que o estado do ponto de extremidade seja liberado no descarte do componente.
• Resolvido o problema com links relativos que não funcionavam em arquivos 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.
• Resolvido TF400367 erros na página Pools de Agentes.
• Correção de um bug em que a identidade do Proprietário da Análise era mostrada como Identidade Inativa.
• Corrigido o bug de loop infinito em CronScheduleJobExtension.

data de lançamento do Patch 1 da atualização 0.1 do Azure DevOps Server 2022: 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 Azure DevOps Server.
• CVE-2023-21569: Azure DevOps Server vulnerabilidade de falsificação.
• Correção de um bug com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é liberado no descarte do componente.
• Correção de um bug em que desanexar ou anexar coleção falha ao relatar o seguinte erro: 'TF246018: a operação de banco de dados excedeu o limite de tempo limite e foi cancelada.

Azure DevOps Server data de lançamento da Atualização 0.1 de 2022: 9 de maio de 2023

Azure DevOps Server 2022.0.1 é um acúmulo de correções de bugs. Ele inclui todas as correções no Azure DevOps Server RC 2022.0.1 lançado anteriormente. Você pode instalar diretamente Azure DevOps Server 2022.0.1 ou atualizar do Azure DevOps Server 2022 ou do 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 acúmulo 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 do Azure DevOps Server 2022 ou do Team Foundation Server 2015 ou mais recente.

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

• Atualização do GVFS (Git Virtual File System) de 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 build para evitar a criação de novos dados de teste órfãos.
• Atualizações ao AnalyticCleanupJob, o trabalho status foi Interrompido e agora relatamos Êxito.
• Correção do comando "tfx extension publish" com o erro "A chave fornecida não estava presente no dicionário".
• Implementou uma solução alternativa para resolver e erro ao acessar a extensão Calendário da Equipe.
• CVE-2023-21564: Azure DevOps Server vulnerabilidade de script entre sites
• CVE-2023-21553: Azure DevOps Server vulnerabilidade de execução remota de código
• As tarefas do MSBuild e do VSBuild foram atualizadas para dar suporte ao Visual Studio 2022.
• Atualize a metodologia de carregamento da reautenticação para evitar o vetor de ataque XSS.
• Azure DevOps Server Proxy 2022 relata o seguinte erro: VS800069: esse serviço só está disponível no Azure DevOps local.
• Correção do problema de acessibilidade de conjuntos de prateleiras por meio da interface do usuário da Web.
• Resolvido o problema que exigia a reinicialização do serviço tfsjobagent e Azure DevOps Server pool de aplicativos depois de atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Azure DevOps Server.
• As notificações não estavam sendo enviadas para PAT sete dias antes da data de validade.

data de lançamento do Patch 4 do Azure DevOps Server 2022: 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 Azure DevOps Server.
• CVE-2023-21569: Azure DevOps Server vulnerabilidade de falsificação.
• Correção de um bug com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é liberado no descarte do componente.
• Correção de um bug em que desanexar ou anexar coleção falha ao relatar o seguinte erro: 'TF246018: a operação de banco de dados excedeu o limite de tempo limite e foi cancelada.

data de lançamento do Patch 3 do Azure DevOps Server 2022: 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.

• Resolvido o problema que exigia a reinicialização do serviço tfsjobagent e Azure DevOps Server pool de aplicativos depois de 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 depois de 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 De entrega de preferência de equipe, os membros da equipe não receberão as notificações. Não é necessário expandir ainda mais as identidades na equipe para marcar as preferências dos membros.

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

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

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

data de lançamento do Patch 1 Azure DevOps Server 2022: 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 build para evitar a criação de novos dados de teste órfãos.
• Atualizações ao AnalyticCleanupJob, o trabalho status foi Interrompido e agora relatamos Êxito.
• Correção do comando "tfx extension publish" falhando com o erro "A chave fornecida não estava presente no dicionário".
• Implementou uma solução alternativa para resolver e erro ao acessar a extensão Calendário da Equipe.

Azure DevOps Server data de lançamento de 2022: 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 RC2 e RC1 de 2022 lançados anteriormente.

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

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

Observação

Novos algoritmos SSH RSA habilitados

O suporte à chave pública RSA foi aprimorado para dar suporte a tipos de chave pública SHA2, além do SHA1 SSH-RSA com suporte anterior.

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 o trabalho ao redor para habilitar o SSH-RSA especificando-o .ssh/config1 explicitamente no arquivo, você precisará remover o PubkeyAcceptedTypesou modificá-lo para usar RSA-SHA2-256 ou RSA-SHA2-512 ou ambos. Você pode encontrar detalhes sobre o que fazer se ainda for solicitado a fornecer 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 chaves elípticas ainda não foi adicionado e continua sendo um recurso altamente solicitado em nossa lista de pendências.

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

Resumo das novidades no Azure DevOps Server 2022

Importante

O Warehouse e o Analysis Service foram preteridos na versão anterior do Azure DevOps Server (2020). No Azure DevOps Server 2022, o Warehouse e o Analysis Service foram removidos do produto. A análise agora fornece a experiência de relatório 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 fork
• Novas páginas do TFVC
• Agrupar por marcas disponíveis em widgets de gráfico

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

• Boards
• Repos
• Pipelines
• Relatórios

---

Boards

Planos de entrega

Estamos entusiasmados em anunciar que os Planos de Entrega agora estão incluídos no Azure DevOps Server. Os Planos de Entrega fornecem três cenários principais:

• Uma visão da linha do tempo do plano
• Progresso do trabalho
• Acompanhamento de dependência

Abaixo estão os recursos de main. Filtragem, marcadores e critérios de campo também fazem parte dos Planos de Entrega.

Há dois modos de exibição main: condensados e expandidos

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

Há dois modos de exibição main o modo de exibição condensado e o modo de exibição expandido. Você também pode ampliar e reduzir o plano clicando na lupa no lado ight do plano.

Há dois modos de exibição main o modo de exibição condensado e o modo de exibição expandido. Você também pode ampliar e sair do plano clicando na lupa no lado direito do plano.

• Exibiçã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 de cartão são mostradas. Essa exibição é útil para uma exibição geral do trabalho no plano. Para recolher os campos cartão, clique no ícone cartão ao lado dos ícones de ampliação no lado direito do plano.

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

  

• Exibiçã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ídas.

  

Acompanhamento de dependência

O acompanhamento de dependências é baseado em links predecessores e sucessores que estão sendo definidos em itens de trabalho. Se esses links não forem 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 de vermelho.

• Exibindo dependências

  Dependências específicas são exibidas por meio do painel de dependência 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 de 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 direcional entre os respectivos itens de trabalho. Várias dependências serão exibidas como várias linhas. Uma linha colorida vermelha indica um problema.

  Aqui estão alguns exemplos.

  

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

  

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

  Veja um exemplo.

  

Estilo de cartão

Os cartões agora podem ser estilizados usando regras, como as placas 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

• After (após)

Para saber mais sobre os Planos de Entrega, marcar 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 dinâmicas e de filtro personalizadas 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 são mais de valor e não devem estar na lista de pendências. Neste sprint, ocultaremos todos os itens removidos dos modos de exibição Atribuídos a mim no Hub de Itens de Trabalho.

Exibir a persona correta em links de confirmação

A seção de desenvolvimento em um item de trabalho mostra a lista de confirmações relevantes e solicitações de pull. Você pode exibir o autor da solicitação de confirmação ou pull junto com a hora associada. Com essa atualização, corrigimos um problema com o avatar do autor sendo exibido incorretamente na exibiçã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 de itens de trabalho, mesmo depois que o anexo foi 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.

Adição do 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 consiste em 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 Não corrigirá o motivo 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 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 nenhum build ao atualizar, criaremos uma concessão para todos os builds existentes no momento da atualização que não têm uma concessão.

Recomendamos que você marcar 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 em seu 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 especiais de log e os executa. O setVariablecomando 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 de registro em log em seu pipeline. Com esta versão, estamos fazendo as seguintes alterações para reduzir o risco de usos indesejados do setVariable comando.

• Adicionamos um novo constructo para autores de tarefas. Ao incluir um snippet como o seguinte em 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 internas, como ssh, para que elas não possam ser exploradas.

• Por fim, agora você pode usar constructos 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 fork

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

Isso pode ser mais restritivo do que o desejado nesses ambientes fechados, em que 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 fornecendo controle para gerar um token de acesso de trabalho regular, mesmo para builds 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 os repositórios e pipelines do Git do Azure, não havia experiência para gerenciá-lo. Esse recurso resolve essa lacuna. Os repositórios Git do Azure agora podem ser tratados como recursos protegidos em pipelines YAML, assim como conexões de serviço e pools de agentes.

Como contribuidor do repositório A, você pode adicionar verificações e permissões de pipeline ao repositório. Para fazer isso, navegue até as configurações do projeto, selecione Repositórios e, em seguida, seu repositório. Você observará um novo menu chamado "Verificações", no qual você pode configurar qualquer uma das verificações personalizadas ou in-the-box 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ó são aplicáveis 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. Exemplos incluem conexões de serviço, grupos de variáveis, arquivos seguros, pools de agentes, ambientes ou repositórios. Para proteger um pipeline contra o acesso a 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 é executado, use o recurso Aprovações e verificações de 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 seguintes fluxos, o Azure Pipelines sabe sobre o usuário que está executando 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 está executando a operação. Portanto, ele cria o ambiente e adiciona o usuário à função de administrador para o 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 seguintes fluxos, 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 como conceder permissões de administrador em um ambiente a todos os membros de um projeto. Conforme ouvimos seus comentários, ouvimos que não devemos criar automaticamente um ambiente se não estiver claro quem é o usuário que está executando a operação. Com esta versão, fizemos alterações na forma como os ambientes serão criados automaticamente:

• Daqui para frente, 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 certa e verificar a configuração antes de usá-los em um pipeline.
• Pipelines com contexto de usuário conhecido ainda criarão ambientes automaticamente, assim como fizeram no passado.
• Por fim, deve-se observar que o recurso para criar automaticamente um ambiente só foi adicionado para simplificar o processo de introdução ao Azure Pipelines. Destinava-se a cenários de teste e não a cenários de produção. Você sempre deve pré-criar ambientes de produção com as permissões e verificações corretas e usá-los em pipelines.

Remover o diálogo insights do Pipeline de Build

Com base em seus comentários, a caixa de diálogo Insights de tarefa/pipeline exibida ao navegar pelo 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 somente 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 é um marcar de bloqueio exclusivo. Esse marcar permite que apenas uma única execução do pipeline continue. Quando várias execuções tentam implantar em um ambiente ao mesmo tempo, o marcar 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 das 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 implantem 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 ao recurso protegido. Um valor de runLatest implica que apenas 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, será considerado 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 de uma extensão no Azure DevOps. Agora atualizamos o aplicativo para trabalhar com a versão quebec do ServiceNow. 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) do repositório Service Now. Para obter mais informações, consulte Integrar com o ServiceNow Change Management.

Novas expressões condicionais YAML

A gravação de expressões condicionais em arquivos YAML ficou mais fácil com o uso de ${{ else }} expressões e ${{ 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 branches 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 src/app/**/myapp*a . Isso foi apontado como um inconveniente por vários clientes. Essa atualização preenche essa lacuna. Agora, você pode usar caracteres cartão selvagens (**, *ou ?) ao especificar filtros de caminho.

A especificação de agente padrão 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 no Azure Pipelines. Até agora, esse rótulo apontava para os agentes do windows-2019. Essa alteração 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-la como a 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, marcar aqui.

A renomeação de pasta de pipeline valida permissões

As pastas que contêm pipelines podem ser renomeados. Renomear uma pasta 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 Agente de Pipeline do Azure DevOps é o produto de software executado em um host de pipeline para executar trabalhos de pipeline. Ele é executado em agentes hospedados da Microsoft, agentes do Conjunto de Dimensionamento e agentes auto-hospedados. No último caso, instale-o por conta própria. O Agente de Pipeline consiste em um Ouvinte e um Trabalho (implementados no .NET), o Trabalho executa tarefas que são implementadas no Node ou no PowerShell e, portanto, hospeda esses runtimes para eles.

Atualização futura para o .NET 6 & substituição do Red Hat 6

Com o lançamento do .NET 6 , podemos aproveitar seus novos recursos multiplataforma. 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 Trabalho) nos próximos meses.

Devido a várias restrições que isso impõe, estamos descartando o suporte do Red Hat Enterprise Linux 6 de nosso agente em 30 de abril de 2022.

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

Estamos lançando uma nova versão da tarefa Cópia de Arquivo do Azure. Essa tarefa é usada para copiar arquivos para blobs de armazenamento do Microsoft Azure ou VMs (máquinas virtuais). A nova versão tem várias atualizações que geralmente foram 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 com suporte, 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 limpo o destino quando o tipo de destino for Blob do Azure. Definir essa 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 do 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 essa tarefa. Você precisaria 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 os pipelines que ainda dependem dos módulos do AzureRM.

Novos pontos de extensão para a exibição de detalhes de 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 vss-extension.json Azure DevOps.

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ê precisa considerar que o 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 de repositório de um build.

Modelos de Pipelines YAML estendidos agora podem ser passados 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 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 para melhorar a segurança de seus pipelines

• Seu modelo usa como parâmetro uma lista de stages, jobsou 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

Vamos examinar um exemplo. Digamos que você esteja criando um pipeline que executa testes de ponta a ponta para validação de solicitação de pull. Sua meta é 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 você precise especificar seu comportamento.

Você percebe que outras equipes terão necessidades semelhantes, portanto, você decide extrair as etapas para configurar o ambiente em um modelo. Seu código se parece com o 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 é que, 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

Esse 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 o dimensionsapi código HTTP de retorno 200, enquanto negative_test espera que ele retorne o código HTTP 500.

Conta de serviço gerenciada 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 de senha centralizado para contas de domínio que atuam como contas de serviço. O Agente do Azure Pipelines pode reconhecer esse tipo de conta para que uma senha não seja 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 execução se parece com a seguinte.

O Azure DevOps recupera o código-fonte de um pipeline YAML em resposta a eventos externos, por exemplo, um commit enviado por push ou em resposta a gatilhos internos, por exemplo, para marcar se houver 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 Build está obsoleta

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

Repos

Novas páginas do 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 mais acessível entre os vários serviços. As páginas do TFVC foram atualizadas para usar a nova plataforma Web. Com essa versão, estamos disponibilizando as novas páginas TFVC 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, talvez você queira fazer isso quando:

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

Nesses casos, talvez você queira desabilitar temporariamente o repositório enquanto trabalha para resolve o problema. Com essa atualização, você poderá desabilitar um repositório se tiver permissões excluir 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 tentar 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, acesse Configurações do Projeto, selecione Repositórios e, em seguida, o repositório específico.

Configurar criadores de branch para não obter "Gerenciar permissões" em seus branches

Ao criar um 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 esse branch. 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 determinados projetos com requisitos de conformidade mais altos, os usuários não devem ser capazes de fazer essas alterações.

Com essa atualização, você pode configurar todo e qualquer repositório em seu projeto de equipe e restringir os criadores de branch de obter a permissão "Gerenciar permissões". Para fazer isso, navegue até as configurações do projeto, selecione Repositórios e 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. Porém, você pode desativá-lo se quiser usar esse novo recurso de segurança.

Impedir que os usuários de bifurcação votem em seus PRs de 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 na bifurcação. Para enviar uma solicitação de pull com suas alterações no upstream, os usuários precisam de 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 contribuidor para o repositório, pode enviar uma solicitação de pull e fazer com que ela seja mesclada dependendo de como você configurou as políticas de branch.

Em projetos que promovem um modelo de origem interna, fork-and-contribute é um padrão comum. Para proteger e promover ainda mais esse padrão, estamos alterando a permissão para votar em um pull request 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 em Azure Repos.

Relatórios

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

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

Exibir tipos de item de trabalho personalizados no widget burndown

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

---

Comentários

Adoraríamos ouvir sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo por meio de Developer Community e obter conselhos sobre o Stack Overflow.

---

Parte superior da página