Notas de versão do Azure DevOps Server 2019

| Termos | Developer Community SystemRequirementsLicense | DevOps Hashes blogSHA-1 |

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 Azure DevOps Server Requisitos. Para baixar Azure DevOps produtos, visite a página Azure DevOps Server Downloads.

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

---

Atualizar com segurança do Azure DevOps Server 2019 para 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 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.

• Vulnerabilidade do Elasticsearch endereçada removendo a classe jndilookup de 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 de atualização 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 denominada 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.

• Corrigir o 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 em seu computador. Por exemplo: AzureResourceGroupDeploymentV2.

2. Baixe e instale Node.js 14.15.1 e npm (incluído com o Node.js download) 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 de 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: Azure DevOps Server vulnerabilidade de falsificação
• CVE-2020-17135: Azure DevOps Server vulnerabilidade de falsificação
• CVE-2020-17145: vulnerabilidade de falsificação de Azure DevOps Server e Team Foundation Server
• Corrigir 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 geral de patch

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 está instalado c:\Program Files\Azure DevOps Server 2019 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 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 pacote AzurePowerShellV4.zip para uma pasta chamada AzurePowerShellV4.

2. Baixe e instale Node.js 14.15.1 e npm (incluído com o Node.js download) 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 de 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 uma 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 2019.0.1 Data de lançamento do Patch 6: 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: verifique se Azure DevOps Server sanitiza 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: Elevação da vulnerabilidade de privilégio
• CVE 2020-0815: Elevação da vulnerabilidade de privilégio

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 3: 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

---

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 2: 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 estão autorizadas para todos os pipelines por padrão.

---

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 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 pacote cumulativo de correções de bugs. Ele inclui todas as correções nos patches Azure DevOps Server 2019 lançados anteriormente. Você pode instalar diretamente Azure DevOps Server 2019.0.1 ou atualizar de Azure DevOps Server 2019 ou 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 essa 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 esse 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 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 uma estrela (*) que indica a visualização, 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 poderem alterar as permissões ou não.
• Nas páginas de aterrissagem de Versões, a ação de lançamento inicial do 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.
• "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 caso de teste de exclusão, 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 status do caso de teste 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 exibidos na lista suspensa do usuário no Test Runner.

Azure Artifacts

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

Análise

• Relatórios de análise podem mostrar dados incompletos porque o modelo é 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 esquerdos são espremidos 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.
• Falha no serviço TfsJobAgent.
• A extensão Pesquisa não é instalada após a conclusão da configuração.
• O Console de Administração fica sem resposta quando o banco de dados 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ãocalizadas nos resultados das páginas de pesquisa.

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

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

Adicionamos suporte para Visual Studio 2019 à tarefa teste de Visual Studio em pipelines. Para executar testes usando a plataforma de teste para Visual Studio 2019, selecione as opções mais recentes ou Visual Studio 2019 na lista suspensa de versão da plataforma 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 HTML no 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 de XSS (script entre sites) no Pipelines
• CVE-2019-0875: Elevação da vulnerabilidade de privilégios em Boards

---

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 2019

Adicionamos os seguintes recursos ao RC2:

• Vincular GitHub Enterprise solicitações de confirmação e 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 ramificação aprimorado
• Alterações no licenciamento de pipeline de implantação de Artifacts 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 do Analytics 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 Boards, Backlogs 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 versão 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 um 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 Azure DevOps como a evolução de Visual Studio Team Services e 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 Azure DevOps e agora está disponível no Azure DevOps Server 2019. Consulte nosso blog para obter mais informações.

Alterações no licenciamento de pipeline de implantação de Artifacts e Release Management

Com base nos comentários dos usuários, estamos fazendo duas alterações importantes em nossas licenças com Azure DevOps Server 2019. Primeiro, os clientes não precisarão mais comprar a extensão artifact para usar Artifacts. Um Artifacts uso de licença 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 Artifacts. Em segundo lugar, os clientes não serão mais obrigados a comprar Release Management implantação Pipelines. Assim como o build Pipelines, 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 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 seu banco de dados para manter a latência baixa. Para saber mais, confira a documentação .

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

Azure DevOps Server 2019 continua a dar suporte ao item de trabalho que acompanha a API SOAP e o modelo de objeto 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 qual é 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 clicando apenas 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 deseja algumas informações de outra parte, não deseja perder o contexto. Com esse novo recurso, você pode acessar esse submenu de qualquer lugar do produto e ele fornecerá uma rápida olhada em informações cruciais, incluindo seus itens de trabalho, solicitações de pull e todos os favoritos. Com esse novo submenu, se você estiver em Repos cabeça para baixo em seu código, mas quiser verificar rapidamente em qual item de trabalho você deve trabalhar a seguir, 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 de meu trabalho mostrando os itens de trabalho atribuídos a mim:

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

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

Boards

Vincular GitHub Enterprise solicitações de confirmação e pull para Azure Boards itens de trabalho

Teams que usam 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 GitHub e Azure Boards, você pode obter todos os recursos, como backlogs, placas, 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 em GitHub.

Vincular confirmações e solicitações de pull a itens de trabalho é fácil. Mencione o item de trabalho usando a seguinte sintaxe:

AB#{work item ID}

Mencione um item de trabalho em uma mensagem de confirmação, título da solicitação pull ou descrição da solicitação de pull e Azure Boards criará um link para esse artefato. Por exemplo, considere uma mensagem de confirmação 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 "correção", "correções" ou "fixas" precedem a menção do item de trabalho (conforme mostrado acima), o item de trabalho será movido para o estado concluído quando a confirmação for mesclada ao branch padrão.

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

Hub Novos Itens de Trabalho

O Hub de Itens de Trabalho é nosso novo hub que servirá como a casa dos seus itens de trabalho! Aqui, você tem muitas exibições 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 recentemente atualizado , 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 reduzir ainda mais o escopo de suas listas, poderá filtrar o 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 Boards, Backlogs e Sprints

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

• O hub backlogs agora abriga apenas as pendências de um projeto. Uma lista de pendências é uma lista priorizada de trabalho para a equipe. Os backlogs fornecem ferramentas de planejamento, como hierarquia de itens de trabalho, previsão e nova experiência de planejamento de sprint.
• O novo hub de Boards abriga todos os Boards Kanban para um projeto. Boards são usados para comunicar o status e o fluxo. Cartões (itens de trabalho) se movem da esquerda para a direita através das 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 um backlog de sprint, um quadro de tarefas e uma exibição para gerenciar e definir a capacidade da 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 a obtenção das 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
• Breadcrumb 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 de 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 uma agenda de sprint existente diretamente do hub Sprints .
• Use o novo painel Planejamento em sua 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 opções na sua lista de pendências de sprint.
• Use filtros para Assignee, Tipo de Item de Trabalho, Estado e Marcas para personalizar os modos de exibição às suas necessidades.

Novas páginas do 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 | | de pendências Sprint) você estava ligado.
• Favoritos Todos os seus quadros favoritos, sprints e pendências em todas as equipes.
• Meu Todas as placas, pendências e sprints para equipes às quais você pertence.
• Todos Uma lista completa de todas as placas, pendências e sprints.

Menu Novas Opções de Exibição

Os novos hubs, incluindo Backlogs, Boards 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 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 explorar gráficos de detalhes do trabalho.

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

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 de lista de verificação intuitiva e interação. Anteriormente, as anotações de cartão eram limitadas a tipos de nível de backlog 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 de cartão.

As configurações de placa para anotações de cartão 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 são habilitadas, as contagens para esse tipo de item de trabalho são incluídas no cartão como uma lista de verificação separada.

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

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 de caminho de Área e Iteração 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 facilmente as guias 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ê tiver usado a @CurrentIteration macro em consultas no passado, talvez tenha notado que os resultados podem variar se o contexto de equipe for alterado entre Teams com agendamentos de iteração diferentes. Agora, ao criar ou modificar uma consulta com a @CurrentIteration macro, você também precisará selecionar 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 há mais necessidade de atualizar 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 backlogs, Boards, planos e até painéis para apenas o trabalho dessa equipe. Se você quisesse escrever uma consulta para uma equipe, porém, você tinha que 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ê fazer referência facilmente aos Caminhos de Área pertencentes à Equipe especificada.

Consulta para 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ê quiser 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, um item de trabalho não poderia ser aberto na página de resultados da pesquisa se o painel de visualização do item de trabalho estivesse desativado. Isso dificultaria a busca dos 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 ramificação 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 uma ramificação.

Receber notificações quando as políticas de solicitação de pull são 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 de email sempre que uma política for ignorada. Comece com a solicitação de pull A criada ou atualizada e selecione Ignorar Política na lista de filtros. As políticas de seleção 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 - revertendo uma alteração que causou uma quebra de build, aplicando 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 as 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 "Substituir" 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 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 contra 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 Permissão para "Isentos de imposição de política" receberão permissão para ambas as novas permissões, para que possam substituir a conclusão em PRs e enviar por 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 adiciona 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árias confirmações exigirão que os colaboradores insiram um título manualmente.

As descrições de 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 de 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 de PR.

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

Quando iniciamos a experiência de PR (solicitação de pull), achamos que faria sentido atribuir todos os PRs ao contexto de equipe selecionado ao criar a PR. Esse comportamento tem sido um ponto de frustração, já que muitas pessoas não perceberam 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 de 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 à seção antiga. No entanto, se você pertencer a várias equipes, esta seção mostrará PRs atribuídos 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 as coisas que devem ser feitas para cada alteração, como testar, adicionar testes de unidade e atualizar a documentação. Muitos de vocês têm solicitado 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 anexá-lo à descrição de PR.

Também há suporte para modelos específicos de ramificação se você quiser aplicar um modelo diferente para uma PR em um branch ou pasta de branch específico. Por exemplo, se você quiser ter um modelo específico para todos os branches que começam com "hotfix/", você pode adicionar um modelo que será usado para todos os 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 foi mesclado ou excluído. Considere um cenário no qual você tem uma PR direcionada a um branch de recursos que contém alguns recursos dos quais suas alterações dependem. Você deseja examinar suas alterações dependentes isoladamente de outras alterações no branch de recursos, para que você inicialmente features/new-featuredirecione. 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 recursos também tivesse uma PR ativa e fosse mesclado main antes de suas alterações? Anteriormente, você teria que abandonar suas alterações e criar uma nova PR mainem , ou mesclar sua PR e, em features/new-featureseguida, criar outra PR de features/new-feature .main Com essa nova ação para atualizar o branch de destino, você pode simplesmente alterar o branch de destino da PR para features/new-featuremain, preservando todo o contexto e comentários. Alterar o branch de destino cria até mesmo uma nova atualização para a PR, o que facilita a análise das diferenças anteriores antes da alteração do branch de destino.

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 estiver selecionado ou o serviço for acessado fora das páginas Azure Repos, o valor nulo será retornado.

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 lançando 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 seu status. Ele também inclui uma visualização da análise de teste para o pipeline selecionado.

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

Emails de conclusão de build e implantação foram atualizados para serem mais filtrados pelas 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 de Azure Pipelines unificada

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 em 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/lançamento que é 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 pode 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 versão 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 versão usando a nova página Versões

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

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

O novo modo de exibição de progresso da versão fornece atualizações dinâmicas do progresso da implantação e acesso de um clique a mais detalhes. O novo modo de exibição visualiza o pipeline de lançamento, tornando mais fácil entender o que está acontecendo e apresenta detalhes e ações apropriados em diferentes estágios da versão.

Pipeline, detalhes de versão e ambientes

O modo de exibição Pipeline mostra os artefatos da versão e os ambientes em que eles serão implantados. A área de 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 seu status, juntamente com o progresso detalhado. A qualquer momento, você pode acessar os logs clicando no link de status dentro do 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 andamento de aprovações e portões também aparecem no status do ambiente. Você pode agir ou exibir mais detalhes clicando no ícone de condição do ambiente pendurado no lado direito ou esquerdo do ambiente.

Confirmações e itens de trabalho

A cada nova versão, você pode ver a lista de confirmações e itens de trabalho associados 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 status do ambiente abre um modo de exibição que contém os logs, com foco no que está ativo no momento.

Você pode clicar nos logs para inserir um modo de exibição focado.

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

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

• Você precisa alternar para a tarefa "Windows Cópia de Arquivo do Computador" 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 computador ou nome do computador seguido pelas portas de gerenciamento remoto 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 contendo detalhes do teste, incluindo resultados de outras extensões que contribuem para o processo.

As extensões existentes funcionam nesse novo modo de exibição, além disso, há novos pontos de extensibilidade para permitir que as extensões se desenvolvam para fornecer 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 (consulte 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.

Compilações relacionadas à cadeia em conjunto 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 independentemente. Quando um componente upstream (uma biblioteca, por exemplo) é alterado, as dependências downstream precisam ser recompiladas e revalidadas. Teams normalmente gerenciam essas dependências manualmente.

Agora você pode disparar um build após a conclusão bem-sucedida de outro build. Artifacts produzido por um build upstream pode ser baixado e usado 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, um único build de várias fases pode atender às suas necessidades. No entanto, um gatilho de conclusão de build será útil se seus requisitos incluirem diferentes configurações, opções ou uma equipe diferente para possuir o processo dependente.

Atualizar localmente seu agente

As tarefas que você instala na 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 dessa versão, você pode configurar seu Azure DevOps Server procurar os arquivos de pacote do agente em seu disco local e não na Internet. Isso oferece flexibilidade e controle sobre quais versões de agente você disponibiliza, sem precisar expor sua Azure DevOps Server à Internet.

Nova URL de selo de status de build

Os selos de build inseridos na página inicial 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 uma ramificação
• 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 um status por branch e podem levar os usuários para o build mais recente do branch selecionado. Você pode obter o Markdown para a nova URL de selo de status selecionando a ação de menu de selo 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 toda vez que você executar um build. Você faz isso na guia variáveis de uma definição. Esse novo recurso oferece mais energia das seguintes maneiras:

• Você pode definir um contador personalizado e definir seu valor de semente. Por exemplo, você pode iniciar seu 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 no 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 no Linux/ARM e Windows plataformas de 32 bits

O Azure Pipelines código aberto, agente multiplataforma sempre teve suporte em 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, arquivar 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 do 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.

A exibição a seguir mostra o resumo do teste In-Progress no novo modo de 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 de 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 pode 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 ao Hub de Execuções para exibir o histórico de um resultado de teste. Com a nova experiência, trazemos o histórico de teste 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 inválido, 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 no Test Plans. No momento, o recurso está disponível para pipeline de build e lançamento usando a Tarefa de Teste do VS na fase do Multi Agent ou publicando resultados de teste usando API(s). No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.

Testar a rastreabilidade e o suporte a ambientes de versão 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 versão como pipelines de lançamento ou ambientes de teste e executando testes em tais 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á o status do resultado do teste mais recente e, se o teste tiver falhado nesse ambiente, você também encontrará a versão desde a qual o teste está falhando.

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 individuais do teste. Com essa atualização, apresentamos uma versão aprimorada dos resultados dos testes apresentados 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, só relatamos 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 de 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 do 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 no 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 pontuação.

Exibir análise de teste para builds e versão, 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 e executadas no servidor. As fases sem agente não exigem um agente ou computadores 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. Relaxamos essa restrição, que permite manter várias tarefas em fases sem agente. As tarefas na mesma fase seriam executadas sequencialmente, assim como fazem nas fases do 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 liberação

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 fora da caixa e você pode adicionar mais portões do Marketplace. Você poderá auditar se 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 depois que um exemplo bem-sucedido para todos os portões foi recebido. Mesmo que um portão esteja errático e a amostra bem-sucedida recebida seja o 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 o controle de implantação de versão usando a documentação de 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 de 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 tempo de lançamento

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 da tarefa 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. É preferível passar os segredos como argumentos para os scripts, uma vez que 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 você quiser replicar um grupo de variáveis e apenas atualizar algumas das variáveis, não precisará passar pelo processo tedioso de adicionar variáveis uma a uma. Agora você pode fazer rapidamente uma cópia do seu 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 só progride quando todos os portões estiverem íntegros ao mesmo tempo. Em determinadas situações, como ao agilizar uma liberação ou depois de verificar manualmente a integridade, um aprovador pode querer ignorar um portão e permitir que a liberaçã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ê foi capaz de 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 novamente 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 autenticada com um certificado.

Executar a partir do pacote com suporte em implantações 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 em sua pasta wwwroot (especificamente d:\home\site\wwwroot) e, em seguida, o runtime executa os arquivos a partir daí.

Com Run From Package, não há mais uma etapa de implantação que copia 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 Implantar servidor de aplicativo

A versão 4.* da tarefa Serviço de Aplicativo do Azure Implantar 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 baseia-se em contêineres do Docker que trazem maior flexibilidade em termos de empacotamento e aproveitamento de dependências específicas do aplicativo. As funções no Linux podem ser hospedadas em dois modos diferentes:

1. Imagem de contêiner interna: 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 relacionado ao Docker específico é necessário. Isso tem suporte na versão existente da tarefa de implantação de Serviço de Aplicativo.
2. Imagem de contêiner personalizada: Aprimoramos a tarefa Serviço de Aplicativo Implantar para dar suporte à implantação de imagens de contêiner personalizadas para Azure Functions no Linux. Quando suas funções precisam de uma versão de idioma 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 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 testado 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 em 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 do Kubernetes. Também ganhou muita popularidade e apoio da comunidade no último ano. Uma tarefa do Helm no Release 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 no Helm para fornecer contêineres em um cluster do Kubernetes. Consulte 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 Helm Tool Installer 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 na instalação opcional da ferramenta kubectl , que é um pré-requisito para o Helm funcionar.

Implantar continuamente em Banco de Dados do Azure para MySQL

Agora você pode implantar continuamente no 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 Windows remotas baseadas no PowerShell

Novas e aprimoradas Windows tarefas remotas baseadas no 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 GitHub.

Filtrar ramificações para artefatos git externos ou GitHub Enterprise

Ao liberar de 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 no 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 do Go Tool de destino já estiver instalada no agente, essa tarefa ignorará o processo de baixar e instalá-lo 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 xcodebuild e gera resultados de teste no formato JUnit. A tarefa de build do Xcode agora usa automaticamente o 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 de 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 do Test Runner (Azure Test Plans) para executar testes manuais para aplicativos da área de trabalho. Isso ajudará você a mudar do Gerenciador de Testes da Microsoft para Azure Test Plans. Consulte nossas diretrizes aqui. Usando o cliente do 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ção 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 Test Runner (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 upstream disponíveis em seus feeds de 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 upstream ao feed, o que significa que você pode usar pacotes NuGet e npm desses feeds por meio do feed.

Também apresentamos uma nova função em Azure Artifacts: "Colaborador". Um Colaborador pode salvar pacotes de uma fonte upstream, mas não pode publicar pacotes diretamente no feed (por exemplo, usando a publicação de nuget). Isso permite que você restrinja 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 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 melhoradas. Agora, as alterações feitas, como adicionar 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 os pivôs de configurações.

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

Interagir com feeds de NuGet autenticados ficou muito melhor. O novo Provedor de Credenciais Azure Artifacts baseado em .NET Core funciona com msbuild, dotnet e nuget(.exe) em Windows, macOS e Linux. Sempre que você quiser usar pacotes de um feed de 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 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 de markdown de um repositório Git como wiki

Os desenvolvedores criam documentação para "APIs", "SDKs" e "documentos de ajuda explicando 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 de markdown de repositórios de código e hospedá-los no Wiki.

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

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

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

Vincular a títulos em 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 de arquivo e imagens 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 ao wiki um nome memorável.

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 à esquerda 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 UTF-8:

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

Exibir links quebrados

Todos os links em um wiki que não estão vinculados corretamente aparecerão em uma cor vermelha distinta e ícone de link quebrado, 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 quebrados são uma das principais causas de má qualidade da página em qualquer solução de documentação. Anteriormente no Wiki, quando você moveu uma página dentro da estrutura da á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 verificar 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 localize e corrija esses links potencialmente quebrados. 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 verificar se há links absolutos ou relativos afetados.

Em seguida, você será mostrado uma lista dos links de página e itens de trabalho afetados antes de agir.

Criar um 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 leitores e í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 com traços triplos. Ele dá suporte a todos os tipos de dados básicos, lista, objeto como valor. Há suporte para a sintaxe no Wiki e na versão prévia 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 do Contribute

Anteriormente, somente usuários com 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 qualquer solicitação para publicar arquivos de markdown hospedados em repositórios git como wikis. Agora, você pode publicar o código como wiki se tiver apenas a permissão Contribuir no repositório de código.

Relatórios

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

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

Para obter mais informações, confira 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 painel de build

Temos um widget de histórico de build novo e aprimorado que você pode adicionar aos dashboards. Com esse widget, agora você pode exibir um histórico de builds de uma ramificação específica em seu painel e configurá-lo em um projeto público para visitantes anônimos.

Importante

Se você estiver procurando informações sobre seus builds XAML, continue a usar o widget mais antigo e leia sobre como migrar de builds XAML para novos builds. Caso contrário, recomendamos que você vá para o widget mais recente.

---

Comentários

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

---

Parte superior da página