Notas de versão do Azure DevOps Server 2019

| Developer Community System Requirements | License Terms | DevOps Blog | SHA-1 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, consulte Requisitos de Azure DevOps Server. Para baixar produtos do Azure DevOps, visite a página Azure DevOps Server Downloads.

Há suporte para a atualização direta para Azure DevOps Server 2020 do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para o Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps localmente.

---

Atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020

Azure DevOps Server 2020 introduz um novo modelo de retenção de execução de pipeline (build) que funciona com base nas configurações de nível de projeto.

Azure DevOps Server 2020 lida com a retenção de build de forma diferente, com base em políticas de retenção no nível do pipeline. Determinadas configurações de política levam à exclusão de execuções de pipeline após a atualização. As execuções de pipeline que foram retidas manualmente ou retidas por uma versão não serão excluídas após a atualização.

Leia nossa postagem no blog para obter mais informações sobre como atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020.

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 12: 26 de janeiro de 2022

Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.

• Resolvido a vulnerabilidade do Elasticsearch removendo a classe jndilookup dos binários log4j.

Etapas de instalação

1. Atualize o servidor com o Patch 12.
2. Verifique o valor do Registro em HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1).
3. Execute o comando PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update update conforme fornecido no arquivo readme. Ele pode retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização está executando novas tentativas até que ela seja concluída.

Observação

Se Azure DevOps Server e Elasticsearch estiverem instalados em computadores diferentes, siga as etapas descritas abaixo.

1. Atualize o servidor com o Patch 12.
2. Verifique o valor do Registro em HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1).
3. Copie o conteúdo da pasta chamada zip, localizada na C:\Program Files\{TFS Version Folder}\Search\zip pasta de arquivo remoto Elasticsearch.
4. Execute Configure-TFSSearch.ps1 -Operation update no computador do servidor Elasticsearch.

HASH SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 11: 10 de agosto de 2021

Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.

• Correção do erro de interface do usuário da definição de build.

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 10: 13 de abril de 2021

Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.

• CVE-2021-27067: Divulgação de informações

Para aplicar o Patch 10, você precisará instalar a AzureResourceGroupDeploymentV2 tarefa.

Instalação da tarefa AzureResourceGroupDeploymentV2

Observação

Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows

Instalar

1. Extraia o pacoteAzureResourceGroupDeploymentV2.zip para uma nova pasta no computador. Por exemplo: AzureResourceGroupDeploymentV2.

2. Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) de acordo com seu computador.

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso completo e copie-o. Esse token de acesso pessoal será usado ao executar o comando de logon tfx .

5. Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o token de acesso pessoal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Execute o comando a seguir para carregar a tarefa no servidor. Use o caminho do arquivo .zip extraído da etapa 1.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 9: 8 de dezembro de 2020

Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• CVE-2020-1325: vulnerabilidade de falsificação de Azure DevOps Server
• CVE-2020-17135: vulnerabilidade de falsificação de Azure DevOps Server
• CVE-2020-17145: vulnerabilidade de falsificação do Azure DevOps Server e do Team Foundation Server
• Corrigir o problema com o TFVC não processando todos os resultados

Importante

Leia as instruções completas fornecidas abaixo antes de instalar este patch.

Instalação de patch geral

Se você tiver Azure DevOps Server 2019.0.1, instale Azure DevOps Server Patch 9 2019.0.1.

Verificando a instalação

• Opção 1: Executar devops2019.0.1patch9.exe CheckInstall, devops2019.0.1patch9.exe é o arquivo baixado do link acima. A saída do comando dirá que o patch foi instalado ou que não está instalado.

• Opção 2: verifique a versão do seguinte arquivo: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. Azure DevOps Server 2019 é instalado c:\Program Files\Azure DevOps Server 2019 no por padrão. Depois de instalar Azure DevOps Server Patch 9 2019.0.1, a versão será 17.143.30723.4 .

Instalação da tarefa AzurePowerShellV4

Observação

Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows

Pré-requisitos

1. Instale Azure PowerShell módulo Az do Azure Powershell no computador do agente privado.

2. Crie um pipeline com a tarefa AzurePowerShellV4 . Você verá apenas uma Falha no Erro Padrão na tarefa.

Instalar

1. Extraia o pacoteAzurePowerShellV4.zip para uma pasta chamada AzurePowerShellV4.

2. Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) de acordo com seu computador.

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso completo e copie-o. Esse token de acesso pessoal será usado ao executar o comando de logon tfx .

5. Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o token de acesso pessoal.

~$ tfx login
Copyright Microsoft Corporation

> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully

6. Execute o comando a seguir para carregar a tarefa no servidor. O caminho do pacote extraído será D:\tasks (1)\AzurePowerShellv4.

  ~$ tfx build tasks upload --task-path *<Path of the extracted package>*

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 8: 8 de setembro de 2020

Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• DTS 1713492 – comportamento inesperado ao adicionar grupos do AD a permissões de segurança.

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 7: 14 de julho de 2020

Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• CVE-2020-1326: Vulnerabilidade de script entre sites
• O pipeline de build mostra a conexão incorreta para usuários não autorizados ao selecionar Outra origem do Git.
• Corrija o erro ao alterar a herança para Ativar ou Desativar na definição de build XAML.

Azure DevOps Server data de lançamento do Patch 6 de 2019.0.1: 10 de junho de 2020

Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• CVE-2020-1327: garantir que Azure DevOps Server sanibilize as entradas do usuário
• Adicionando suporte para SHA2 no SSH no Azure DevOps

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 5: 10 de março de 2020

Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.

• CVE-2020-0700: vulnerabilidade de script entre sites
• CVE-2020-0758: Vulnerabilidade de elevação de privilégio
• CVE 2020-0815: Vulnerabilidade de elevação de privilégio

data de lançamento do Patch 3 do Azure DevOps Server 2019.0.1: 10 de setembro de 2019

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige os seguintes bugs. Confira a postagem no blog para saber mais.

• CVE-2019-1305 : vulnerabilidade XSS (cross site scripting) no Repos
• CVE-2019-1306 : vulnerabilidade de execução de código remoto no Wiki

---

data de lançamento do Patch 2 do Azure DevOps Server 2019.0.1: 13 de agosto de 2019

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte bug. Confira a postagem no blog para saber mais.

• Adicionamos informações às conexões de serviço para esclarecer que elas são autorizadas para todos os pipelines por padrão.

---

data de lançamento do Patch 1 do Azure DevOps Server 2019.0.1: 9 de julho de 2019

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige os seguintes bugs. Confira a postagem no blog para saber mais.

• CVE-2019-1072 : Vulnerabilidade de execução de código remoto no acompanhamento de item de trabalho
• CVE-2019-1076 : Vulnerabilidade XSS (Cross Site Scripting) em solicitações de pull

---

data de lançamento do Azure DevOps Server 2019.0.1: 21 de maio de 2019

Azure DevOps Server 2019.0.1 é um acúmulo de correções de bugs. Ele inclui todas as correções nos patches do Azure DevOps Server 2019 lançados anteriormente. Você pode instalar diretamente Azure DevOps Server 2019.0.1 ou atualizar do Azure DevOps Server 2019 ou do Team Foundation Server 2012 ou mais recente.

Observação

A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 2019.0.1 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

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

Azure Boards

• "Os critérios de campo para este plano têm um erro" ao configurar um Plano. Relatado por meio de Developer Community.
• apiwitcontroller.executequery gera uma exceção quando uma consulta tem a mesma coluna várias vezes.
• No modelo de objeto do cliente usando o escopo vso.work_full oauth, WorkItemServer.DownloadFile() falha.
• Copiar uma imagem inserida de um campo de item de trabalho para outro campo de item de trabalho em um projeto diferente pode criar uma imagem quebrada.

Azure Repos

• "TF401019: GitRepositoryNotFoundException".

Azure Pipelines

• A guia Análise de Teste tem um star (*) que indica a versão prévia, mesmo que esse recurso não esteja em versão prévia.
• Na guia Versões , a ação para gerenciar a segurança agora é mostrada a todos os usuários, independentemente de eles poderem alterar as permissões ou não.
• Nas páginas de aterrissagem versões, a ação iniciar versão de rascunho estava criando uma nova versão, mas agora inicia a versão de rascunho.

Azure Test Plans

• O filtro de 1 hora em TestRuns e TestResults CompletedDate é muito granular.
• No tipo de item de trabalho Caso de Teste , o tipo "Caso de Teste" não deve ser localizado.
• Os casos de teste não aparecem no MTM ou em um navegador.
• Erro "Estágio de validação: você não tem permissão para disparar versões no pipeline de lançamento associado" ao executar testes automatizados de um Plano de Teste. Relatado por meio de Developer Community.
• Usando a API de exclusão de caso de teste, os casos de teste podem ser excluídos de outros projetos. Relatado por meio de Developer Community.
• Clicar em um link de item de trabalho no Test Runner abre a URL do item de trabalho dentro do Test Runner em vez do navegador padrão.
• O caso de teste status não está sendo atualizado para os usuários que saem do Test Runner.
• O nome de usuário e o endereço de email não são mostrados na lista suspensa do usuário no Executor de Teste.

Azure Artifacts

• Mover para cima e Mover para baixo não são localizados em Upstreams.

Análise

• Os relatórios de análise podem mostrar dados incompletos porque o modelo está marcado como "pronto" antes de ser realmente concluído.
• Os widgets de velocidade, burndown e burnup exibem diferentes trabalhos planejados para usuários em fusos horários diferentes.
• Uma retenção pode ser colocada na ingestão de dados do Analytics durante a manutenção, o que pode causar relatórios obsoletos.

Geral

• Os itens de navegação à esquerda são pressionados no IE quando não há espaço suficiente.

Administração

• Registro em log adicional adicionado à Atualização de coleção para ajudar a depurar problemas.
• Quando TfsConfig offlineDetach falha, a mensagem de erro não é acionável.
• O serviço TfsJobAgent falha.
• A extensão De pesquisa não é instalada após a conclusão da configuração.
• O Console de Administração fica sem resposta quando o BD de configuração está corrompido.
• Os Ganchos de Serviço podem não processar corretamente as notificações.
• A indexação de Pesquisa de Código não é iniciada após a configuração da Pesquisa.
• Há cadeias de caracteres não localizadas nos resultados das páginas de pesquisa.

Esta versão inclui a seguinte atualização:

Suporte para Visual Studio 2019 (VS2019) na tarefa teste do Visual Studio

Adicionamos suporte para o Visual Studio 2019 à tarefa teste do Visual Studio em pipelines. Para executar testes usando a plataforma de teste do Visual Studio 2019, selecione as opções Mais recente ou Visual Studio 2019 na lista suspensa Versão da plataforma de teste.

---

data de lançamento do Patch 2 do Azure DevOps Server 2019: 14 de maio de 2019

Lançamos um patch de segurança para Azure DevOps Server 2019 que corrige os bugs a seguir. Confira a postagem no blog para saber mais.

• CVE-2019-0872 : Vulnerabilidade XSS (Cross Site Scripting) no Test Plans
• CVE-2019-0971 : Vulnerabilidade da divulgação de informações confidenciais na API do Repos
• CVE-2019-0979 : Vulnerabilidade XSS (Cross Site Scripting) no hub de Usuário

---

data de lançamento do Patch 1 do Azure DevOps Server 2019: 9 de abril de 2019

Lançamos um patch de segurança para Azure DevOps Server 2019 que corrige os bugs a seguir. Confira a postagem no blog para saber mais.

• CVE-2019-0857: vulnerabilidade de falsificação no Wiki
• CVE-2019-0866 : Vulnerabilidade de execução de código remoto no Pipelines
• CVE-2019-0867 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
• CVE-2019-0868 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
• CVE-2019-0869: vulnerabilidade de injeção de HTML em pipelines
• CVE-2019-0870 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
• CVE-2019-0871 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
• CVE-2019-0874: vulnerabilidade XSS (cross site scripting) em pipelines
• CVE-2019-0875: vulnerabilidade de elevação de privilégio em Quadros

---

data de lançamento do Azure DevOps Server 2019: 5 de março de 2019

Observação

A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 2019 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.

---

Data de lançamento do RC2: 22 de janeiro de 2019

Resumo das novidades no Azure DevOps Server RC2 de 2019

Adicionamos os seguintes recursos ao RC2:

• Vincular commits do GitHub Enterprise e solicitações de pull para Azure Boards itens de trabalho
• Configurar builds usando YAML
• As anotações de cartão incluem bugs e tipos de item de trabalho personalizados
• Seletor de branch aprimorado
• Alterações no Licenciamento de Pipeline de Implantação de Artefatos e Release Management

---

Data de lançamento do RC1: 19 de novembro de 2018

Resumo das novidades no Azure DevOps Server RC1 2019

Azure DevOps Server 2019 apresenta uma nova experiência de navegação e muitos novos recursos. Alguns dos destaques incluem:

• Nova experiência de navegação
• A extensão do marketplace de Análise para relatórios agora está disponível
• Suporte para banco de dados SQL do Azure
• Processar herança em novas coleções
• Hub Novos Itens de Trabalho
• Novos hubs de Quadros, Listas de Pendências e Sprints
• Novo hub de Consultas
• Padronizar descrições de solicitação de pull usando modelos
• Alterar o branch de destino de uma solicitação de pull
• Gerenciar pipelines de build usando a nova página Builds
• Gerenciar pipelines de lançamento usando a nova página Versões
• Visualizar o progresso da versão
• Atualizar localmente seu agente
• Expor progressivamente e fases de implantações usando portões de liberação
• Fontes upstream
• Criar sumário para páginas wiki

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

• Geral
• Boards
• Repos
• Pipelines
• Test Plans
• Artefatos
• Wiki
• Relatórios

---

Geral

Anunciando Azure DevOps Server

Em 10 de setembro, anunciamos o Azure DevOps como a evolução do Visual Studio Team Services e do Team Foundation Server. Azure DevOps Server 2019 é nosso primeiro lançamento local com essa nova marca. Você pode encontrar mais informações em nossa postagem no blog.

Nova experiência de navegação

Estamos introduzindo uma nova navegação para modernizar a experiência do usuário. Essa nova navegação foi distribuída para o serviço do Azure DevOps e agora está disponível no Azure DevOps Server 2019. Confira nosso blog para obter mais informações.

Alterações no Licenciamento de Pipeline de Implantação de Artefatos e Release Management

Com base nos comentários dos usuários, estamos fazendo duas alterações importantes em nossas licenças com o Azure DevOps Server 2019. Primeiro, os clientes não precisarão mais comprar a extensão artifact para usar artefatos. Um uso de licença do Artifacts agora será incluído na Licença Básica. Todos os usuários que têm uma Licença Básica atribuída a eles agora poderão usar Artefatos. Em segundo lugar, os clientes não precisarão mais comprar Release Management Pipelines de Implantação. Assim como os Pipelines de Build, Release Management Pipelines de Implantação agora estão incluídos no Azure DevOps Server 2019.

Suporte para banco de dados SQL do Azure

Para simplificar a experiência de execução do Azure DevOps 2019 no Azure, habilitamos o suporte para o Banco de Dados SQL do Azure (Uso Geral S3 e superior). Isso permitirá que você aproveite recursos de backup extensivos e opções de dimensionamento para atender às suas necessidades, reduzindo a sobrecarga administrativa da execução do serviço. Observe que sua VM host deve estar localizada na mesma região do Azure que o banco de dados para manter a latência baixa. Para saber mais, confira a documentação .

APIs SOAP do modelo de objeto de cliente de teste de item & de trabalho em versões futuras

Azure DevOps Server 2019 continua a dar suporte à API SOAP de acompanhamento de item de trabalho e ao modelo de objeto do cliente. No entanto, ele será marcado como preterido em versões futuras do Azure DevOps Server. Você pode encontrar mais informações em nossa documentação.

Processar herança em novas coleções

A herança do processo agora está disponível em novas coleções. Os usuários precisarão tomar uma decisão consciente sobre o modelo de processo ao criar uma nova coleção. Consulte nossa documentação sobre o que é o modelo de herança e como ele é diferente do XML.

Caixa de pesquisa expandida

Entendemos a importância da pesquisa e estamos trazendo de volta a caixa de pesquisa expandida no cabeçalho do produto. Além disso, agora você pode invocar a caixa de pesquisa apenas clicando em "/" em qualquer página de serviço no Azure DevOps.

Esta é a caixa de pesquisa padrão:

Depois de digitar um "/", você verá a caixa de pesquisa expandida:

Meu submenu de trabalho

Um novo recurso que estamos muito animados para apresentar é o meu submenu de trabalho. Ouvimos comentários de que quando você está em uma parte do produto e quer algumas informações de outra parte, você não quer perder seu contexto. Com esse novo recurso, você pode acessar esse submenu de qualquer lugar do produto e ele fornecerá uma rápida visão das informações cruciais, incluindo seus itens de trabalho, solicitações de pull e todos os favoritos. Com esse novo submenu, se você estiver no Repos de cabeça para baixo em seu código, mas quiser marcar rapidamente em qual item de trabalho você deve trabalhar em seguida, basta clicar no submenu e ver os itens de trabalho atribuídos a você e pegar o próximo item.

Abaixo, você pode ver o submenu meu trabalho mostrando os itens de trabalho atribuídos a mim:

Aqui, você pode ver o segundo pivô que mostra as PRs atribuídas a mim. No submenu, você também tem um acesso de clique para exibir mais solicitações de pull:

Aqui você pode ver o último pivô, que é tudo o que você tem favoritos. Isso inclui suas equipes, dashboards, quadros, listas de pendências, consultas e repositórios favoritos:

Boards

Vincular commits do GitHub Enterprise e solicitações de pull para Azure Boards itens de trabalho

As equipes que usam o GitHub Enterprise para código e desejam recursos avançados de gerenciamento de projetos agora podem integrar seus repositórios com Azure Boards. Ao conectar o GitHub e o Azure Boards, você pode obter todos os recursos, como listas de pendências, quadros, ferramentas de planejamento de sprint, vários tipos de item de trabalho e ainda ter um fluxo de trabalho que se integra aos fluxos de trabalho do desenvolvedor no GitHub.

É fácil vincular commits e pull requests a itens de trabalho. Mencione o item de trabalho usando a seguinte sintaxe:

AB#{work item ID}

Mencione um item de trabalho em um mensagem do commit, título da solicitação de pull ou descrição da solicitação de pull e Azure Boards criará um link para esse artefato. Por exemplo, considere uma mensagem do commit como esta:

Adds support for deleting connections. Fixes AB#20.

Isso criará um link do item de trabalho nº 20 para a confirmação no GitHub, que aparecerá na seção Desenvolvimento do item de trabalho. ​

Se as palavras "corrigir", "correções" ou "fixas" precedem o item de trabalho menção (conforme mostrado acima), o item de trabalho será movido para o estado concluído quando a confirmação for mesclada ao branch padrão.

As equipes que estão usando o Azure Pipelines para criar código no GitHub também verão os itens de trabalho vinculados às confirmações do GitHub no resumo do build.

Hub Novos Itens de Trabalho

O Hub de Itens de Trabalho é nosso novo hub que servirá como a página inicial de seus itens de trabalho! Aqui, você tem muitos modos de exibição de lista diferentes de seus itens de trabalho com escopo reduzido para você. Você pode exibir Atribuído a mim para ver rapidamente todo o trabalho atribuído a você ou Atualizado recentemente , que mostra todos os itens de trabalho em seu projeto que foram atualizados mais recentemente. Todas as opções de lista podem ser vistas abaixo:

Se você quiser definir o escopo de suas listas ainda mais, poderá filtrar por tipo, atribuído a, estado, área, marcas e palavra-chave. Depois de ter a exibição de lista desejada, você poderá classificar os itens de trabalho simplesmente clicando no cabeçalho da coluna. Se uma coluna for muito estreita para você exibir o conteúdo completo da coluna, você poderá redimensionar facilmente a coluna na área de cabeçalho. Essas experiências podem ser vistas abaixo:

Novos hubs de Quadros, Listas de Pendências e Sprints

O hub de listas de pendências foi dividido em três hubs distintos para melhorar a experiência do usuário. Embora poderoso, o antigo hub backlogs era o lar de muitos recursos. Isso geralmente dificulta a localização do recurso ou da funcionalidade que os usuários estavam procurando. Para resolver esse problema, dividimos o hub de listas de pendências em:

• O hub listas de pendências agora abriga apenas as listas de pendências de um projeto. Uma lista de pendências é uma lista priorizada de trabalho para a equipe. As listas de pendências fornecem ferramentas de planejamento, como hierarquia de itens de trabalho, previsão e nova experiência de planejamento de sprint.
• O novo hub boards é o lar de todos os Quadros Kanban para um projeto. Os quadros são usados para comunicar status e fluxo. Os cartões (itens de trabalho) se movem da esquerda para a direita através do quadro por meio de colunas definidas pela equipe.
• O novo hub sprints é o lar dos recursos usados para planejar e executar um incremento de trabalho. Cada sprint contém uma lista de pendências de sprint, um quadro de tarefas e uma exibição para gerenciar e definir a capacidade para a equipe.

Novo hub de Consultas

O novo hub de consultas simplifica muitos dos recursos de consultas existentes do hub antigo com uma aparência mais moderna, bem como fornece novos recursos para facilitar o acesso às consultas que são importantes para você. Alguns destaques da nova experiência incluem:

• Páginas de diretório com última modificação por informações e a capacidade de pesquisar consultas
• Trilha com URLs exclusivas para pastas para marcar grupos importantes de consultas
• Acesso rápido às suas consultas favoritas na página de resultados

Leia mais sobre essas atualizações interessantes em nosso blog do DevOps.

Mover itens de trabalho para outro projeto e alterar um tipo de item de trabalho

Agora você pode alterar o tipo de item de trabalho ou mover itens de trabalho para outro projeto dentro de uma coleção de projetos. Esses recursos exigem que o data warehouse esteja desabilitado. Com o data warehouse desabilitado , você pode usar o Serviço de Análise para dar suporte às suas necessidades de relatório. Para saber mais sobre como desabilitar o data warehouse, consulte Desabilitar o data warehouse e o cubo.

Recursos de planejamento de sprint

Os novos recursos de planejamento de sprint ajudam a agilizar e melhorar a experiência de planejamento de sprint.

• Crie seu próximo sprint ou assine um agendamento de sprint existente diretamente do hub Sprints .
• Use o novo painel Planejamento na lista de pendências para arrastar e soltar itens de trabalho em sprints futuros. O painel Planejamento inclui datas de sprint, contagens de itens de trabalho e esforço planejado.
• Adicione requisitos à parte superior do quadro de tarefas ou use a criação rápida para adicionar à parte superior, inferior ou linha de sua lista de pendências de sprint.
• Use filtros para Assignee, Work Item Type, State e Tags para adaptar os modos de exibição às suas necessidades.

Novas páginas de diretório

Todos os novos hubs, incluindo Backlogs, Boards e Sprints, agora têm novas páginas de diretório organizadas com as seguintes seções:

• Continuar de onde parou Esta nova seção fornece um link rápido diretamente para o último (Board | Lista de pendências | Sprint) você estava.
• Favoritos Todos os seus quadros favoritos, sprints e listas de pendências em todas as equipes.
• Meu Todos os quadros, listas de pendências e sprints para equipes às quais você pertence.
• Todos Uma lista completa de todas as placas, listas de pendências e sprints.

Menu Novas Opções de Exibição

Os novos hubs, incluindo Listas de Pendências, Quadros e Sprints, têm um novo menu Opções de Exibição . Esta é uma nova página inicial para todas as ações para personalizar o layout e o conteúdo da página. Use Opções de Exibição para habilitar exibições adicionais, como mostrar hierarquia em listas de pendências ou alterar a opção Agrupar por em um quadro de tarefas, ativar o painel lateral para mapeamento e planejamento de sprints ou para explorar gráficos de detalhes de trabalho.

Leia mais sobre essas atualizações interessantes, o novo painel Perfil de equipe e Favoritos em nosso blog de DevOps.

As anotações de cartão incluem bugs e tipos de item de trabalho personalizados

As anotações de cartão são amadas por sua exibição e interação intuitivas marcar lista. Anteriormente, cartão anotações eram limitadas a tipos de nível de lista de pendências padrão e não eram compatíveis com Bugs ou tipos personalizados. Com a nova versão, removemos a restrição nos tipos de item de trabalho e adicionamos a capacidade de mostrar Bugs e qualquer tipo de item de trabalho personalizado como uma anotação cartão.

As configurações de quadro para cartão anotações foram expandidas para incluir todos os tipos de item de trabalho disponíveis para esse nível de lista de pendências.

Quando as anotações do item de trabalho estão habilitadas, as contagens desse tipo de item de trabalho são incluídas no cartão como uma lista de marcar separada.

A criação rápida de tipos de item de trabalho habilitados também está disponível por meio cartão menu de contexto.

Mover o trabalho usando áreas e iterações sugeridas

Pode ser comum trabalhar na mesma área ou iteração e navegar repetidamente pelas hierarquias ao mover itens de trabalho. Os controles Demarcador e Área agora incluem uma lista de valores usados recentemente como Sugestões, fornecendo acesso rápido para definir e seguir em frente.

Além disso, as datas de iteração são incluídas à direita do nome para que você possa julgar rapidamente quando um item de trabalho deve ser entregue.

Trabalho de consulta na agenda de iteração com +/- @CurrentIteration

A @CurrentIteration macro que ajuda sua equipe a acompanhar o trabalho com base em seu agendamento de iteração agora dá suporte a deslocamento inteiro. Mantenha guias facilmente sobre o trabalho que não foi fechado com @CurrentIteration - 1 ou examine o trabalho planejado para iterações futuras com @CurrentIteration + 1. Consulte a postagem @CurrentIteration no Blog do Microsoft DevOps para obter mais informações.

Esclarecer agendamentos de iteração de consulta com o @CurrentIteration parâmetro Team

Se você estiver usando a @CurrentIteration macro em consultas no passado, talvez tenha notado que os resultados podem variar se o contexto da equipe mudar entre o Teams com diferentes agendas de iteração. Agora, ao criar ou modificar uma consulta com a @CurrentIteration macro, você precisará selecionar também a Equipe com o agendamento de iteração relevante para a consulta. Com o parâmetro Team, você pode usar a @CurrentIteration macro na mesma consulta, mas entre equipes. Um exemplo pode ser uma consulta para itens de trabalho em dois projetos de equipe diferentes usando nomes de iteração diferentes e até mesmo agendamentos. Isso significa que não é mais preciso atualizar as consultas à medida que os sprints mudam! Consulte a postagem @CurrentIteration no Blog do Microsoft DevOps para obter mais informações.

Trabalho de consulta nos Caminhos de Área de uma Equipe com a nova @TeamAreas macro

Nas configurações de uma Equipe, você pode associar um ou mais Caminhos de Área, o que ajuda a concentrar listas de pendências, quadros, planos e até painéis apenas ao trabalho dessa equipe. No entanto, se você quisesse escrever uma consulta para uma Equipe, era necessário listar os Caminhos de Área específicos para essa equipe nas cláusulas de consulta. Agora, uma nova macro @TeamAreas está disponível para você referenciar facilmente os Caminhos de Área pertencentes à Equipe especificada.

Consultar campos de rich text vazios

Encontre itens de trabalho que tenham um campo de rich text vazio, como Descrição, usando o novo operador de consulta IsEmpty .

Encontre facilmente itens de trabalho existentes em experiências de vinculação e menção

Quando você deseja vincular dois itens de trabalho existentes, agora você pode encontrar facilmente o item que é importante para você usando nosso novo controle de pesquisa de item de trabalho. O seletor de consulta foi substituído por sugestões embutidas com base em seus itens de trabalho acessados recentemente, bem como um ponto de entrada para pesquisar um item de trabalho específico por ID ou título.

Abrir itens de trabalho da pesquisa

Anteriormente, não era possível abrir um item de trabalho na página de resultados da pesquisa se o painel de visualização do item de trabalho estivesse desativado. Isso dificultaria a pesquisa nos resultados da pesquisa. Agora você pode clicar no título do item de trabalho para abrir os itens de trabalho em uma janela modal.

Repos

Seletor de branch aprimorado

A maioria das experiências em Azure Repos exige que você selecione um repositório e, em seguida, um branch nesse repositório. Para melhorar essa experiência para organizações com um grande número de branches, estamos lançando um novo seletor de branch. O seletor agora permite que você selecione seus branches favoritos ou pesquise rapidamente um branch.

Receber notificações quando as políticas de solicitação de pull forem ignoradas

Para equipes que usam PRs (solicitações de pull) e políticas de branch, pode haver ocasiões em que as pessoas precisam substituir e ignorar essas políticas , por exemplo, ao implantar um hotfix em um problema de produção no meio da noite. Faz sentido confiar nos desenvolvedores para fazer a coisa certa e usar a funcionalidade de substituição com moderação. Ao mesmo tempo, as equipes precisam de uma maneira de verificar se essas substituições de política estão sendo usadas nas situações certas. Para dar suporte a isso, adicionamos um novo filtro de notificação para permitir que usuários e equipes recebam alertas por email sempre que uma política for ignorada. Comece com o modelo A pull request criado ou atualizado e selecione Bypass de Política na lista de filtros. Selecione As políticas foram ignoradas como o valor e você será notificado sempre que uma PR for concluída e as políticas forem ignoradas.

Permitir ignorar políticas de branch sem abrir mão da proteção por push

Há muitos cenários em que você tem a necessidade ocasional de ignorar uma política de branch – reverter uma alteração que causou uma quebra de build, aplicar um hotfix no meio da noite, etc. Anteriormente, oferecemos uma permissão ("Isento de imposição de política") para ajudar as equipes a gerenciar quais usuários receberam a capacidade de ignorar políticas de branch ao concluir uma solicitação de pull. No entanto, essa permissão também concedeu a capacidade de enviar por push diretamente para o branch, ignorando totalmente o processo de PR.

Para melhorar essa experiência, dividimos a permissão antiga para oferecer mais controle às equipes que estão concedendo permissões de bypass. Há duas novas permissões para substituir a antiga:

1. Ignorar políticas ao concluir solicitações de pull. Os usuários com essa permissão poderão usar a experiência de "Substituição" para solicitações de pull.
2. Ignorar políticas ao enviar por push. Os usuários com essa permissão poderão enviar por push diretamente para branches que tenham as políticas necessárias configuradas.

Ao conceder a primeira permissão e negar a segunda, um usuário poderá usar a opção de bypass quando necessário, mas ainda terá a proteção de enviar por push acidentalmente para um branch com políticas.

Observação

Essa alteração não introduz nenhuma alteração de comportamento. Os usuários que anteriormente receberam a permissão Permitir para "Isento de imposição de política" receberão Permissão para ambas as novas permissões, de modo que eles poderão substituir a conclusão em PRs e efetuar push diretamente para branches com políticas.

Consulte a documentação Definir permissões de branch para obter mais informações.

Descrever rapidamente as solicitações de pull usando mensagens de confirmação

Gravar mensagens de confirmação descritivas agrega valor ao histórico de qualquer repositório Git. Para incentivar mensagens de confirmação de qualidade, novas solicitações de pull (PR) que têm vários commits exigirão que os colaboradores insiram um título manualmente.

As descrições da solicitação de pull continuarão vazias por padrão, mas um novo recurso facilitará a incorporação das mensagens de confirmação das confirmações de PR na descrição da PR. Para adicionar as mensagens de confirmação, basta clicar em Adicionar mensagens de confirmação para acrescentar as mensagens de confirmação ao final do texto de descrição da PR.

Criar solicitações de pull sem uma equipe padrão como revisor

Quando iniciamos a experiência de PR (solicitação de pull) pela primeira vez, pensamos que faria sentido atribuir todas as PRs ao contexto de equipe que você havia selecionado ao criar a PR. Esse comportamento tem sido um ponto de frustração, pois muitas pessoas não notaram a conexão entre o contexto da equipe e a atribuição de PR.

Como parte das novas alterações de navegação, aproveitamos a oportunidade para alterar essa associação padrão com as equipes. Você observará duas alterações:

1. Ao criar uma PR, nenhum revisor é adicionado por padrão. A lista de revisores tem um recurso para facilitar a adição de indivíduos e grupos que foram adicionados a PRs recentemente. A política de revisores necessária também pode ajudar as equipes que desejam garantir que revisores específicos sejam adicionados para revisar seu código.
2. O hub solicitações de pull tem uma nova seção personalizável. Por padrão, esta seção mostra PRs "Atribuídos às minhas equipes", fornecendo funcionalidade equivalente como a seção antiga. No entanto, se você pertencer a várias equipes, esta seção mostrará PRs atribuídas a qualquer uma de suas equipes. A seção também é personalizável – basta clicar na ação "Personalizar esta exibição" perto do cabeçalho da seção.

Padronizar descrições de solicitação de pull usando modelos

Escrever boas descrições de solicitação de pull é uma ótima maneira de ajudar os revisores a saber o que esperar ao revisar o código. Eles também são uma ótima maneira de ajudar a acompanhar coisas que devem ser feitas para cada alteração, como teste, adição de testes de unidade e atualização da documentação. Muitos de vocês estão solicitando que adicionemos modelos de solicitação de pull para facilitar a gravação de excelentes descrições pelas equipes, e agora adicionamos esse recurso.

Além de dar suporte a um modelo de descrição de PR padrão, as equipes podem adicionar vários modelos, que são apresentados a você em um menu na página Criar PR. Basta clicar no botão Adicionar um modelo para escolher entre qualquer modelo no repositório para acrescentá-lo à descrição de PR.

Também há suporte para modelos específicos de branch se você quiser aplicar um modelo diferente para uma PR em uma ramificação específica ou pasta de branch. Por exemplo, se você quiser ter um modelo específico para todos os branches que começam com "hotfix/", você poderá adicionar um modelo que será usado para todas as PRs nesses branches.

Consulte a documentação de modelos de solicitação de pull para saber mais sobre como criar e usar modelos.

Alterar o branch de destino de uma solicitação de pull

Para a maioria das equipes, quase todas as solicitações de pull têm como destino o mesmo branch, como main ou develop. No entanto, no caso em que você precisa direcionar um branch diferente, é fácil esquecer de alterar o branch de destino do padrão. Com o novo recurso para alterar o branch de destino de uma solicitação de pull ativa, essa agora é uma ação simples. Basta clicar no ícone de lápis próximo ao nome do branch de destino no cabeçalho da solicitação de pull.

Além de apenas corrigir erros, o recurso para alterar branches de destino também facilita a "redirecionação" de uma solicitação de pull quando o branch de destino é mesclado ou excluído. Considere um cenário em que você tem uma PR direcionada a um branch de recurso que contém algum recurso do qual suas alterações dependem. Você deseja examinar suas alterações dependentes isoladamente de outras alterações no branch de recurso, portanto, você inicialmente tem como destino features/new-feature. Em seguida, os revisores podem ver apenas suas alterações e deixar os comentários apropriados.

Agora, considere o que aconteceria se o branch de recurso também tivesse uma PR ativa e fosse mesclado main antes das alterações? Anteriormente, você teria que abandonar suas alterações e criar uma nova PR em mainou mesclar sua PR em e, em features/new-featureseguida, criar outra PR de features/new-feature para main. Com essa nova ação para atualizar o branch de destino, você pode simplesmente alterar o branch de destino da PR de features/new-feature para main, preservando todo o contexto e comentários. Alterar o branch de destino até cria uma nova atualização para a PR, o que facilita a análise de diferenças anteriores antes da alteração do branch de destino.

Os autores de extensão podem consultar o contexto sobre o repositório atual

Um dos desafios para um autor de uma extensão de controle de versão é obter o contexto do repositório que está sendo exibido para o usuário, como o nome, a ID e a URL. Para ajudar com isso, adicionamos o VersionControlRepositoryService como um serviço acessível por extensão. Usando isso, um autor de extensão pode consultar informações sobre o contexto atual do repositório Git na interface do usuário da Web. Atualmente, ele tem um método, getCurrentGitRepository().

• Se um repositório Git for selecionado, um objeto GitRepository será retornado com dados básicos sobre o repositório (nome, ID e URL)
• Se um repositório TFVC for selecionado ou o serviço for acessado fora das páginas Azure Repos, será retornado nulo.

Aqui está uma extensão de exemplo que usa esse serviço.

Pipelines

Gerenciar pipelines de build usando a nova página Builds

Estamos fazendo várias melhorias e implantando uma nova versão da página Builds . Essa nova versão combina o diretório de todos os pipelines de build e a lista de builds atuais para que você possa navegar rapidamente pelos builds do projeto para ver seus status. Ele também inclui uma visualização da análise de teste para o pipeline selecionado.

Gerenciar emails de conclusão de compilação e implantação melhor usando a formatação aprimorada

Os emails de conclusão de build e implantação foram atualizados para serem mais filtráveis por regras de email. Agora a linha de assunto inclui informações mais relevantes rapidamente, o corpo contém mais detalhes, e seu estilo foi atualizado com a marca mais recente.

Os elementos do novo formato são:

• [Build result] [pipeline name] - [repository:branch] - [project name] - [commit]
• [Deployment result] [pipeline name] > [release name] : [stage name]

Veja alguns exemplos:

• [Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80
• [Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1

Siga a nova terminologia unificada do Azure Pipelines

Ao longo de builds e versões, diferentes termos têm sido usados historicamente para conceitos semelhantes. Em outros casos, os significados dos termos eram vagos. Por exemplo, informando a diferença entre um pool de agentes e uma fila de agentes.

A terminologia foi unificada no Azure Pipelines para esclarecer seus conceitos. Agora você verá os seguintes termos unificados:

Termo anterior	Termo unificado	Significado
Agente hospedado	Agente hospedado pela Microsoft	Um agente de build/versão executado na infraestrutura hospedada na nuvem gerenciada pela Microsoft.
Agente privado	Agente auto-hospedado	Um agente de build/versão executado em um computador fornecido e gerenciado por você.
Pool de agentes	Pool de agentes	Um conjunto de computadores de agente no nível da organização que pode executar builds ou versões.
Fila do agente	Pool de agentes	Um conjunto de computadores de agente no nível do projeto que podem executar builds ou versões. Ele está vinculado a um pool de agentes no nível da organização.
Definição da compilação	Pipeline de build	Um conjunto de etapas de build de ponta a ponta para um aplicativo.
Build	Build	Uma instância de um pipeline de build que está em execução ou foi executada.
Fase	Trabalho	Uma série de tarefas que são executadas sequencialmente ou em paralelo em um agente. Um pipeline de build ou lançamento pode conter um trabalho ou um grafo de vários trabalhos.
Definição de versão	Pipeline de lançamento	Um conjunto de etapas de versão de ponta a ponta para um aplicativo ser implantado em vários estágios.
Versão	Versão	Uma instância de um pipeline de lançamento que está em execução ou foi executada.
Ambiente	Estágio	Uma entidade lógica e independente que representa onde você deseja implantar uma versão gerada a partir de um pipeline de lançamento.
Trabalho/pipeline simultâneo	Trabalho paralelo	Um trabalho paralelo oferece a capacidade de executar um único trabalho de build ou lançamento por vez em sua organização. Com mais trabalhos paralelos disponíveis, você pode executar mais trabalhos de build e lançamento ao mesmo tempo.
Ponto de extremidade de serviço	Conexão de serviço	Um grupo de configurações, como credenciais, usado para se conectar a serviços externos para executar tarefas em um build ou versão.

Consulte a documentação Conceitos para obter mais informações.

Gerenciar pipelines de lançamento usando a nova página Versões

Uma experiência de usuário nova e totalmente reprojetada está disponível para a página de aterrissagem da versão. Confira uma lista dos pipelines de lançamento que você lança com frequência à esquerda. Você também pode pesquisar seus pipelines e favoritos deles.

Altere para a exibição de pastas para criar pastas para organização e segurança. A segurança pode ser definida em um nível de pasta.

Visualizar o progresso da versão

A nova exibição de progresso da versão fornece atualizações dinâmicas do progresso da implantação e acesso de um clique para obter mais detalhes. A nova exibição visualiza o pipeline de lançamento, facilitando a compreensão do que está acontecendo e apresenta os detalhes e as ações apropriados em diferentes estágios da versão.

Pipeline, detalhes de versão e ambientes

A exibição Pipeline mostra os artefatos da versão e os ambientes em que eles serão implantados. A área Versão fornece detalhes de versão, como o gatilho de versão, versões de artefato e marcas.

Os ambientes são modelados de forma a ajudar a entender seus status, juntamente com o progresso detalhado. A qualquer momento, você pode acessar os logs clicando no link status no ambiente.

Pré-implantação e pós-implantação

Se as condições de pré-implantação ou pós-implantação tiverem sido definidas para um ambiente, ela será indicada no ambiente com a presença das aprovações e portões. O progresso das aprovações e dos portões também aparece no status do ambiente. Você pode executar uma ação ou exibir mais detalhes clicando no ícone de condição do ambiente pendurado no lado direito ou esquerdo do ambiente.

Commits e itens de trabalho

A cada nova versão, você pode ver a lista de commits associados e itens de trabalho para cada ambiente separadamente clicando no ambiente. Se a lista for longa, use filtros para localizar um item de confirmação ou de trabalho no qual você está interessado.

Progresso da implantação e logs

Os ambientes mostram atualizações dinâmicas para implantações em andamento, incluindo quantas fases e tarefas estão concluídas e o tempo de execução. Clicar no ambiente status abre uma exibição que contém os logs, com foco no que está ativo no momento.

Você pode clicar nos logs para inserir uma exibição focada.

Impacto da atualização para o Azure DevOps Server 2019 em tarefas: Cópia de Arquivo do Windows Machine e PoweShell no Computador de Destino

Os grupos de computadores em Hub de Teste foram preteridos no TFS 2017 RTM. Com Azure DevOps Server 2019, o serviço Grupos de máquinas não está mais disponível. Isso afetará os usuários da tarefa 'Cópia de Arquivo do Windows Machine' versão 1.* e da tarefa 'PowerShell on Target Machines' versão 1.*. Para que seus pipelines continuem funcionando,

• Você precisa alternar para a tarefa "Cópia de Arquivo do Windows Machine" versão 2.* e fornecer o fqdn completo para o computador de destino em vez de apenas o nome do computador.
• E alterne para a tarefa 'Powershell on Target Machine' versão 2.* ou posterior e forneça o fqdn completo do nome do computador ou do computador seguido pelas portas de Gerenciamento Remoto do Windows (http/https). Por exemplo, targetMachine:5985 ou targetMachine:5986

Resultados do teste e extensibilidade

Os resultados da execução do teste também são exibidos para cada ambiente. Clicar nos resultados do teste abre uma exibição que contém detalhes do teste, incluindo resultados de outras extensões que contribuem para o processo.

As extensões existentes funcionam nessa nova exibição, além disso, há novos pontos de extensibilidade para permitir que as extensões se desenvolvam para exibir ainda mais informações para um ambiente. Consulte a documentação de contribuições e extensões para obter mais informações.

Configurar builds usando YAML

Os pipelines de build baseados em YAML estão disponíveis em seu Azure DevOps Server. Automatize seu pipeline de integração contínua usando um arquivo YAML verificado em seu repositório. Uma referência completa para o esquema YAML pode ser encontrada aqui.

Para dar suporte a pipelines de build baseados em YAML de forma mais direta, alteramos o comportamento padrão para todos os novos recursos criados (por exemplo, conexões de serviço, grupos de variáveis, pools de agentes e arquivos seguros) para serem utilizáveis em todo o pipeline desse projeto. Se você quiser um controle mais rígido sobre seus recursos, poderá desabilitar o modelo de autorização padrão (veja a figura abaixo). Quando você faz isso, alguém com permissões para usar o recurso deve salvar explicitamente o pipeline no editor da Web depois que uma referência de recurso é adicionada ao arquivo YAML.

Encadear compilações relacionadas usando gatilhos de conclusão de build

Produtos grandes têm vários componentes que dependem uns dos outros. Esses componentes geralmente são criados de forma independente. Quando um componente upstream (uma biblioteca, por exemplo) é alterado, as dependências downstream precisam ser recompiladas e revalidadas. Normalmente, as equipes gerenciam essas dependências manualmente.

Agora você pode disparar um build após a conclusão bem-sucedida de outro build. Artefatos produzidos por um build upstream podem ser baixados e usados no build posterior, e você também pode obter dados dessas variáveis: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Consulte a documentação de gatilhos de build para obter mais informações.

Tenha em mente que, em alguns casos, uma única compilação de várias fases pode atender às suas necessidades. No entanto, um gatilho de conclusão de build será útil se seus requisitos incluírem diferentes definições de configuração, opções ou uma equipe diferente para possuir o processo dependente.

Atualizar localmente seu agente

As tarefas instaladas por meio da Galeria às vezes exigem uma versão mais recente do agente de pipelines. Se o Azure DevOps Server puder se conectar à Internet, as versões mais recentes serão baixadas automaticamente. Caso contrário, você precisará atualizar manualmente cada agente. A partir desta versão, você pode configurar seu Azure DevOps Server para procurar os arquivos de pacote do agente em seu disco local em vez da Internet. Isso oferece flexibilidade e controle sobre quais versões de agente você disponibiliza, sem precisar expor seus Azure DevOps Server à Internet.

Nova URL de selo de status de build

Os selos de build inseridos na home page de um repositório são uma maneira comum de mostrar a integridade do repositório. Embora tivéssemos selos de construção até agora, houve alguns problemas:

• A URL não era intuitiva
• O selo não era específico de um branch
• Não havia como um usuário clicar no selo para levar o usuário ao build mais recente dessa definição

Agora estamos lançando uma nova API para selos de build que resolve esses problemas. A nova API permite que os usuários publiquem uma status por branch e podem levar os usuários para a compilação mais recente do branch selecionado. Você pode obter o Markdown para a nova URL de selo do status selecionando a ação de menu Selo de status na nova página Builds.

Para compatibilidade com versões anteriores, continuaremos a honrar as URLs de selo de build mais antigas também.

Adicionar contadores de build personalizados aos seus builds

Os contadores de build fornecem uma maneira exclusiva de numerar e rotular builds. Anteriormente, você poderia usar a variável especial $(rev:r) para fazer isso. Agora você pode definir suas próprias variáveis de contador em sua definição de build que são incrementadas automaticamente sempre que você executa um build. Faça isso na guia variáveis de uma definição. Esse novo recurso oferece mais poder das seguintes maneiras:

• Você pode definir um contador personalizado e definir seu valor de semente. Por exemplo, você pode iniciar o contador em 100. $(rev:r) sempre começa em 0.
• Você pode usar sua própria lógica personalizada para redefinir um contador. $(rev:r) está vinculado à geração de número de build e é redefinido automaticamente sempre que há um novo prefixo no número de build.
• Você pode definir vários contadores por definição.
• Você pode consultar o valor de um contador fora de um build. Por exemplo, você pode contar o número de builds executados desde a última redefinição usando um contador.

Consulte a documentação sobre variáveis definidas pelo usuário para obter mais informações sobre contadores de build.

Azure Policy validações de conformidade e segurança em Pipelines

Queremos garantir a estabilidade e a segurança do software no início do processo de desenvolvimento, juntando desenvolvimento, segurança e operações. Para fazer isso, adicionamos suporte para Azure Policy.

O Azure Policy ajuda você a gerenciar e impedir problemas de TI com definições de políticas que impõem regras e efeitos para seus recursos. Quando você usa Azure Policy, os recursos permanecem em conformidade com seus padrões corporativos e contratos de nível de serviço.

Para cumprir as diretrizes de conformidade e segurança como parte do processo de lançamento, aprimoramos nossa experiência de implantação do grupo de recursos do Azure. Agora, estamos falhando na tarefa de implantação do Grupo de Recursos do Azure com erros relacionados à política relevantes em caso de violações durante a implantação de modelos do ARM.

Além disso, adicionamos Azure Policy modelo de definição de versão. Isso permitirá que os usuários criem políticas do Azure e atribuam essas políticas a recursos, assinaturas ou grupos de gerenciamento da própria definição de versão.

Criar em plataformas Linux/ARM e Windows de 32 bits

O agente multiplataforma do Azure Pipelines código aberto sempre foi compatível com Windows, macOS e Linux de 64 bits (x64). Com esta versão, estamos introduzindo duas novas plataformas com suporte: Linux/ARM e Windows/32 bits. Essas novas plataformas oferecem a capacidade de criar plataformas menos comuns, mas não menos importantes, como o Raspberry Pi, um computador Linux/ARM.

Experiências aprimoradas para testes em pipelines

A guia Testes agora tem uma experiência moderna que fornece informações avançadas de teste no contexto para Pipelines. A nova experiência fornece uma exibição de teste em andamento, experiência de depuração de página inteira, histórico de teste de contexto, relatório de execução de teste anulada e resumo do nível de execução.

Exibir a execução de testes em andamento

Testes, como integração e testes funcionais, podem ser executados por muito tempo, portanto, é importante ver a execução do teste a qualquer momento. Com o modo de exibição de teste In-Progress, você não precisa mais aguardar a conclusão da execução do teste para saber o resultado do teste. Os resultados estão disponíveis quase em tempo real à medida que são executados, ajudando você a executar ações mais rapidamente. Você pode depurar uma falha ou anular, registrar um bug ou anular o pipeline. No momento, o recurso está disponível para pipeline de build e lançamento usando a Tarefa de Teste do VS na fase de Vários Agentes, usando a Tarefa Publicar Resultados de Teste ou publicando resultados de teste usando API(s). No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.

O modo de exibição a seguir mostra o resumo do teste In-Progress na nova exibição de progresso da versão, relatando a contagem total de testes e o número de falhas de teste em um determinado ponto no tempo.

Ao clicar no resumo do teste In-Progress acima, você pode exibir o resumo detalhado do teste juntamente com informações de teste com falha ou anuladas em Test Plans. O resumo do teste é atualizado em um intervalo periódico com a capacidade de atualizar a exibição de detalhes sob demanda, com base na disponibilidade de novos resultados.

Exibir detalhes de depuração da execução de teste na página inteira

Mensagens de erro e rastreamentos de pilha são longos por natureza e precisam de imóveis suficientes para exibir os detalhes durante a depuração. Para ter uma experiência de depuração imersiva, agora você pode expandir o modo de exibição de teste ou execução de teste para o modo de exibição de página inteira, enquanto ainda é capaz de executar o necessário em operações de contexto, como criação de bugs ou associação de requisitos para o resultado do teste atual.

Exibir o histórico de teste no contexto

Historicamente, as equipes teriam que ir para o hub De execuções para exibir o histórico de um resultado de teste. Com a nova experiência, trazemos o histórico de testes diretamente no contexto dentro da guia Test Plans para compilação e versão. As informações do histórico de teste são fornecidas de maneira progressiva, começando com a definição de build atual ou o ambiente para o teste selecionado, seguido por outros branches e ambientes para o build e a versão, respectivamente.

Exibir testes anulados

A execução do teste pode ser anulada devido a vários motivos, como código de teste incorreto, origem em teste e problemas ambientais. Independentemente do motivo da anulação, é importante diagnosticar o comportamento e identificar a causa raiz. Agora você pode exibir os testes anulados e as execuções de teste, juntamente com as execuções concluídas em Test Plans. Atualmente, o recurso está disponível para pipeline de build e lançamento usando a Tarefa de Teste do VS na fase de Vários Agentes ou publicando resultados de teste usando API(s). No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.

Teste de rastreamento e suporte a ambientes de lançamento no Histórico de Testes

Estamos adicionando suporte para exibir o histórico de um teste automatizado agrupado por vários ambientes de versão nos quais o teste é executado. Se você estiver modelando ambientes de lançamento como pipelines de lançamento ou ambientes de teste e executando testes nesses ambientes, poderá descobrir se um teste está passando no ambiente de desenvolvimento, mas falhando no ambiente de integração. Você pode descobrir se ele está passando na localidade inglesa, mas falhando em um ambiente que tem localidade turca. Para cada ambiente, você encontrará a status do resultado mais recente do teste e, se o teste tiver falhado nesse ambiente, você também encontrará a versão desde a qual o teste falhou.

Examinar os resultados resumidos do teste

Durante a execução do teste, um teste pode gerar várias instâncias de testes que contribuem para o resultado geral. Alguns exemplos incluem: testes que são executados novamente devido a falhas, testes compostos por uma combinação ordenada de outros testes (por exemplo, teste ordenado) ou testes com instâncias diferentes com base no parâmetro de entrada fornecido (testes controlados por dados). Como esses testes estão relacionados, eles precisam ser relatados junto com o resultado geral derivado com base nos resultados de teste individuais. Com essa atualização, apresentamos uma versão aprimorada dos resultados do teste apresentada como uma hierarquia na guia Testes em uma versão. Vamos examinar um exemplo.

Anteriormente, introduzimos a capacidade de executar novamente testes com falha na tarefa teste do VS . No entanto, relatamos apenas a última tentativa de um teste, o que limitou um pouco a utilidade desse recurso. Agora estendemos esse recurso para relatar cada instância da execução do teste como uma tentativa. Além disso, a API de Gerenciamento de Testes agora dá suporte à capacidade de publicar e consultar resultados de teste hierárquicos. Consulte a documentação da API de resultados de teste para obter mais informações.

Observação

As métricas na seção resumo do teste (por exemplo, Total de testes, Aprovados etc.), são computadas usando o nível raiz da hierarquia em vez de cada iteração individual dos testes.

Exibir análise de teste em Pipelines

Acompanhar a qualidade do teste ao longo do tempo e melhorar a garantia de teste é fundamental para manter um pipeline íntegro. O recurso de análise de teste fornece visibilidade quase em tempo real dos dados de teste para builds e pipelines de lançamento. Ele ajuda a melhorar a eficiência do pipeline identificando problemas repetitivos de qualidade de alto impacto.

Você pode agrupar resultados de teste por vários elementos, identificar testes de chave para seu branch ou arquivos de teste ou fazer drill down em um teste específico para exibir tendências e entender problemas de qualidade, como problemas de integridade.

Veja a análise de teste para builds e lançamentos, versão prévia abaixo:

Para obter mais informações, confira a documentação.

Simplificar definições com várias tarefas sem agente

As tarefas em uma fase sem agente são orquestradas por e executadas no servidor. As fases sem agente não exigem um agente ou nenhum computador de destino. Ao contrário das fases do agente, apenas uma tarefa poderia ser adicionada a cada fase sem agente nas definições. Isso significava que várias fases tinham que ser adicionadas quando havia mais de uma tarefa sem agente no processo, tornando a definição volumosa. Flexibilizamos essa restrição, o que permite que você mantenha várias tarefas em fases sem agente. As tarefas na mesma fase seriam executadas sequencialmente, assim como em fases de agente. Consulte a documentação de fases do servidor para obter mais informações.

Expor progressivamente e fases de implantações usando portões de lançamento

Usando portões de versão, você pode especificar critérios de integridade do aplicativo que devem ser atendidos antes que uma versão seja promovida para o próximo ambiente. Todos os portões especificados são avaliados periodicamente antes ou depois de qualquer implantação, até que todos sejam bem-sucedidos. Quatro tipos de portões estão disponíveis prontos para uso e você pode adicionar mais portões do Marketplace. Você poderá auditar que todos os critérios necessários para uma implantação foram atendidos. Consulte a documentação para as entradas de versão para obter mais informações.

Manter implantações até que os portões tenham êxito consistentemente

Os portões de liberação permitem a avaliação automática dos critérios de integridade antes que uma versão seja promovida para o próximo ambiente. Por padrão, a versão progride após um exemplo bem-sucedido para todos os portões ter sido recebido. Mesmo que um portão seja irregular e o exemplo bem-sucedido recebido seja ruído, a versão progride. Para evitar esses tipos de problemas, agora você pode configurar a versão para verificar a consistência da integridade por uma duração mínima antes de progredir. Em tempo de execução, a versão garantiria que as avaliações consecutivas dos portões fossem bem-sucedidas antes de permitir a promoção. O tempo total para avaliação depende de "tempo entre reavaliação" e normalmente seria maior do que a duração mínima configurada. Consulte a documentação Liberar controle de implantação de implantação usando portões para obter mais informações.

Implantar automaticamente em novos destinos em um grupo de implantação

Anteriormente, quando novos destinos eram adicionados a um grupo de implantação, era necessária uma implantação manual para garantir que todos os destinos tivessem a mesma versão. Agora você pode configurar o ambiente para implantar automaticamente a última versão bem-sucedida nos novos destinos. Consulte a documentação Grupos de Implantação para obter mais informações.

Implantar continuamente builds marcados pelo processamento pós-build

Os gatilhos de implantação contínua criam uma versão na conclusão do build. No entanto, às vezes, os builds são pós-processados e o build só deve ser liberado após a conclusão desse processamento. Agora você pode aproveitar as marcas de build, que seriam atribuídas durante o pós-processamento, nos filtros de gatilho da versão.

Definir uma variável no momento da versão

Em uma definição de versão, agora você pode escolher as variáveis que deseja definir ao criar a versão.

O valor fornecido para a variável quando a versão é criada é usado apenas para essa versão. Esse recurso ajudará você a evitar várias etapas para Criar em Rascunho, atualizar as variáveis no rascunho e disparar a versão com a variável .

Passar variáveis de ambiente para tarefas

Os autores de tarefas de CI/CD podem definir uma nova propriedade, showEnvironmentVariables, no task.json para passar variáveis de ambiente para tarefas. Quando você faz isso, um controle extra é renderizado na tarefa no editor de build. Isso está disponível para as tarefas powershell, cmd e bash .

Isso habilita dois cenários:

• Uma tarefa requer uma variável de ambiente com maiúsculas e minúsculas preservadas no nome da variável. Por exemplo, no exemplo acima, a variável de ambiente passada para a tarefa seria "foo" e não "FOO".
• Ele permite que os valores de segredos sejam passados de maneira segura para os scripts. Isso é preferido para passar os segredos como argumentos para os scripts, pois o sistema operacional no agente pode registrar a invocação de processos, incluindo seus argumentos.

Clonar grupos de variáveis

Adicionamos suporte para clonagem de grupos de variáveis. Sempre que quiser replicar um grupo de variáveis e apenas atualizar algumas das variáveis, você não precisará passar pelo processo tedioso de adicionar variáveis uma a uma. Agora você pode fazer rapidamente uma cópia do grupo de variáveis, atualizar os valores adequadamente e salvá-lo como um novo grupo de variáveis.

Observação

Os valores da variável secreta não são copiados quando você clona um grupo de variáveis. Você precisa atualizar as variáveis criptografadas e salvar o grupo de variáveis clonados.

Ignorar um portão de lançamento para uma implantação

Os portões de liberação permitem a avaliação automática dos critérios de integridade antes que uma versão seja promovida para o próximo ambiente. Por padrão, o pipeline de lançamento progride somente quando todos os portões estiverem íntegros ao mesmo tempo. Em determinadas situações, como ao agilizar uma versão ou depois de verificar manualmente a integridade, um aprovador pode querer ignorar um portão e permitir que a versão progrida mesmo que esse portão ainda não tenha sido avaliado como íntegro. A documentação dos portões de lançamento para obter mais informações.

Executar testes adicionais usando um gatilho de liberação de solicitação de pull

Você conseguiu disparar um build com base em uma PR (solicitação de pull) e obter esse feedback rápido antes de uma mesclagem por um tempo. Agora você também pode configurar um gatilho de PR para uma versão. O status da versão será postado de volta no repositório de código e poderá ser visto diretamente na página pr. Isso será útil se você quiser executar testes funcionais ou manuais adicionais como parte do fluxo de trabalho de PR.

Criar conexão de serviço do Azure com a entidade de serviço que se autentica com um certificado

Agora você pode definir uma conexão de serviço do Azure com uma entidade de serviço e um certificado para autenticação. Com a conexão de serviço do Azure agora dando suporte à entidade de serviço que se autentica com um certificado, agora você pode implantar no Azure Stack configurado com o AD FS. Para criar uma entidade de serviço com autenticação de certificado, consulte o artigo sobre como criar uma entidade de serviço que se autentica com um certificado.

Executar em Pacote com suporte em implantações de Serviço de Aplicativo do Azure

A versão da tarefa Serviço de Aplicativo do Azure Deploy (4.*) agora dá suporte a RunFromPackage (anteriormente chamado runFromZip.

Serviço de Aplicativo dá suporte a várias técnicas diferentes para implantar seus arquivos, como msdeploy (também conhecido como WebDeploy), git, ARM e muito mais. Mas todas essas técnicas têm uma limitação. Seus arquivos são implantados na pasta wwwroot (especificamente d:\home\site\wwwroot) e o runtime executa os arquivos nela.

Com Run From Package, não há mais uma etapa de implantação que copie os arquivos individuais para wwwroot. Em vez disso, basta apontá-lo para um arquivo zip e o zip é montado em wwwroot como um sistema de arquivos somente leitura. Isso tem várias vantagens:

• Reduz o risco de problemas de bloqueio de cópia de arquivo.
• Pode ser implantado em um aplicativo de produção (com reinicialização).
• Você pode ter certeza dos arquivos que estão em execução no seu aplicativo.
• Melhora o desempenho de implantações de Serviço de Aplicativo do Azure.
• Pode reduzir os tempos de inicialização a frio, particularmente para as funções de JavaScript com árvores de pacote npm grandes.

Implantar contêineres do Linux com a tarefa Implantação do Servidor de Aplicativos

A versão 4.* da tarefa implantar Serviço de Aplicativo do Azure agora dá suporte à implantação de seu próprio contêiner personalizado para Azure Functions no Linux.

O modelo de hospedagem do Linux para Azure Functions é baseado em contêineres do Docker que trazem maior flexibilidade em termos de empacotamento e aproveitando dependências específicas do aplicativo. As funções no Linux podem ser hospedadas em dois modos diferentes:

1. Imagem de contêiner interno: Você traz o código do Aplicativo de Funções e o Azure fornece e gerencia o contêiner (modo de imagem interno), portanto, nenhum conhecimento específico relacionado ao Docker é necessário. Isso tem suporte na versão existente da tarefa Implantar Serviço de Aplicativo.
2. Imagem de contêiner personalizada: Aprimoramos a tarefa implantar Serviço de Aplicativo para dar suporte à implantação de imagens de contêiner personalizadas em Azure Functions no Linux. Quando suas funções precisam de uma versão de linguagem específica ou exigem uma dependência ou configuração específica que não é fornecida dentro da imagem interna, você pode criar e implantar uma imagem personalizada no Azure Function no Linux usando o Azure Pipelines.

A tarefa Xcode dá suporte ao Xcode 10 recém-lançado

Coincidindo com o lançamento do Xcode 10 da Apple, agora você pode definir seus projetos para compilar ou ser testados especificamente com o Xcode 10. Seu pipeline também pode executar trabalhos em paralelo com uma matriz de versões Xcode. Você pode usar o pool de agentes macOS hospedado pela Microsoft para executar essas compilações. Consulte as diretrizes para usar o Xcode no Azure Pipelines.

Simplificar a implantação no Kubernetes usando o Helm

O Helm é uma ferramenta que simplifica a instalação e o gerenciamento de aplicativos kubernetes. Também ganhou muita popularidade e apoio da comunidade no último ano. Uma tarefa do Helm em Versão agora está disponível para empacotar e implantar gráficos do Helm no AKS (Serviço de Contêiner do Azure) ou em qualquer outro cluster do Kubernetes.

Com a adição dessa tarefa do Helm, agora você pode configurar um pipeline de CI/CD baseado em Helm para entregar contêineres em um cluster do Kubernetes. Confira a documentação Implantar usando o Kubernetes no Serviço de Contêiner do Azure para obter mais informações.

Controlar a versão do Helm usada na versão

A tarefa Instalador de Ferramentas do Helm adquire uma versão específica do Helm da Internet ou do cache de ferramentas e a adiciona ao PATH do agente (hospedado ou privado). Use essa tarefa para alterar a versão do Helm usada em tarefas subsequentes, como a tarefa da cli do .NET Core . Adicionar essa tarefa antes da tarefa Implantar do Helm em uma definição de build ou versão garante que você esteja empacotando e implantando seu aplicativo com a versão certa do Helm. Essa tarefa também ajuda a instalar opcionalmente a ferramenta kubectl , que é um pré-requisito para o Helm funcionar.

Implantar continuamente no Banco de Dados do Azure para MySQL

Agora você pode implantar continuamente em Banco de Dados do Azure para MySQL – banco de dados MySQL do Azure como um serviço. Gerencie seus arquivos de script MySQL no controle de versão e implante continuamente como parte de um pipeline de lançamento usando uma tarefa nativa em vez de scripts do PowerShell.

Usar tarefas baseadas em PowerShell remotas do Windows aprimoradas

Tarefas novas e aprimoradas baseadas no Windows Remote PowerShell estão disponíveis. Essas melhorias incluem várias correções de desempenho e dão suporte a logs dinâmicos e comandos de saída do console, como Write-Host e Write-Output.

Tarefa PowerShell on Target (versão: 3.*): você pode adicionar script embutido, modificar opções de PSSession, controlar "ErrorActionPreference" e falhar no erro padrão.

Tarefa Cópia de Arquivo do Azure (versão: 2.*): é fornecida com o AzCopy mais recente (v7.1.0) que resolve um problema do GitHub.

Filtrar branches para o GitHub Enterprise ou artefatos externos do Git

Ao liberar do GitHub Enterprise ou repositórios Git externos, agora você pode configurar os branches específicos que serão lançados. Por exemplo, talvez você queira implantar somente builds provenientes de um branch específico para produção.

Criar aplicativos escritos em Go

Use a tarefa Go Tool Installer para instalar uma ou mais versões do Go Tool em tempo real. Essa tarefa adquire uma versão específica da Ferramenta Go necessária para seu projeto e a adiciona ao PATH do agente de build. Se a versão da Ferramenta Go direcionada já estiver instalada no agente, essa tarefa ignorará o processo de baixá-la e instalá-la novamente.

A tarefa Go ajuda você a baixar dependências, compilar ou testar seu aplicativo. Você também pode usar essa tarefa para executar um comando Go personalizado de sua escolha.

Executar scripts python embutidos ou baseados em arquivo em seu pipeline

Uma nova tarefa script python simplifica a execução de scripts python em seu pipeline. A tarefa executará um script de um arquivo Python (.py) em seu repositório ou você poderá inserir manualmente um script nas configurações da tarefa, para salvar como parte do pipeline. A tarefa usará a versão do Python no caminho ou você poderá especificar um caminho absoluto para um interpretador do Python a ser usado.

Aproveitar a saída de teste e compilação do Xcode aprimorada do xcpretty

xcpretty aprimora a legibilidade da saída do xcodebuild e gera resultados de teste no formato JUnit. A tarefa de build do Xcode agora usa automaticamente xcpretty quando está disponível no computador do agente, pois está em agentes macOS hospedados. Embora a saída xcpretty possa ser diferente e menos detalhada do que a saída do xcodebuild, disponibilizamos os logs xcodebuild completos com cada build.

Test Plans

Cliente do Test Runner (Azure Test Plans) para executar testes manuais para aplicativos da área de trabalho

Agora você pode usar o cliente test runner (Azure Test Plans) para executar testes manuais para aplicativos da área de trabalho. Isso ajudará você a mudar do Microsoft Test Manager para o Azure Test Plans. Consulte nossas diretrizes aqui. Usando o cliente test runner, você pode executar seus testes manuais e registrar os resultados do teste para cada etapa de teste. Você também tem recursos de coleta de dados, como captura de tela, log de ações de imagem e gravação de vídeo de áudio. Se você encontrar um problema ao testar, use o Test Runner para criar um bug com etapas de teste, capturas de tela e comentários incluídos automaticamente no bug.

O Executor de Teste (Azure Test Plans) requer um download único e uma instalação do executor. Selecione Executar para aplicativo da área de trabalho , conforme mostrado abaixo.

Artifacts

Fontes upstream

Azure DevOps Server 2019 traz atualizações substanciais para as fontes de upstream disponíveis nos feeds do Azure Artifacts:

• Você pode adicionar nuget.org fontes upstream a feeds existentes criados em versões anteriores do TFS. Procure a faixa acima dos pacotes do feed para obter mais informações, incluindo alterações de comportamento que você deve estar ciente antes de atualizar.
• Você pode adicionar outros feeds Azure DevOps Server como fontes de upstream ao feed, o que significa que você pode usar pacotes NuGet e npm desses feeds por meio do feed.

Também introduzimos uma nova função no Azure Artifacts: "Colaborador". Um Colaborador pode salvar pacotes de uma fonte de upstream, mas não pode publicar pacotes diretamente no feed (por exemplo, usando a publicação de nuget). Isso permite restringir a publicação de pacotes a um usuário confiável ou ao sistema de build, permitindo que seus engenheiros usem novos pacotes de suas fontes de upstream.

Seguir pacotes

Facilitamos ainda mais a configuração de notificações com um novo botão Seguir diretamente em cada pacote. O botão Seguir também é compatível com exibições de versão. Se você seguir um pacote enquanto o examina por meio de um modo de exibição, você só receberá atualizações para novas versões promovidas para esse modo de exibição.

Alterar as configurações do feed sem precisar salvar manualmente

Algumas das interações na página de configurações do feed foram aprimoradas. Agora, as alterações feitas, como a adição de um upstream ou uma permissão, são salvas imediatamente. Isso significa que você não precisa se preocupar com a perda de alterações ao alternar entre as configurações dinâmicas.

Simplificar a autenticação com o novo Provedor de Credenciais multiplataforma para NuGet

Interagir com feeds do NuGet autenticados ficou muito melhor. O novo Provedor de Credenciais do Azure Artifacts baseado no .NET Core funciona com msbuild, dotnet e nuget(.exe) no Windows, macOS e Linux. Sempre que você quiser usar pacotes de um feed do Azure Artifacts, o Provedor de Credenciais adquirirá e armazenará automaticamente um token em nome do cliente NuGet que você está usando. Você não precisa mais armazenar e gerenciar manualmente um token em um arquivo de configuração.

Para obter o novo provedor, vá para o GitHub e siga as instruções para seu cliente e plataforma.

Compactar símbolos ao publicar em um compartilhamento de arquivos

Atualizamos a tarefa Símbolos de Publicação de Índice & para dar suporte a símbolos de compactação quando eles são publicados em um compartilhamento de arquivos.

Wiki

Publicar arquivos markdown de um repositório Git como um Wiki

Os desenvolvedores criam documentação para "APIs", "SDKs" e "documentos de ajuda explicando o código" em repositórios de código. Em seguida, os leitores precisam examinar o código para encontrar a documentação certa. Agora você pode simplesmente publicar arquivos markdown de repositórios de código e hospedá-los no Wiki.

No Wiki, comece clicando em Publicar código como wiki. Em seguida, você pode especificar uma pasta em um repositório Git que deve ser promovida.

Depois de clicar em Publicar, todos os arquivos markdown na pasta selecionada serão publicados como um wiki. Isso também mapeará o cabeçalho do branch para o wiki para que todas as alterações feitas no repositório Git sejam refletidas imediatamente.

Confira a postagem no blog da documentação do produto para obter mais informações.

Link para títulos dentro de uma página

Agora você pode clicar no ícone de link ao lado de qualquer título de seção em uma página wiki para gerar uma URL diretamente para essa seção. Em seguida, você pode copiar essa URL e compartilhá-la com os membros da equipe para vinculá-las diretamente a essa seção.

Anexar arquivos e imagens em pastas

Ao editar páginas wiki offline, pode ser mais fácil adicionar anexos e imagens de arquivo no mesmo diretório que a página wiki. Agora, você pode adicionar um anexo ou uma imagem em qualquer pasta no wiki e vinculá-lo à sua página.

Inserir um vídeo na wiki

Agora você pode inserir vídeos em uma página wiki de serviços online como Microsoft Stream e YouTube. Você pode adicionar a URL de vídeo inserida usando a seguinte sintaxe:

::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::

Renomear uma wiki

Agora você pode renomear seu wiki na interface do usuário wiki e usando APIs REST. No menu Mais , clique em Renomear wiki para dar um nome memorável ao wiki.

Abrir página na nova guia

Agora você pode clicar com o botão direito do mouse em uma página wiki e abri-la em uma nova guia ou simplesmente pressionar CTRL + clique com o botão esquerdo do mouse em uma página wiki para abri-la em uma nova guia.

Reter caracteres especiais em títulos de página wiki

Agora você pode criar páginas wiki com caracteres especiais, como : < > * ? | -. Agora páginas com títulos como "Perguntas frequentes?" ou "Guia de configuração" pode ser criado no Wiki. Os seguintes caracteres são traduzidos para suas cadeias de caracteres codificadas em UTF-8:

Caractere	Cadeia de caracteres codificada
:	%3A
<	%3C
>	%3E
*	%2A
?	%3F
|	%7C
-	%2D

Exibir links desfeitos

Todos os links em um wiki que não estão vinculados corretamente aparecerão em uma cor vermelha distinta e ícone de link desfeito, fornecendo uma pista visual de todos os links quebrados em uma página wiki.

Corrigir links quebrados ao mover páginas

Links de páginas desfeitos são uma das principais causas de baixa qualidade de página em qualquer solução de documentação. Anteriormente no Wiki, quando você moveu uma página dentro da estrutura de árvore ou renomeou uma página, ela poderia potencialmente quebrar links para a página de outras páginas e itens de trabalho. Agora, você pode marcar e corrigir links antes que eles sejam quebrados.

Importante

Lembre-se de usar a []() sintaxe markdown para links em páginas e o tipo de link de página Wiki em itens de trabalho para permitir que o Wiki encontre e corrija esses links potencialmente desfeitos. URLs de texto sem formatação e hiperlinks em itens de trabalho não serão captados por esse recurso.

Ao renomear ou mover uma página, você será solicitado a marcar para links absolutos ou relativos afetados.

Em seguida, você verá uma lista dos links de Página e Itens de trabalho afetados antes de executar uma ação.

Criar sumário para páginas wiki

Às vezes, as páginas wiki podem ficar longas, com o conteúdo organizado em vários títulos. Agora você pode adicionar um sumário a qualquer página que tenha pelo menos um título usando a [[_TOC_]] sintaxe .

Você também pode inserir um sumário clicando no botão apropriado no painel de formato ao editar a página.

Consulte a documentação de diretrizes de markdown para obter mais informações sobre como usar markdown no Azure DevOps.

Metadados do Surface para páginas wiki e visualização de código usando marcas YAML

Adicionar metadados à documentação pode ajudar os leitores e os índices de pesquisa a captar e exibir conteúdo significativo. Nesta atualização, qualquer arquivo que contenha um bloco YAML no início do arquivo será transformado em uma tabela de metadados de uma cabeça e uma linha. O bloco YAML deve assumir a forma de conjunto YAML válido entre linhas triplas tracejadas. Ele dá suporte a todos os tipos de dados básicos, lista, objeto como valor. Há suporte para a sintaxe no Wiki e na visualização do arquivo de código.

Exemplo de marcas YAML:

---
tag: post
title: Hello world
---

Exemplo de marcas YAML com lista:

---
tags:
- post
- code
- web
title: Hello world
---

Publicar código como wiki com permissões de Colaboração

Anteriormente, somente os usuários que tinham a permissão Criar Repositório em um repositório git eram capazes de publicar código como wiki. Isso tornou os administradores ou criadores do repositório um gargalo para quaisquer solicitações para publicar arquivos markdown hospedados em repositórios git como wikis. Agora, você pode Publicar código como wiki se tiver apenas a permissão Contribuir no repositório de código.

Relatórios

A extensão do marketplace de Análise para relatórios agora está disponível

A extensão do Marketplace de Análise agora está disponível para Azure DevOps Server. A análise é o futuro dos relatórios para o Azure DevOps e Azure DevOps Server. A instalação da extensão do Analytics fornece widgets avançados, integração do Power BI e acesso OData.

Para obter mais informações, marcar o Que é Análise e o Roteiro de Relatórios. A análise está em Visualização Pública. Atualmente, ele contém dados para boards e resultados de teste automatizado por meio de pipelines. Consulte Dados disponíveis no Serviço de Análise.

Investigar o histórico de build por meio de um novo widget de dashboard de build

Temos um widget de histórico de build novo e aprimorado que você pode adicionar aos seus painéis. Com esse widget, agora você pode exibir um histórico de builds de um branch específico em seu dashboard e configurá-lo em um projeto público para visitantes anônimos.

Importante

Se você estiver procurando insights sobre seus builds XAML, continue usando o widget mais antigo e leia sobre como migrar de builds XAML para novos builds. Caso contrário, recomendamos que você mude para o widget mais recente.

---

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