Notas de versão do Azure DevOps Server 2022

| Comunidade de Desenvolvedores | Requisitos de Sistema e Compatibilidade | Termos de Licença | Blog de DevOps | SHA-256 Hashes |

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 do Azure DevOps Server, consulte Azure DevOps Server Requirements.

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

A atualização direta para o Azure DevOps Server 2022 é suportada pelo Azure DevOps Server 2019 ou Team Foundation Server 2015 ou mais recente. Se sua 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 Instalação para obter mais informações.

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

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

• Estendida a lista de caracteres permitidos para argumentos de tarefas do PowerShell em , habilitando a validação de parâmetros para tarefas do shell.
• Corrija um problema que fazia com que as alterações nas conexões de serviço permanecessem mesmo 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

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

• Corrigida uma falha que fazia os pipelines ficarem presos ao atualizar o modelo de execução.
• Corrigido um bug em que a identidade "Analysis Owner" 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 elimina um artefato de uma compilação. Se alguma dessas tarefas falhar, nenhuma das tarefas subsequentes foi 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 Patch 3 Data de lançamento: 12 de setembro de 2023

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

• CVE-2023-33136: Vulnerabilidade de execução remota de código 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 o Azure DevOps Server 2022 Update 0.1 que inclui correções para o seguinte.

• CVE-2023-36869: Vulnerabilidade de spoofing do servidor Azure DevOps.
• Corrigido um bug em chamadas SOAP em que ArithmeticException pode ser gerado para resposta XML de grandes metadados.
• Alterações implementadas no editor de conexões de serviço para que o estado do ponto de extremidade seja liberado ao descartar componentes.
• Foi resolvido um problema com ligações relativas que não funcionavam em ficheiros de markdown.
• Corrigido um problema de desempenho relacionado à camada de aplicativo que levava mais tempo do que o normal para a inicialização quando há um grande número de tags definidas.
• Foram corrigidos erros de TF400367 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 erro de loop infinito na extensão CronScheduleJob.

Azure DevOps Server 2022 Atualização 0.1 Patch 1 Data de lançamento: 13 de junho de 2023

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

• CVE-2023-21565: Vulnerabilidade de falsificação do servidor Azure DevOps.
• CVE-2023-21569: Vulnerabilidade de falsificação do servidor Azure DevOps.
• Corrigido um bug com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é limpo quando o componente é dispensado.
• Corrigido um bug em que desanexar ou anexar a coleção falhava 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 Atualização 0.1 Data de lançamento: 9 de maio de 2023

O 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 o Azure DevOps Server 2022.0.1 ou atualizar do 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

O 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 o Azure DevOps Server 2022.0.1 ou atualizar do Azure DevOps Server 2022 ou Team Foundation Server 2015 ou mais recente.

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

• Atualizado o Git Virtual File System (GVFS) para a versão v2.39.1.1-microsoft.2 para corrigir uma vulnerabilidade de segurança.
• Os dados de teste não estavam sendo excluídos, fazendo com que o banco de dados crescesse. Com esta correção, atualizamos a retenção da build para evitar a geração de novos dados de teste isolados.
• Atualizações no AnalyticCleanupJob, o estado da tarefa estava Parado e agora está reportado como Concluído com sucesso.
• Foi corrigido o comando "tfx extension publish" que falhava com o erro "A chave dada não estava presente no dicionário".
• Implementada uma solução alternativa para corrigir um erro ao aceder à extensão de Calendário de Equipa.
• 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 MSBuild e VSBuild atualizadas para dar suporte ao Visual Studio 2022.
• Atualizar metodologia de carregamento de reautenticação para evitar vetor de ataque XSS.
• O Proxy do Azure DevOps Server 2022 relata o seguinte erro: VS800069: Este serviço só está disponível no Azure DevOps local.
• Corrigido problema de acessibilidade de shelvesets via interface web.
• Foi resolvido um problema que exigia reiniciar o serviço tfsjobagent e o pool de aplicativos do Azure DevOps Server após atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Servidor de DevOps do Azure.
• As notificações não estavam a ser enviadas para PAT sete dias antes da data de validade.

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

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

• CVE-2023-21565: Vulnerabilidade de falsificação do servidor Azure DevOps.
• CVE-2023-21569: Vulnerabilidade de falsificação do servidor Azure DevOps.
• Corrigido um bug com o editor de conexões de serviço. Agora, o estado do ponto de extremidade de rascunho é limpo quando o componente é dispensado.
• Corrigido um bug em que desanexar ou anexar a coleção falhava 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 Patch 3 Data de lançamento: 21 de março de 2023

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

• Foi resolvido um problema que exigia reiniciar o serviço tfsjobagent e o pool de aplicativos do Azure DevOps Server após atualizar a configuração relacionada ao SMTP no Console de Gerenciamento do Servidor de DevOps do Azure.
• Copie o estado do Endpoint para o painel de edição do Endpoint de Serviço em vez de o passar por referência.
• Anteriormente, ao editar conexões de serviço, as edições eram persistentes na interface do usuário depois de selecionar o botão cancelar. Com este patch, corrigimos no SDK de notificações quando uma equipa tem a entrega de notificações 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 há necessidade de expandir ainda mais as identidades sob a equipe para verificar as preferências dos membros.

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

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

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

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

Lançámos um patch para o 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 esta correção, atualizamos a retenção da build para evitar a geração de novos dados de teste isolados.
• Atualizações no AnalyticCleanupJob, o estado da tarefa estava Parado e agora está reportado como Concluído com sucesso.
• Corrigido o comando "tfx extension publish" falhando com o erro "A chave dada não estava presente no dicionário".
• Implementada uma solução alternativa para corrigir um erro ao aceder à extensão de Calendário de Equipa.

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

O 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

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

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

Os tipos de chave pública agora suportados incluem:

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

Ação Necessária

Se você implementou a solução alternativa para habilitar 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 chaves 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 do que há de novo no Azure DevOps Server 2022

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

• Planos de Entrega
• Exibir a persona correta nos links de confirmação
• Novos controles para variáveis de ambiente em pipelines
• Gerar token irrestrito para compilações de fork
• Novas páginas TFVC
• Agrupar por tags 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:

• Painéis
• Repos
• Pipelines
• Elaboração de Relatórios

Conselhos

Planos de Entrega

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

• Uma visão do cronograma do plano
• Evolução dos trabalhos
• Rastreamento 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.

Há duas visões principais: condensada e expandida

O Delivery Plans 2.0 permite visualizar todos os itens de trabalho do seu plano em uma linha do tempo, usando datas de início e de destino ou datas de iteração. A ordem de precedência é início e datas de destino seguidas de iteração. Isso permite que você adicione itens de trabalho de nível de portfólio como Epic, que muitas vezes não são definidos para uma iteração.

Existem duas vistas principais: a vista condensada e a vista expandida. Você também pode aumentar e diminuir o zoom do plano clicando na lupa à direita do plano.

Existem duas vistas principais: a vista condensada e a vista expandida. Você também pode aumentar e diminuir o zoom do plano clicando na lupa no lado direito do plano.

• Vista 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. Esta vista é útil para uma visão global do trabalho no plano. Para recolher os campos do cartão, clique no ícone do cartão junto aos ícones de lupa no lado direito do plano.

  Aqui está um exemplo de um plano alternando entre as visualizações condensada e expandida.

  

• Vista expandida

  O modo de exibição expandido 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.

  

Rastreamento de dependência

O rastreamento de dependência baseia-se em links de predecessores e sucessores definidos nos 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 do link de dependência é colorido em vermelho.

• Exibindo dependências

  As dependências específicas são visualizadas através do painel de dependências que mostra todas as dependências para esse 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 respetivos itens de trabalho. Várias dependências serão exibidas como várias linhas. Uma linha de cor vermelha indica um problema.

  Eis alguns exemplos.

  

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

  

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

  Aqui está 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, em seguida, clique em Guardar. Pode haver até 10 regras e cada regra pode ter até 5 cláusulas.

• Antes

• Depois

Para saber mais sobre os Planos de Entrega, consulte 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 separador Atribuído a mim é que ele exibe itens de trabalho que foram 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 visualizações Atribuído a mim no Hub Itens de Trabalho.

Exibir a persona correta nos links de confirmação

A seção de desenvolvimento em um item de trabalho mostra a lista de confirmações relevantes e solicitações pull. Você pode visualizar o autor da solicitação commit ou pull junto com o tempo associado. Com esta 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 podiam baixar anexos do histórico de itens de trabalho, mesmo depois que o anexo era removido do formulário. Agora, uma vez que o anexo é removido, ele não pode ser baixado do histórico, nem o URL de download estará disponível a partir da resposta da API REST.

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

Como em 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. As razões especificam por que o item transitou de um Estado para outro. Com esta atualização, adicionámos um valor de motivo "Will not fix" para os tipos de item de trabalho Bug no processo Agile. O valor será utilizável como justificativa ao mover erros de "Novo" ou "Ativo" para "Resolvido". Você pode saber mais sobre como definir, capturar, triar e gerenciar bugs de software na documentação do Azure Boards.

Tubulações

Remoção de políticas de retenção por pipeline em compilações clássicas

Agora você pode configurar políticas de retenção para compilações clássicas e pipelines YAML nas configurações do projeto Azure DevOps. As regras de retenção por pipeline para pipelines de compilação clássicos não são mais suportadas. 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 compilação clássicos por pipeline. Removeremos todas as regras de retenção por pipeline para pipelines de compilação clássicos numa versão futura.

O que isso significa para você: qualquer pipeline de compilação 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 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 sobre definir políticas de retenção para compilações, lançamentos 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 setVariablecomando pode ser usado para definir uma variável ou modificar uma variável previamente definida. Isto pode ser potencialmente explorado por um interveniente externo ao 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.

• Adicionámos uma nova estrutura para autores de tarefas. Ao incluir um trecho 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 uma série de tarefas internas, como ssh, para que elas não possam ser exploradas.

• Finalmente, 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 sem restrições para compilações 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 a partir de uma bifurcação de um repositório do GitHub Enterprise, ele restringe as permissões concedidas ao token de acesso ao trabalho e não permite que segredos do pipeline sejam acessados por esses trabalhos. Você pode encontrar mais informações sobre a segurança da construção de garfos em nossa documentação.

Isso pode ser mais restritivo do que o desejado nesses 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 ramificações, não há nenhuma configuração para controlar o escopo do token de acesso a tarefas. Com esta versão, estamos dando a você controle para gerar um token de acesso a trabalho regular, mesmo para compilações de forks.

Você pode alterar esta 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.

Repos como um recurso protegido em pipelines YAML

Você pode organizar seu projeto de DevOps do Azure para hospedar muitos subprojetos - cada um com seu próprio repositório Git do Azure DevOps e um ou mais pipelines. Nessa estrutura, convém 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 constroem esses repositórios. Você pode querer 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. Este 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 contribuidor 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 pode configurar qualquer uma das verificações padrão 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 satisfeitas.

Permissões e verificações em grupos 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 aceder a um recurso, o proprietário do recurso pode configurar permissões e verificações sobre esse recurso. Sempre que um pipeline tenta acessar o recurso, todas as permissões e verificações configuradas são avaliadas. Há algum tempo, essas proteções têm estado disponíveis em conexões de serviço, ambientes e pools de agentes. Eles foram recentemente adicionados aos repositórios. Com esta versão, estamos adicionando as mesmas proteções para grupos 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, utilize a funcionalidade Aprovações e verificações para Biblioteca.

Mudanças 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 faz referência a um ambiente que ainda não foi criado.
• Você atualiza o arquivo YAML usando o editor da Web do Azure Pipelines e salva 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. Assim, ele cria o ambiente e adiciona o usuário à função de administrador para o ambiente. Este usuário tem todas as permissões para gerenciar o ambiente e/ou para 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 faz com que um pipeline de integração contínua seja acionado. Nesse caso, o Azure Pipelines não sabe sobre o usuário. Anteriormente, tratamos desse caso adicionando todos os colaboradores do projeto à função de administrador do ambiente. Desta forma, qualquer membro do projeto podia alterar estas permissões e impedir que outras pessoas acedessem ao ambiente.

Recebemos seus comentários sobre a concessão de permissões de administrador em um ambiente a todos os membros de um projeto. Enquanto ouvíamos seus comentários, ouvimos que não deveríamos 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 na forma 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 de ambiente não encontrado. Você precisa pré-criar os ambientes com a segurança certa e verificar a configuração antes de usá-lo em um pipeline.
• Os pipelines com contexto de usuário conhecido ainda criarão automaticamente ambientes como faziam no passado.
• Por fim, deve-se notar 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ê 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 fluxo de compilação

Baseado no vosso feedback, a caixa de diálogo Insights de tarefa/pipeline que aparecia ao navegar no pipeline de construção foi removida para melhorar o fluxo de trabalho. As análises de pipeline ainda estão disponíveis para que você tenha os insights de que precisa.

Suporte para implantações sequenciais em vez das mais recentes, apenas quando se usam verificações de bloqueio exclusivas.

Nos pipelines YAML, as verificações são usadas para controlar a execução de etapas 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, existem 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 de 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 apenas a última execução adquire o bloqueio para o recurso.

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

1. Ative a verificação exclusiva de bloqueio no ambiente (ou em outro recurso protegido).
2. No arquivo YAML para o pipeline, especifique uma nova propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para um determinado estágio:

Encenado num palco:

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

Configurado na linha de produção.

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 de uma extensão no Azure DevOps. Agora atualizamos o aplicativo para funcionar com a versão Quebec do ServiceNow. Tanto os dutos clássicos quanto os 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 ServiceNow Change Management.

Novas expressões condicionais YAML

Escrever expressões condicionais em arquivos YAML ficou mais fácil com o uso de ${{ else }} e ${{ elseif }} expressões. 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 coringas nos filtros de percursos

Os caracteres universais podem ser usados ao especificar ramificações de inclusão e exclusão para gatilhos de CI ou PR em um ficheiro YAML de pipeline. No entanto, eles não podem ser usados ao especificar filtros de caminho. Por exemplo, não é possível incluir todos os caminhos que correspondem ao src/app/**/myapp*. Isso tem sido apontado como um inconveniente por vários clientes. Esta atualização preenche esta lacuna. Agora, você pode usar caracteres curinga (**, *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 para o windows-latest rótulo nos agentes do Azure Pipelines hospedados pela Microsoft. Até agora, este rótulo apontava para os agentes do Windows-2019. Esta alteração será implementada ao longo de um período de várias semanas a partir de 17 de janeiro. Pretendemos concluir a migração até março.

O Azure Pipelines tem suporte windows-2022 desde setembro de 2021. Monitorizamos o seu feedback 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.

O renomear da pasta de Pipeline valida as permissões

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

Planeamento de atualização do runtime do Pipelines Agent

O que é o Pipeline Agent?

O Agente de Pipeline do Azure DevOps é o produto de software que é executado num host de pipeline para executar tarefas de pipeline. Ele é executado em agentes hospedados pela Microsoft, agentes Scale set e agentes auto-hospedados. Neste último caso, você mesmo o instala. O Agente de Pipeline consiste numa Listener e num Worker (implementados em .NET), o Worker executa tarefas que são implementadas em Node.js ou PowerShell e, portanto, hospeda esses ambientes de execução para elas.

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

Com o lançamento do .NET 6 , podemos tirar proveito de seus novos recursos multiplataforma. Especificamente, seremos capazes de fornecer compatibilidade nativa para Apple Silicon e Windows Arm64. Por isso, planeamos mudar para o .NET 6 para o Pipeline Agent (Listener e Worker) nos próximos meses.

Devido a uma série de restrições impostas, vamos descontinuar o suporte ao Red Hat Enterprise Linux 6 no nosso agente a partir de 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 de Cópia de Arquivo do Azure. Esta tarefa é usada para copiar arquivos para blobs de armazenamento do Microsoft Azure ou máquinas virtuais (VMs). 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 o Blob do Azure. Definir essa opção excluirá todas as pastas/arquivos desse 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 as suas 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 depende dos módulos do AzureRM.

Novos Pontos de Extensão para Visualização de Detalhes de Pipelines

Adicionamos dois novos pontos de extensibilidade que você pode segmentar 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 do pipeline:

• Botão personalizado no cabeçalho do pipeline: ms.vss-build-web.pipelines-header-menu
• Menu personalizado numa pasta do 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 numa pasta de canalização

  

Migração melhorada para os Serviços de DevOps do Azure

Ao executar uma importação do Servidor de DevOps do Azure para os Serviços de DevOps do Azure, você precisa considerar que o Azure DevOps não oferece mais suporte a regras de retenção por pipeline. Com esta atualização, removemos essas políticas quando você migra para os Serviços de DevOps do Azure do seu Servidor de DevOps do Azure 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 compilações, versões e testes.

Melhoria para pipelines executa API REST

Anteriormente, a API REST Pipelines Runs retornava apenas o self repositório. Com essa atualização, a API REST Pipelines Runs retorna todos os recursos do repositório de uma compilação.

Os modelos de pipelines estendidos do YAML agora podem receber informações de contexto para estágios, tarefas e implementações.

Com esta atualização, estamos adicionando uma nova templateContext propriedade para job, deploymente stage componentes de pipeline 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 tarefa é executada ou adiciona etapas adicionais para impor a conformidade

• O processamento requer informações adicionais para serem fornecidas pelo autor do pipeline no modelo para cada estágio, trabalho ou implementaçã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 pull. Seu objetivo é testar apenas um componente do seu sistema, mas, como você planeja executar testes de ponta a ponta, você precisa de um ambiente onde mais componentes do sistema estejam disponíveis e você 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 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 é, para cada trabalho no testSet parâmetro, definir a resposta dos componentes do sistema especificados por ${{ testJob.templateContext.requiredComponents }} para retornar ${{ testJob.templateContext.expectedHTTPResponseCode }}.

Em seguida, pode criar o seu próprio pipeline que amplia testing-template.yml, como no exemplo seguinte.

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 o retorno do código HTTP 200, enquanto dimensionsapi espera o retorno do 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 de Pipelines do Azure 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>

Corridas informativas

Uma execução informativa informa que o Azure DevOps não conseguiu recuperar o código-fonte de um pipeline YAML. Tal corrida se parece com o seguinte.

O Azure DevOps recupera o código-fonte de um pipeline YAML em resposta a eventos externos, por exemplo, uma confirmação enviada, 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 esta etapa falha, o sistema cria uma execução informativa. Essas execuções sã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:

• Provedor de repositório enfrentando uma interrupção
• Controlo do fluxo de pedidos
• Problemas de autenticação
• Não é possível recuperar o conteúdo do arquivo .yml do pipeline

Leia mais sobre Testes informativos.

A propriedade Build Definition REST API retentionRules está obsoleta

No tipo de resposta da API REST de definição de compilação, a propriedade é agora considerada BuildDefinition obsoleta, pois essa propriedade sempre retorna conjunto vazio.

Repos

Novas páginas TFVC

Temos vindo a atualizar várias páginas no Azure DevOps para utilizar 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 TFVC foram atualizadas para utilizar a nova plataforma web. Com esta versão, estamos disponibilizando as novas páginas TFVC para o público em geral.

Desativar um repositório

Os clientes muitas vezes solicitaram uma maneira de desativar 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, convém desativar temporariamente o repositório enquanto resolves o problema. Com esta atualização, você pode desativar um repositório se tiver permissões Excluir repositório . Ao desativar 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
• Ver uma mensagem informando que o repositório foi desabilitado quando eles tentam acessá-lo na interface do usuário do Azure Repos

Após as etapas de mitigação necessárias terem sido tomadas, os usuários com permissão Excluir repositório podem reativar o repositório. Para desativar 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 ramos para que não tenham "Manage permissions" nos seus ramos

Ao criar uma nova ramificação, você obtém "Gerenciar permissões" nessa ramificação. 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 filial 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 construção) possa alterar o código nessa ramificação. Em certos projetos com requisitos de conformidade mais elevados, os utilizadores não devem poder efetuar essas 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 ramificações 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 quiser fazer uso deste novo recurso de segurança.

Impedir que os utilizadores de forks votem nos respetivos PRs de origem

Com o 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 um pull request com as suas alterações para o upstream, os utilizadores precisam da permissão para "contribuir para pull requests" no upstream. No entanto, essa permissão também rege quem pode votar em solicitações 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 pull e fazer com que ela seja mesclada, dependendo de como você configurou as políticas de ramificação.

Em projetos que promovem um modelo de fonte 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 uma solicitação pull de "contribute to pull requests" para "contribute". No entanto, essa alteração não está sendo feita por padrão em todos os projetos. Você tem que inscrever-se e selecionar uma nova política no seu repositório, chamada "Modo Estrito de Votação", para mudar essa permissão. Recomendamos que o faça se depender de forks no Azure Repos.

Elaboração de Relatórios

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, não era possível ver os tipos personalizados de itens de trabalho configurados no widget de burn down 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

Gostaríamos muito de ouvir a sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo através da Comunidade de Desenvolvedores e obter conselhos no Stack Overflow .