Azure DevOps Server Notas de versão de 2019

Requisitos | do sistema da comunidade | de desenvolvedores Termos | de licença DevOps Blog | Hashes SHA-1

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

Para saber mais sobre como instalar ou atualizar uma implantação Azure DevOps Server, consulte Azure DevOps Server Requisitos. Para baixar produtos do Azure DevOps, visite a página Downloads do Azure DevOps Server.

A atualização direta para Azure DevOps Server 2020 tem suporte de 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, confira Instalar e configurar o Azure DevOps local.

---

Atualizar com segurança de Azure DevOps Server 2019 para Azure DevOps Server 2020

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

Azure DevOps Server 2020 lida com a retenção de build de forma diferente, com base nas 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 são 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 de Azure DevOps Server 2019 para Azure DevOps Server 2020.

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 16: 14 de novembro de 2023

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

• Estendida a lista de caracteres permitidos de tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas do shell.

Instalar patches

Configurar o TFX

1. Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.

Atualizar tarefas usando o TFX

Arquivo	Hash SHA-256
Tasks20231103.zip	389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5

1. Baixe e extraia Tasks20231103.zip.
2. Altere o diretório para os arquivos extraídos.
3. Execute os seguintes comandos para carregar as tarefas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.230.0.zip
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.230.0.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.230.0.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.230.0.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.230.0.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.230.0.zip 

Requisitos de pipeline

Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true precisa ser definida em pipelines que usam as tarefas afetadas.

• No clássico:

  Defina a variável na guia Variável do pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 15: 12 de setembro de 2023

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

• CVE-2023-33136: vulnerabilidade de execução de código remoto do Azure DevOps Server.
• CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.

Instalar patches

1. Baixe e instale Azure DevOps Server 2019.0.1 Patch 15.

Atualizar o agente do Azure Pipelines

1. Baixe o agente em: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 – Agent_20230825.zip
2. Use as etapas descritas na documentação de agentes auto-hospedados do Windows para implantar o agente.  

Configurar o TFX

1. Siga as etapas da documentação de upload de tarefas para a coleção de projetos para instalar a tfx-cli e fazer logon com ela.

Atualizar tarefas usando o TFX

1. Baixe e extraia Tasks_20230825.zip.
2. Altere o diretório para os arquivos extraídos.
3. Execute os seguintes comandos para carregar as tarefas:

tfx build tasks upload --task-zip-path AzureFileCopyV1.1.226.3.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV2.2.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV3.3.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV4.4.226.2.zip 
tfx build tasks upload --task-zip-path AzureFileCopyV5.5.226.2.zip 
tfx build tasks upload --task-zip-path BashV3.3.226.2.zip 
tfx build tasks upload --task-zip-path BatchScriptV1.1.226.0.zip 
tfx build tasks upload --task-zip-path PowerShellV2.2.226.1.zip 
tfx build tasks upload --task-zip-path SSHV0.0.226.1.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV1.1.226.2.zip 
tfx build tasks upload --task-zip-path WindowsMachineFileCopyV2.2.226.2.zip 

Requisitos de pipeline

Para usar o novo comportamento, uma variável AZP_75787_ENABLE_NEW_LOGIC = true precisa ser definida em pipelines que usam as tarefas afetadas.

• No clássico:

  Defina a variável na guia Variável do pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 14: 8 de agosto de 2022

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

• CVE-2023-36869: vulnerabilidade de falsificação do Azure DevOps Server.

Azure DevOps Server 2019.0.1 Data de lançamento do Patch 13: 17 de maio de 2022

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

• Revogação de todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário é desabilitada.

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.

• Resolução da vulnerabilidade do Elasticsearch pela remoção da classe jndilookup dos binários do 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 presente, 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 de atualização PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update, conforme fornecido no arquivo Leiame. Ele poderá retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização executa novas tentativas até que seja concluída.

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 presente, 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 em C:\Program Files\{TFS Version Folder}\Search\zip, para a pasta de arquivos remotos do Elasticsearch.
4. Execute Configure-TFSSearch.ps1 -Operation update no computador do servidor do 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.

• Corrija o erro da interface do usuário de definição de compilação.

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 confidenciais

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

Instalação da tarefa AzureResourceGroupDeploymentV2

Instalar

1. Extraia o pacote AzureResourceGroupDeploymentV2.zip para uma nova pasta em seu computador. Por exemplo: AzureResourceGroupDeploymentV2.

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

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar a 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 tfx login.

5. Execute o comando a seguir 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 do Azure DevOps Server
• CVE-2020-17135: vulnerabilidade de falsificação do Azure DevOps Server
• CVE-2020-17145: vulnerabilidade de falsificação do Azure DevOps Server e do Team Foundation Server
• Correção do problema com o TFVC não processando todos os resultados

Instalação geral de patches

Se você tiver Azure DevOps Server 2019.0.1, deverá instalar Azure DevOps Server 2019.0.1 Patch 9.

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 por padrão. Depois de instalar Azure DevOps Server 2019.0.1 Patch 9, a versão será 17.143.30723.4 .

Instalação da tarefa AzurePowerShellV4

Pré-requisitos

1. Instale o módulo Az do Azure PowerShell do Azure Powershell em seu computador de agente privado.

2. Crie um pipeline com a tarefa AzurePowerShellV4 . Você verá apenas uma falha em caso de erro padrão na tarefa.

Instalar

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

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

3. Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar a 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 tfx login.

5. Execute o comando a seguir 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 às 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 fonte do Git.
• Correção do erro ao alterar a alteração da herança para On ou Off 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 limpa as entradas do usuário
• Adicionando suporte para SHA2 em 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

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 de 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 sã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 de cross-site scripting em pull requests

---

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

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 da Comunidade de Desenvolvedores.
• 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 uma estrela (*) que indica 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 eles poderem alterar as permissões ou não.
• Nas páginas de aterrissagem de Versões, a ação de iniciar versão de rascunho estava criando uma nova versão, mas agora ela 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 da Comunidade de Desenvolvedores.
• Usando a API de exclusão de caso de teste, os casos de teste podem ser excluídos de outros projetos. Relatado por meio da Comunidade de Desenvolvedores.
• 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 usuários que saem do Test Runner.
• O nome de usuário e o endereço de e-mail não são exibidos no menu suspenso do usuário no Test Runner.

Azure Artifacts

• Mover para cima e Mover para baixo não estão localizados em upstreams.

Análise

• Os relatórios do Analytics 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 diferentes fusos horários.
• 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 espremidos no IE quando não há espaço suficiente.

Administração

• Registro adicional adicionado à atualização da 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 deixa de responder quando o banco de dados de configuração está corrompido.
• Os ganchos de serviço podem não processar notificações corretamente.
• A indexação da Pesquisa de Código não é iniciada após a configuração da Pesquisa.
• Há strings 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 de teste do Visual Studio

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

---

Azure DevOps Server 2019 Data de lançamento do Patch 2: 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 de cross-site scripting no Test Plans
• CVE-2019-0971: vulnerabilidade de divulgação de informações confidenciais na API do Repos
• CVE-2019-0979: vulnerabilidade de cross-site scripting no hub de Usuário

---

Azure DevOps Server 2019 Data de lançamento do Patch 1: 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 de cross-site scripting no Pipelines
• CVE-2019-0868: vulnerabilidade de cross-site scripting no Pipelines
• CVE-2019-0869: vulnerabilidade de injeção de HTML em pipelines
• CVE-2019-0870: vulnerabilidade de cross-site scripting no Pipelines
• CVE-2019-0871: vulnerabilidade de cross-site scripting no Pipelines
• CVE-2019-0874: vulnerabilidade de script entre sites (XSS) 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

---

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

Resumo das novidades em Azure DevOps Server 2019 RC2

Adicionamos os seguintes recursos ao RC2:

• Vincular confirmações e solicitações de pull do GitHub Enterprise a itens de trabalho do Azure Boards
• Configurar builds usando YAML
• As anotações de cartão incluem bugs e tipos de item de trabalho personalizados
• Seletor de branch aperfeiçoado
• Alterações no licenciamento do pipeline de implantação do Artifacts and Release Management

---

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

Resumo das novidades em Azure DevOps Server 2019 RC1

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 já está disponível
• Suporte para Banco de Dados SQL do Azure
• Herança de processo em novas coleções
• Novo hub de Itens de Trabalho
• Novos hubs de Quadros, Backlogs e Sprints
• Novo hub de consultas
• Padronizar descrições de solicitação de pull usando modelos
• Altere a ramificação 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
• Visualize o progresso da versão
• Atualize localmente seu agente
• Expor progressivamente e fasear implantações usando portões de lançamento
• Fontes upstream
• Criar sumário para páginas wiki

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

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

---

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 é nossa primeira versão 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 em Azure DevOps Server 2019. Consulte nosso blog para obter mais informações.

Alterações no licenciamento do pipeline de implantação do Artifacts and 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 uso de licença de Artefatos agora será incluído na Licença Básica. Todos os usuários que tiverem 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 pipelines de implantação do Release Management. Assim como os Pipelines de Build, os Pipelines de Implantação de Gerenciamento de Versã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 os amplos recursos de backup e as opções de dimensionamento para atender às suas necessidades, reduzindo a sobrecarga administrativa da execução do serviço. Observe que sua VM de host deve estar localizada na mesma região do Azure que seu banco de dados para manter a latência baixa. Para obter mais informações, consulte a documentação.

APIs SOAP do modelo de objeto do cliente de teste e 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.

Herança de processo em novas coleções

A herança de 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.

Aqui está 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 em apresentar é o submenu meu trabalho . Ouvimos comentários de que, quando você está em uma parte do produto e deseja algumas informações de outra parte, não quer perder o contexto. Com esse novo recurso, você pode acessar esse submenu de qualquer lugar no produto e ele fornecerá uma visão rápida de 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 de cabeça para baixo em seu código, mas quiser verificar 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 os PRs atribuídos a mim. No submenu, você também tem acesso com um clique para exibir mais solicitações de pull:

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

Boards

Vincular confirmações e solicitações de pull do GitHub Enterprise a itens de trabalho do Azure Boards

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 ao 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.

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 de solicitação de pull ou descrição de 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 #20 para a confirmação no GitHub, que aparecerá na seção Desenvolvimento do item de trabalho. ​

Se as palavras "corrigir", "corrigir" ou "corrigido" precederem a menção do item de trabalho (como mostrado acima), o item de trabalho será movido para o estado concluído quando a confirmação for mesclada com o 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.

Novo hub de Itens de Trabalho

O Hub de Itens de Trabalho é o nosso novo hub que servirá como o lar 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 dar uma olhada rapidamente em 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 da sua lista podem ser vistas abaixo:

Se você quiser reduzir ainda mais o escopo de suas listas, poderá filtrar por tipo, atribuído a, estado, área, tags e palavra-chave. Depois de ter o modo de exibição de lista desejado, você pode 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á redimensioná-la facilmente na área do cabeçalho. Essas experiências podem ser vistas abaixo:

Novos hubs de Quadros, 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 abrigava muitos recursos. Isso geralmente dificultava a localização do recurso ou funcionalidade que os usuários estavam procurando. Para resolver esse problema, dividimos o hub de pendências em:

• O hub de pendências agora abriga apenas as 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 de Quadros abriga todos os Quadros Kanban para um projeto. Os quadros são usados para comunicar o status e o fluxo. Os cartões (itens de trabalho) se movem da esquerda para a direita no quadro por meio de colunas definidas pela equipe.
• O novo hub Sprints abriga 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 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, além de fornecer 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 a última modificação por informações e a capacidade de pesquisar consultas
• Trilha de navegação 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 empolgantes 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ê 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, confira 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 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 sua escolha em sua lista de pendências de sprint.
• Use filtros para Destinatário, Tipo de Item de Trabalho, Estado e Marcas para adaptar as exibições às suas necessidades.

Novas páginas do diretório

Todos os novos hubs, incluindo listas de pendências, quadros e sprints, agora têm novas páginas de diretório organizadas com as seguintes seções:

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

Novo menu Opções de Visualizaçã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 listas de pendências ou alterar a opção Agrupar por em um painel de tarefas, para ativar o painel lateral para mapeamento e planejamento de sprints ou para explorar gráficos de detalhes do trabalho.

Leia mais sobre essas atualizações empolgantes, o novo painel de perfil da equipe e os 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ões são adoradas por sua visualização intuitiva da lista de verificação e interação. Anteriormente, as anotações de cartão eram limitadas a tipos de nível de lista de pendências padrão e não davam suporte a bugs ou tipos personalizados. Com a nova versão, removemos a restrição de 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 quadro 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 para o item de trabalho estã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 Á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.

Consultar o trabalho em todo o cronograma de iteração com +/- @CurrentIteration

A @CurrentIteration macro que ajuda sua equipe a acompanhar o trabalho com base em seu cronograma de iteração agora dá suporte ao deslocamento de inteiro. Acompanhe facilmente o trabalho que não foi fechado com @CurrentIteration - 1 ou olhe para 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 agendas de iteração de consulta com o @CurrentIteration parâmetro Team

Se você já usou a @CurrentIteration macro em consultas no passado, deve ter notado que os resultados podem variar se o contexto da equipe for alterado entre as equipes com diferentes agendamentos de iteração. 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 de itens de trabalho em dois projetos de equipe diferentes usando nomes de iteração e até mesmo agendamentos diferentes. Isso significa que não é mais necessário 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 para o trabalho dessa equipe. No entanto, se você quisesse escrever uma consulta para uma equipe, teria 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ê referenciar facilmente os caminhos de área pertencentes à equipe especificada.

Consulta de campos de rich text vazios

Localize 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 na vinculação e mencione experiências

Quando você deseja vincular dois itens de trabalho existentes, agora 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 pela pesquisa

Anteriormente, um item de trabalho não podia ser aberto na página de resultados da pesquisa se o painel de visualização do item de trabalho estivesse desativado. Isso dificultaria a análise 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 branch aperfeiçoado

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 grande número de filiais, estamos lançando um novo seletor de filiais. O seletor agora permite que você selecione suas ramificações favoritas ou pesquise rapidamente uma ramificação.

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 o recurso 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 Uma solicitação de pull é criada ou atualizada 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 - revertendo uma alteração que causou uma quebra de build, aplicando um hotfix no meio da noite, etc. Anteriormente, oferecíamos uma permissão ("Isento da 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 diretamente para a filial, 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 desvio. 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" nas 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 bypass quando necessário, mas ainda terá a proteção contra push acidental para uma ramificação com políticas.

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

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

Escrever 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) com 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 da PR.

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

Quando lançamos a experiência de PR (solicitação de pull) pela primeira vez, achamos que faria sentido atribuir todas as PRs ao contexto de equipe que você selecionou 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 RP.

Como parte das novas alterações de navegação, aproveitamos a oportunidade para alterar essa associação padrão com as equipes. Você notará 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 aos PRs recentemente. A política de revisores necessários 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ídas a qualquer uma de suas equipes. A seção também é personalizável - basta clicar na ação "Personalizar esta visualizaçã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 em 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 tornar mais fácil para as equipes escreverem ótimas descrições, 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 de criação de PR. Basta clicar no botão Adicionar um modelo para escolher qualquer modelo no repositório para anexá-lo à descrição da PR.

Também há suporte para modelos específicos de branch se você quiser aplicar um modelo diferente para uma PR em um branch específico ou pasta de branch. Por exemplo, se você quiser ter um modelo específico para todos os branches que começam com "hotfix/", poderá 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.

Altere a ramificação de destino de uma solicitação de pull

Para a maioria das equipes, quase todas as solicitações de pull têm como alvo 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 o "redirecionamento" de uma solicitação 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 recursos que contém alguns recursos dos quais suas alterações dependem. Você deseja revisar suas alterações dependentes isoladamente de outras alterações na ramificação de recursos, portanto, você direciona features/new-featureinicialmente . 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 um PR ativo e fosse mesclado antes de main suas alterações? Anteriormente, você teria que abandonar suas alterações e criar uma nova PR em main, ou mesclar sua PR em features/new-feature, e então 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 do 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 o PR, o que facilita a análise de diffs anteriores antes da alteração do branch de destino.

Criadores 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, null será retornado.

Aqui está um exemplo de extensão 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.

Gerencie melhor os e-mails de conclusão de compilação e implantação usando 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, termos diferentes foram usados historicamente para conceitos semelhantes. Em outros casos, os significados dos termos eram vagos. Por exemplo, informar 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 que é executado na infraestrutura hospedada na nuvem gerenciada pela Microsoft.
Agente privado	Agente auto-hospedado	Um agente de compilação/versão que é 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 compilações ou versões.
Fila de agentes	Pool de agentes	Um conjunto de computadores de agente no nível do projeto que pode executar compilações 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 completo de etapas de compilação para um aplicativo.
Build	Build	Uma instância de um pipeline de build que está em execução ou foi executado.
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 gráfico de vários trabalhos.
Definição de liberação	Pipeline de lançamento	Um conjunto completo de etapas de lançamento para um aplicativo a 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 versão por vez em sua organização. Com mais trabalhos paralelos disponíveis, você pode executar mais trabalhos de build e versão 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 de 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 redesenhada está disponível para a página de aterrissagem de lançamento. Veja uma lista dos pipelines de lançamento que você lança com frequência à esquerda. Você também pode pesquisar seus pipelines e adicioná-los aos 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

A nova visualização do progresso da versão oferece atualizações ao vivo do progresso da implantação e acesso com um clique a mais detalhes. A nova exibição visualiza o pipeline de lançamento, facilitando a compreensão do que está acontecendo e apresenta detalhes e ações apropriados em diferentes estágios do lançamento.

Pipeline, detalhes da versão e ambientes

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

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 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.

Confirmações e itens de trabalho

A cada nova versão, você pode ver a lista de commits 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 e logs da implantação

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 um modo de exibição que contém os logs, com foco no que está ativo no momento.

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

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

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

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

Resultados de 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 visualização contendo 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 de haver novos pontos de extensibilidade para permitir que os desenvolvimentos de extensões exibam 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 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 integrada, alteramos o comportamento padrão de todos os novos recursos que você cria (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á desativar o modelo de autorização padrão (veja a figura abaixo). Ao fazer 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 for adicionada ao arquivo YAML.

Encadear builds relacionados 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. As equipes normalmente gerenciam essas dependências manualmente.

Agora você pode acionar uma compilação após a conclusão bem-sucedida de outra compilação. Os 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.

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

Atualize localmente seu agente

Às vezes, as tarefas que você instala da Galeria 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 Azure DevOps Server para procurar os arquivos de pacote do agente em seu disco local em vez de na Internet. Isso oferece flexibilidade e controle sobre quais versões do agente você disponibiliza, sem precisar expor Azure DevOps Server à Internet.

URL do novo emblema de status de compilação

Os emblemas de build incorporados na página inicial de um repositório são uma maneira comum de mostrar a integridade do repositório. Embora tivéssemos emblemas de construção até agora, havia alguns problemas:

• O URL não era intuitivo
• O emblema não era específico de uma filial
• Não havia como um usuário clicar no emblema para levá-lo à versão mais recente dessa definição

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

Para compatibilidade com versões anteriores, continuaremos a honrar os URLs de emblema de compilação mais antigos também.

Adicionar contadores de build personalizados ao seus builds

Os contadores de build fornecem uma maneira de numerar e rotular builds de forma exclusiva. Anteriormente, você podia 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 compilação que são incrementadas automaticamente toda vez que você executa uma compilação. Você faz 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 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 do número de compilação e é redefinido automaticamente sempre que há um novo prefixo no número da compilação.
• 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 que foram 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.

Conformidade com a Azure Policy e validações de segurança nos pipelines

Queremos garantir a estabilidade e a segurança do software no início do processo de desenvolvimento, ao mesmo tempo em que reunimos 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 o 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 relevantes relacionados à política em caso de violações durante a implantação de modelos do ARM.

Além disso, adicionamos o modelo de definição de versão do Azure Policy. 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.

Compilar em plataformas Linux/ARM e Windows 32 bits

O agente multiplataforma de software livre do Azure Pipelines sempre teve suporte no 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, uma máquina Linux/ARM.

Experiências aprimoradas para testes em pipelines

A guia Testes agora tem uma experiência moderna que fornece informações de teste avançadas e contextuais 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 no contexto, relatório de execução de teste abortado e resumo de nível de execução.

Exibir a execução de testes em andamento

Testes, como testes funcionais e de integração, podem ser executados por um longo tempo, portanto, é importante ver a execução do teste a qualquer momento. Com o Modo de Exibição de Teste em Andamento, você não precisa mais esperar 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 realizar 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 o pipeline de build e lançamento usando a Tarefa de Teste do VS na fase de Vários Agentes, usando a Tarefa de Publicação de Resultados de Teste ou publicando resultados de teste usando APIs. No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.

A exibição abaixo mostra o resumo do teste em andamento na exibição de progresso da nova versão, relatando a contagem total de testes e o número de falhas de teste em um determinado momento.

Ao clicar no resumo do teste em andamento acima, você pode exibir o resumo detalhado do teste junto com as informações de teste com falha ou anuladas em Planos de teste. O resumo do teste é atualizado em intervalos periódicos com a capacidade de atualizar a exibição de detalhes sob demanda, com base na disponibilidade de novos resultados.

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

As mensagens de erro e os rastreamentos de pilha são longos por natureza e precisam de espaço suficiente para exibir os detalhes durante a depuração. Para ter uma experiência de depuração imersiva, agora você pode expandir a exibição de teste ou execução de teste para a exibição de página inteira, enquanto ainda pode executar as operações de contexto necessárias, como criação de bugs ou associação de requisitos para o resultado do teste atual.

Exibir histórico de testes no contexto

Historicamente, as equipes teriam que ir ao hub Runs para visualizar o histórico de um resultado de teste. Com a nova experiência, trazemos o histórico de testes diretamente no contexto na guia Planos de Teste para build e lançamento. As informações do histórico de teste são fornecidas de maneira progressiva, começando com a definição de compilação ou o ambiente atual para o teste selecionado, seguido por outras ramificações e ambientes para a compilação e a versão, respectivamente.

Exibir testes anulados

A execução do teste pode ser interrompida devido a vários motivos, como código de teste incorreto, origem em teste e problemas ambientais. Independentemente do motivo do aborto, é importante que você diagnostique o comportamento e identifique a causa raiz. Agora você pode exibir os testes anulados e as execuções de teste, juntamente com as execuções concluídas em Planos de Teste. No momento, o recurso está disponível para o 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 APIs. No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.

Rastreabilidade de teste 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 lançamento 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 em inglês, mas falhando em um ambiente que tem a 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.

Revise 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 orientados a dados). Uma vez que 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 do teste apresentados como uma hierarquia na guia Testes em uma versão. Vejamos um exemplo.

Anteriormente, introduzimos a capacidade de executar novamente testes com falha na tarefa VS Test . No entanto, relatamos apenas a última tentativa de 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 testes hierárquicos. Consulte a documentação da API de resultados de teste para obter mais informações.

Veja a análise de teste nos pipelines

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

Você pode agrupar os resultados do teste por vários elementos, identificar os principais testes para sua ramificação ou arquivos de teste ou fazer uma busca detalhada em um teste específico para exibir tendências e entender problemas de qualidade, como descamação.

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

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

Simplifique as 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 pode ser adicionada a cada fase sem agente nas definições. Isso significava que várias fases precisavam ser adicionadas quando havia mais de uma tarefa sem agente no processo, tornando a definição volumosa. Relaxamos 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 nas fases do agente. Consulte a documentação das fases do servidor para obter mais informações.

Expor progressivamente e fasear 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 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 sejam bem-sucedidos de forma consistente

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 uma amostra bem-sucedida para todos os portões é recebida. Mesmo que uma porta seja errática e a amostra bem-sucedida recebida seja ruído, a liberação progride. Para evitar esses tipos de problemas, agora você pode configurar a versão para verificar a consistência da integridade por um período mínimo antes de progredir. Em tempo de execução, a versão garantiria que avaliações consecutivas dos portões fossem bem-sucedidas antes de permitir a promoção. O tempo total para avaliação depende do "tempo entre a reavaliação" e normalmente seria maior do que a duração mínima configurada. Consulte a documentação Controle de implantação de versã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, uma implantação manual era necessária 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 dos 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 após a conclusão da compilação. No entanto, às vezes, as compilações são pós-processadas e a compilação só deve ser liberada após a conclusão do processamento. Agora você pode aproveitar as tags 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 liberaçã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 Create-in-Draft, atualizar as variáveis no rascunho e acionar 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 compilação. Isso está disponível para as tarefas do Powershell, Cmd e Bash.

Isso permite 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 é preferível a 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 você quiser replicar um grupo de variáveis e apenas atualizar algumas das variáveis, não precisará passar pelo tedioso processo de adicionar variáveis uma a uma. Agora você pode fazer uma cópia rápida do seu grupo de variáveis, atualizar os valores adequadamente e salvá-lo como um novo grupo de variáveis.

Ignorar um portão de liberação 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 estão íntegros ao mesmo tempo. Em determinadas situações, como ao agilizar uma versão ou após verificar manualmente a integridade, um aprovador pode querer ignorar um portão e permitir que o lançamento progrida, mesmo que esse portão ainda não tenha sido avaliado como íntegro. A documentação de 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 pode ser visto diretamente na página PR. Isso é útil se você quiser executar testes funcionais ou manuais adicionais como parte do fluxo de trabalho de PR.

Crie uma conexão de serviço do Azure com a entidade de serviço que 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 do Pacote compatível com as implantações do Serviço de Aplicativo do Azure

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

O 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 tempo de execução executa os arquivos a partir daí.

Com o Pacote Executar De, 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 das implantações do 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 de Implantação do Serviço de Aplicativo

A versão 4.* da tarefa de Implantação do Serviço de Aplicativo do Azure agora dá suporte à implantação de seu próprio contêiner personalizado no 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 aproveitamento de dependências específicas do aplicativo. As funções no Linux podem ser hospedadas em 2 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 específico relacionado ao Docker é necessário. Isso tem suporte na versão existente da tarefa de Implantação do Serviço de Aplicativo.
2. Imagem de contêiner personalizada: aprimoramos a tarefa de Implantação do Serviço de Aplicativo para dar suporte à implantação de imagens de contêiner personalizadas no 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 na imagem interna, você pode criar e implantar uma imagem personalizada no Azure Function no Linux usando o Azure Pipelines.

A tarefa Xcode é compatível com o recém lançado Xcode 10

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

Simplifique a implantação no Kubernetes usando o Helm

O Helm é uma ferramenta que agiliza a instalação e o gerenciamento de aplicativos Kubernetes. Também ganhou muita popularidade e apoio da comunidade no ano passado. Uma tarefa do Helm na 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 no Helm para entregar 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.

Versão do Control Helm usada na versão Release

A tarefa Instalador da Ferramenta 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 CLI do .NET Core. Adicionar essa tarefa antes da tarefa de implantação do Helm em uma definição de build ou versão garante que você esteja empacotando e implantando seu aplicativo com a versão correta do Helm. Essa tarefa também ajuda na instalação opcional da 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 no Banco de Dados do Azure para MySQL – o 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 aprimoradas baseadas no PowerShell remoto do Windows

Tarefas novas e aprimoradas baseadas no PowerShell remoto do Windows 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 do PowerShell no Destino (versão: 3.*): você pode adicionar script embutido, modificar opções PSSession, controlar "ErrorActionPreference" e falhar em caso de erro padrão.

Tarefa de 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 GitHub Enterprise ou artefatos externos do Git

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

Crie 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 o projeto e a adiciona ao PATH do agente de compilação. Se a versão de destino do Go Tool já estiver instalada no agente, essa tarefa ignorará o processo de download e instalação 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 de Script do Python simplifica a execução de scripts do 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 de seu pipeline. A tarefa usará a versão do Python no caminho ou você pode especificar um caminho absoluto para um interpretador Python a ser usado.

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

O 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 o xcpretty quando está disponível no computador do agente, como está em agentes macOS hospedados. Embora a saída do xcpretty possa ser diferente e menos detalhada do que a saída do xcodebuild, disponibilizamos os logs completos do xcodebuild com cada compilação.

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 migrar do Microsoft Test Manager para o Azure Test Plans. Consulte nossa orientação aqui. Usando o cliente do Test Runner, você pode executar seus testes manuais e registrar os resultados do teste para cada etapa do teste. Você também tem recursos de coleta de dados, como captura de tela, registro de ação de imagem e gravação de áudio e vídeo. 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 e uma instalação únicos 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 do Azure Artifacts:

• Você pode adicionar nuget.org fontes upstream a feeds existentes criados em versões anteriores do TFS. Procure o banner acima dos pacotes do seu feed para obter mais informações, incluindo mudanças 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 introduzimos uma nova função no Azure Artifacts: "Colaborador". Um Colaborador pode salvar pacotes de uma fonte upstream, mas não pode publicar pacotes de pacotes diretamente no feed (por exemplo, usando nuget publish). Isso permite que você restrinja a publicação de pacotes a um usuário confiável ou ao sistema de compilação, permitindo que seus engenheiros usem novos pacotes de suas fontes upstream.

Seguir pacotes

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

Altere 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 adicionar um upstream ou uma permissão, são salvas imediatamente. Isso significa que você não precisa se preocupar em perder alterações ao alternar entre os pivôs de configurações.

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

A interação com feeds 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, acesse 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 Index & Publish Symbols para dar suporte à compactação de símbolos 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. Os leitores precisam vasculhar o código para encontrar a documentação correta. 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.

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

Link para títulos em uma página

Agora você pode clicar no ícone de link ao lado de qualquer cabeçalho de seção em uma página wiki para gerar um URL diretamente para essa seção. Você pode copiar esse URL e compartilhá-lo com os membros da equipe para vinculá-los 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 da página wiki. Agora, você pode adicionar um anexo ou uma imagem em qualquer pasta do wiki e vinculá-lo à sua página.

Inserir um vídeo na wiki

Agora você pode incorporar vídeos em uma página wiki de serviços online, como Microsoft Stream e YouTube. Você pode adicionar o URL do vídeo incorporado 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 do wiki e usando APIs REST. No menu Mais, clique em Renomear wiki para dar um nome memorável à sua wiki.

Abrir página em 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 esquerdo em uma página wiki para abri-la em uma nova guia.

Manter caracteres especiais nos títulos das páginas Wiki

Agora você pode criar páginas wiki com caracteres especiais, como : < > * ? | -. Agora, páginas com títulos como "FAQ?" 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 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, dando a você uma pista visual de todos os links quebrados em uma página wiki.

Corrigir links quebrados ao mover páginas

Links de página quebrados são uma das principais causas de baixa qualidade de página em qualquer solução de documentação. Anteriormente, no Wiki, quando você movia uma página dentro da estrutura de árvore ou renomeava uma página, ela poderia 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.

Ao renomear ou mover uma página, você será solicitado a verificar se há links absolutos ou relativos afetados.

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

Criar sumário para páginas wiki

Às vezes, as páginas wiki podem ficar longas, com 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 o 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 o markdown no Azure DevOps.

Metadados de superfície para páginas wiki e visualização de código usando marcas YAML

Adicionar metadados à documentação pode ajudar os 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 um cabeçalho e uma linha. O bloco YAML deve assumir a forma de YAML válido definido entre linhas tracejadas triplas. Ele suporta todos os tipos de dados básicos, lista, objeto como valor. A sintaxe é suportada na visualização do arquivo Wiki e do arquivo de código.

Exemplo de tags YAML:

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

Exemplo de tags YAML com lista:

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

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

Anteriormente, apenas os usuários com permissão Criar repositório em um repositório git podiam publicar código como wiki. Isso tornou os administradores ou criadores do repositório um gargalo para quaisquer solicitações de publicação de 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.

Reporting

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

A extensão 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 com o Power BI e acesso OData.

Para obter mais informações, confira O que é Analytics e o roteiro de relatórios. O Analytics está em Visualização Pública. Atualmente, ele contém dados para Boards e resultados de testes automatizados por meio de pipelines. Consulte Dados disponíveis no Analytics Service.

Investigar o histórico de compilação por meio de um novo widget de painel de compilação

Temos um widget de histórico de compilação novo e aprimorado que você pode adicionar aos seus painéis. Com este widget, agora você pode visualizar um histórico de compilações de um branch específico em seu painel e configurá-lo em um projeto público para visitantes anônimos.

---

Comentários

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

---

Início da página