Notas de versão do Azure DevOps Server 2019

Comunidade de Desenvolvedores | Requisitos de Sistema | Termos de Licença | Blog de DevOps | 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 do Azure DevOps Server, consulte Requisitos do Servidor de DevOps do Azure. Para baixar produtos do Azure DevOps, visite a página de Downloads do Azure DevOps Server .

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

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

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

O Azure DevOps Server 2020 gere a retenção de builds de maneira diferente, com base em políticas de retenção ao nível de pipeline. Determinadas configurações de política levam a que as execuções de pipeline sejam excluídas 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 de blog para obter mais informações sobre como atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020.

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

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

• Estendida a lista de caracteres permitidos para argumentos de tarefas do PowerShell em , habilitando a validação de parâmetros para tarefas do shell.

Instalar correções

Configurar TFX

1. Siga as etapas no para carregar tarefas para a documentação da coleção do projeto para instalar e fazer login com o tfx-cli.

Atualizar tarefas usando TFX

1. Faça o download 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 do canal de transmissão

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

• Sobre o clássico:

  Defina a variável na aba 'Variável' no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

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

Instalar correções

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

Atualizar o agente do Azure Pipelines

1. Faça o download do agente de: 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 Windows auto-hospedados para implantar o agente.  

Configurar TFX

1. Siga as etapas no para carregar tarefas para a documentação da coleção do projeto para instalar e fazer login com o tfx-cli.

Atualizar tarefas usando TFX

1. Faça o download 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 do canal de transmissão

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

• Sobre o clássico:

  Defina a variável na aba 'Variável' no pipeline.

• Exemplo de YAML:

variables: 
- name: AZP_75787_ENABLE_NEW_LOGIC 
  value: true 

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

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

• CVE-2023-36869: Vulnerabilidade de spoofing do servidor Azure DevOps.

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

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

• Revogue todos os tokens de acesso pessoal depois que a conta do Ative Directory de um usuário for desabilitada.

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

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

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

Etapas de instalação

1. Atualize o servidor com o Patch 12.
2. Verifique o valor do Registo 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 (Name = Version, Value = 5.4.1).
3. Execute o comando update PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation update conforme fornecido no arquivo readme. Ele pode retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização está executando novas tentativas até que seja concluída.

1. Atualize o servidor com o Patch 12.
2. Verifique o valor do Registo 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 (Name = Version, Value = 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 na máquina do servidor Elasticsearch.

Hash SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7

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

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

• Corrige o erro na interface de definição de build.

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

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

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

Para aplicar o Patch 10, terá de instalar a tarefa AzureResourceGroupDeploymentV2.

Instalação da tarefa AzureResourceGroupDeploymentV2

Instalar

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

2. Baixe e instale Node.js 14.15.1 e npm (incluído com o download Node.js) de acordo com sua máquina.

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

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso total e copie-o. Este token de acesso pessoal será usado ao executar o comando tfx login.

5. Execute o seguinte a partir do 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 seguinte comando para carregar a tarefa no servidor. Use o caminho do arquivo de .zip extraído da etapa 1.

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

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

Lançamos um patch para o Azure DevOps Server 2019.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

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

Instalação geral do patch

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

Verificando a instalação

• Opção 1: Executardevops2019.0.1patch9.exe CheckInstall , devops2019.0.1patch9.exe é o arquivo que é 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 ficheiro: [INSTALL_DIR]\Azure DevOps Server 2019\Application Tier\Web Services\bin\Microsoft.VisualStudio.Services.Feed.Server.dll. O Azure DevOps Server 2019 é instalado para c:\Program Files\Azure DevOps Server 2019 por padrão. Depois de instalar o 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 Azure PowerShell Az Azure Powershell em sua máquina de agente privado.

2. Crie uma 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 download Node.js) de acordo com sua máquina.

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

npm install -g tfx-cli

4. Crie um token de acesso pessoal com privilégios de acesso total e copie-o. Este token de acesso pessoal será usado ao executar o comando tfx login.

5. Execute o seguinte a partir do 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 seguinte comando 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 Patch 8 Data de lançamento: 8 de setembro de 2020

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• DTS 1713492 - Comportamento inesperado ao adicionar grupos do Active Directory a permissões de segurança.

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

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• CVE-2020-1326: Vulnerabilidade de script entre sites
• O pipeline de compilação mostra a conexão incorreta para usuários não autorizados ao selecionar Outra fonte Git.
• Corrija o erro ao alterar Inheritance para On ou Off na definição de compilação XAML.

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

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• CVE-2020-1327: Verifique se o Servidor de DevOps do Azure limpa as entradas do usuário
• Adicionando suporte para SHA2 em SSH no Azure DevOps

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

Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte. Consulte a postagem do blog para obter mais informações.

• 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 Patch 3 Data de lançamento: 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. Consulte a postagem do blog para obter mais informações.

• CVE-2019-1305: Vulnerabilidade de script entre sites (XSS) no Repos
• CVE-2019-1306: Vulnerabilidade de execução remota de código no Wiki

Azure DevOps Server 2019.0.1 Patch 2 Data de lançamento: 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. Consulte a postagem do blog para obter mais informações.

• 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 Patch 1 Data de lançamento: 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. Consulte a postagem do blog para obter mais informações.

• CVE-2019-1072: Vulnerabilidade de execução remota de código no controle de item de trabalho
• CVE-2019-1076: Vulnerabilidade de script entre sites (XSS) em pull requests

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

O 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 o Azure DevOps Server 2019.0.1 ou atualizar do Azure DevOps Server 2019 ou Team Foundation Server 2012 ou mais recente.

Esta 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 através da Comunidade de Desenvolvedores.
• ApiwitController.ExecuteQuery lança 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 incorporada 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 pré-visualização, mesmo que este recurso não esteja em fase de pré-visualização.
• Na guia Lançamentos , a ação para gerenciar a segurança agora é mostrada para todos os usuários, independentemente de eles poderem alterar as permissões ou não.
• Nas páginas iniciais de Releases, a ação de lançamento de rascunho inicial estava criando uma nova versão, mas agora ela inicia a versão de rascunho.

Planos de teste do Azure

• O filtro de 1 hora em TestRuns e TestResults CompletedDate são muito granulares.
• No tipo de item de trabalho Test Case , o tipo, "Test Case", não deve ser localizado.
• Os casos de teste não aparecem no MTM ou num navegador.
• Erro "Etapa de validação: você não tem permissão para disparar liberações no pipeline de liberação associado" ao executar testes automatizados de um plano de teste. Relatado através 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 através 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 os usuários que saem do Test Runner.
• O nome do utilizador e o endereço de e-mail não são exibidos no menu dropdown do utilizador no Test Runner.

Artefatos do Azure

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

Análises de Dados

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

Geral

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

Administração

• Log adicional adicionado à atualização da Collection 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 corretamente as notificações.
• A indexação da Pesquisa de Código não é iniciada após a configuração da Pesquisa.
• Há cadeias de caracteres não localizadas nos resultados das páginas de pesquisa.

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

Suporte para Visual Studio 2019 (VS2019) na tarefa 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 testes do Visual Studio 2019, selecione a opção Mais Recente ou Visual Studio 2019 na lista suspensa da versão da plataforma de testes.

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

Lançamos um patch de segurança para o Azure DevOps Server 2019 que corrige os seguintes bugs. Consulte a postagem do blog para obter mais informações.

• CVE-2019-0872: Vulnerabilidade de script entre sites (XSS) nos planos de teste
• CVE-2019-0971: Vulnerabilidade de divulgação não autorizada de informações na API Repos
• CVE-2019-0979: Vulnerabilidade de script entre sites (XSS) no hub do usuário

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

Lançamos um patch de segurança para o Azure DevOps Server 2019 que corrige os seguintes bugs. Consulte a postagem do blog para obter mais informações.

• CVE-2019-0857: Vulnerabilidade de falsificação no Wiki
• CVE-2019-0866: Vulnerabilidade de execução remota de código em Pipelines
• CVE-2019-0867: Vulnerabilidade de script entre sites (XSS) em Pipelines
• CVE-2019-0868: Vulnerabilidade de script entre sites (XSS) em Pipelines
• CVE-2019-0869: Vulnerabilidade de injeção de HTML em Pipelines
• CVE-2019-0870: Vulnerabilidade de script entre sites (XSS) em Pipelines
• CVE-2019-0871: Vulnerabilidade de script entre sites (XSS) em Pipelines
• CVE-2019-0874: Vulnerabilidade de script entre sites (XSS) em Pipelines
• CVE-2019-0875: Vulnerabilidade de elevação de privilégio em Boards

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

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

Resumo do que há de novo no Azure DevOps Server 2019 RC2

Adicionámos as seguintes funcionalidades ao RC2:

• Vincular solicitações de confirmação e recebimento do GitHub Enterprise para itens de trabalho do Azure Boards
• Configurar compilações usando YAML
• As notas de cartão incluem bugs e tipos de itens de trabalho personalizados
• Seletor de filiais melhorado
• Alterações no licenciamento do pipeline de implantação de artefactos e gestão de lançamentos

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

Resumo do que há de novo no Azure DevOps Server 2019 RC1

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

• Nova experiência de navegação
• A extensão de mercado do Google Analytics para relatórios já está disponível
• Suporte para o Banco de Dados SQL do Azure
• Processamento de herança em novas coleções
• Hub de Novos Itens de Trabalho
• Novos painéis, listas de pendências e hubs de Sprints
• Novo hub de Consultas
• Padronize descrições de solicitação pull usando modelos
• Alterar a ramificação de destino de uma solicitação pull
• Gerir pipelines de build usando a nova página de Compilações
• Gerencie pipelines de liberação usando a nova página Releases
• Visualize o progresso da versão
• Atualize localmente seu agente
• Expor progressivamente e fasear implantações usando portas de liberação
• Fontes a montante
• Criar índice para páginas wiki

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

• Geral
• Painéis
• Repos
• Pipelines
• Planos de Teste
• Artefatos
• Wiki
• Elaboração de Relatórios

Geral

Anunciando Azure DevOps Server

Em 10 de setembro, anunciamos o Azure DevOps como a evolução do Visual Studio Team Services e do Team Foundation Server. O Azure DevOps Server 2019 é a nossa primeira versão local com esta 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 implementada no serviço Azure DevOps e agora está disponível no Azure DevOps Server 2019. Consulte o nosso blog para mais informações.

Alterações no licenciamento do fluxo de trabalho de implantação de artefatos e no gerenciamento de lançamento.

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

Suporte para o 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 (S3 de Uso Geral e superior). Isso permitirá que você aproveite os extensos 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 Host deve estar localizada na mesma região do Azure que seu banco de dados para manter a latência baixa. Consulte a documentação de para obter mais informações.

Item de trabalho e APIs SOAP do modelo de objeto para o cliente de teste em futuras versões

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

Processar herança em novas coleções

A herança do processo está agora 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 aumentada

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:

Submenu Meu trabalho

Um novo recurso que estamos muito entusiasmados em apresentar é o painel meu trabalho. Ouvimos comentários de que quando você está em uma parte do produto e quer alguma informação de outra parte, você não quer perder seu contexto. Com esse novo recurso, você pode acessar esse submenu de qualquer lugar do produto e ele lhe dará uma rápida olhada em informações cruciais, incluindo seus itens de trabalho, solicitações pull e todos os favoritos. Com este novo submenu, se você estiver em Repos com a cabeça para baixo em seu código, mas quiser verificar rapidamente em qual item de trabalho você deve trabalhar em seguida, você pode simplesmente 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 ver mais solicitações pull:

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

Conselhos

Vincular commits e pull requests do GitHub Enterprise a itens de trabalho no 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 aos Painéis do Azure. Ao conectar o GitHub e os Quadros do Azure, você pode obter todos os recursos, como listas de pendências, painéis, ferramentas de planejamento de sprint, vários tipos de item de trabalho e ainda ter um fluxo de trabalho que se integra aos fluxos de trabalho do desenvolvedor no GitHub.

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

AB#{work item ID}

Mencione um item de trabalho numa mensagem de commit, título de pull request ou descrição do pull request, e os Painéis do Azure criarão um link para esse artifacts. 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 "fix", "fixes" ou "fixed" precederem a menção do item de trabalho (como mostrado acima), o item de trabalho será movido para o estado concluído quando o commit for integrado ao branch padrão.

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

Hub Novos Itens de Trabalho

O Hub de Itens de Trabalho é o 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 que são definidas para você. Você pode visualizar 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 a visualização de lista desejada, você pode classificar os itens de trabalho simplesmente clicando no cabeçalho da coluna. Se uma coluna for muito estreita para que você possa exibir o conteúdo completo da coluna, você poderá facilmente redimensioná-la na área do cabeçalho. Estas experiências podem ser vistas abaixo:

Novos painéis, listas de pendências e hubs de Sprints

O hub Backlogs foi dividido em três hubs distintos para melhorar a experiência do usuário. Embora poderoso, o antigo hub de Backlogs abrigava muitas funcionalidades. Isso muitas vezes tornava difícil encontrar o recurso ou a capacidade que os usuários estavam procurando. Para resolver esse problema, dividimos o hub Backlogs em:

• O hub Backlogs agora abriga apenas as listas de pendências de um projeto. Uma lista de pendências é uma lista priorizada de trabalho para a equipe. As listas de pendências fornecem ferramentas de planejamento, como hierarquia de itens de trabalho, previsão e nova experiência em planejamento de sprint.
• O novo hub de Painéis abriga todos os Quadros Kanban para um projeto. As placas são usadas para comunicar status e fluxo. Os cartões (itens de trabalho) deslocam-se da esquerda para a direita através de colunas definidas pela equipa.
• 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 interface para gerir e definir a capacidade da equipa.

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 informações modificadas pela última vez e a capacidade de pesquisar consultas
• Trilha de navegação com URLs exclusivas para pastas, permitindo marcar grupos importantes de consultas
• Acesso rápido às suas consultas favoritas a partir da 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 armazém de dados esteja desativado. Com o data warehouse desativado, você pode usar o Serviço de Análise para dar suporte às suas necessidades de relatórios. Para saber mais sobre como desativar o data warehouse, consulte Desabilitar o data warehouse e o cubo.

Funcionalidades de planeamento de sprint

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

• Crie o seu próximo sprint ou subscreva uma agenda de sprint existente diretamente a partir 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 utilize a opção de criação rápida para adicionar à parte superior, inferior ou linha de sua escolha na lista de pendências do sprint.
• Use filtros para Cessionário, Tipo de Item de Trabalho, Estado e Tags para adaptar as visualizações às suas necessidades.

Novas páginas de diretório

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

• Continue de onde parou Esta nova secção fornece um link rápido diretamente para o último (Quadro | Pendências | Sprint) em que esteve.
• Favoritos Todos os seus quadros favoritos, sprints e listas de pendências em todas as equipes.
• Os meus Todos os quadros, listas de pendências e sprints para as equipas a que pertences.
• Tudo Uma lista completa de todos os seus quadros, listas de pendências e sprints.

Novo menu Opções de Visualização

Os novos hubs, incluindo Backlogs, Boards e Sprints, têm um novo menu View Options . 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 modos de exibição adicionais, como mostrar hierarquia em listas de pendências ou alterar a opção Agrupar por em um quadro de tarefas, para ativar o painel lateral para mapear e planejar sprints ou para explorar gráficos de detalhes de 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 em cartões incluem bugs e tipos de item de trabalho personalizados

As anotações de cartão 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 aos tipos de nível de backlog padrão e não suportavam Bugs ou tipos personalizados. Com a nova versão, removemos a restrição aos 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 do 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 item de trabalho estão habilitadas, as contagens para esse tipo de itens são incluídas no cartão como uma lista de verificação separada.

A criação rápida de tipos de itens de trabalho ativados também está disponível através do menu de contexto do cartão.

Mover 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, oferecendo 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.

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

A @CurrentIteration macro que ajuda a sua equipa a acompanhar o trabalho com base no seu calendário de iteração agora suporta deslocamento de números inteiros. Acompanhe facilmente o trabalho que não foi fechado com @CurrentIteration - 1 ou veja o trabalho planejado para futuras iterações com @CurrentIteration + 1. Consulte a postagem @CurrentIteration no Blog do Microsoft DevOps para obter mais informações.

Esclarecer os horários de iteração da consulta com o parâmetro da equipa @CurrentIteration

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

Consultar trabalho nos caminhos de área de uma equipa com a nova macro @TeamAreas

Nas configurações de uma Equipe, você pode associar um ou mais Caminhos de Área, o que ajuda a concentrar Listas de Pendências, Painéis, Planos e até mesmo Painéis apenas no trabalho dessa Equipe. No entanto, caso se queira escrever uma consulta para uma equipa, é necessário listar os caminhos de área específicos dessa equipa nas cláusulas da consulta. Agora, uma nova macro de @TeamAreas está disponível para você referenciar facilmente os Caminhos de Área pertencentes à Equipe especificada.

Consulta de campos de texto rico vazios

Localize itens de trabalho que tenham um campo de rich text vazio, como Description, usando o novo operador de consulta IsEmpty .

Encontre facilmente itens de trabalho existentes na vinculação e mencione experiências

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 nos 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 os itens de trabalho a partir da 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 exploração aprofundada 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 ramos melhorado

A maioria das experiências no Azure Repos exige que você selecione um repositório e, em seguida, uma ramificação 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 filiais favoritas ou procure rapidamente por uma filial.

Receba notificações quando as políticas de pedidos de pull forem contornadas

Para equipes que usam solicitações pull (PRs) e políticas de ramificação, pode haver ocasiões em que as pessoas precisem substituir e ignorar essas políticas - por exemplo, ao implantar um hotfix para 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 equipas precisam de uma maneira de verificar se essas exceções às políticas estão a ser 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 e-mail sempre que uma política for ignorada. Comece com o modelo Uma solicitação pull é criada ou atualizada e selecione Bypass de política na lista de filtros. Selecione Políticas foram ignoradas como o valor e você será notificado sempre que uma RP for concluída e as políticas forem ignoradas.

Permitir ignorar políticas de ramificação sem abrir mão da proteção contra push

Há muitos cenários em que você tem a necessidade ocasional de ignorar uma política de ramificação - revertendo uma alteração que causou uma quebra de compilação, aplicando um hotfix no meio da noite, etc. Anteriormente, oferecíamos uma permissão ("Isenta da aplicação de políticas") para ajudar as equipes a gerenciar quais usuários receberam a capacidade de ignorar as políticas de ramificação ao concluir uma solicitação pull. No entanto, essa permissão também concedeu a capacidade de empurrar diretamente para a filial, ignorando totalmente o processo de RP.

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 as políticas ao completar pull requests. Os utilizadores com esta permissão poderão usar a funcionalidade "Substituir" para os pedidos pull.
2. Ignorar políticas ao efetuar push. Os utilizadores com esta permissão poderão fazer push diretamente para as ramificações 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 empurrar acidentalmente para uma ramificação com políticas.

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

Descreva rapidamente solicitações 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 pull (PR) com várias confirmações exigirão que os colaboradores insiram um título manualmente.

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

Criar pull requests sem uma equipa padrão como revisor

Quando lançamos pela primeira vez a experiência de pull request (PR), pensamos que faria sentido atribuir todos os RPs ao contexto da equipe que você selecionou ao criar o PR. Este comportamento tem sido um motivo de frustração, já que muitas pessoas não perceberam a ligação entre o contexto da equipa e a atribuição de PR.

Como parte das novas mudanças 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 RP, 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 RPs 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 Pull Requests tem uma nova seção personalizável. Por padrão, esta seção mostra RPs "Atribuídos às minhas equipes", fornecendo funcionalidade equivalente à seção antiga. No entanto, se você pertencer a várias equipes, esta seção mostrará RPs atribuídos 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.

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

Escrever boas descrições de pull request é 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 controlar as coisas que devem ser feitas para cada alteração, como testes, adição de testes de unidade e atualização de documentação. Muitos de vocês têm solicitado que adicionemos modelos de pull request para tornar mais fácil para as equipes escreverem ótimas descrições, e agora adicionamos esse recurso.

Além de suportar um modelo de descrição de RP 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 RP. Basta clicar no botão Adicionar um modelo para escolher entre qualquer modelo no repositório para anexá-lo à descrição de RP.

Modelos específicos de ramificação também são suportados se você quiser aplicar um modelo diferente para um RP em uma ramificação ou pasta de filial específica. Por exemplo, se você quiser ter um modelo específico para todas as ramificações que começam com "hotfix/", você pode adicionar um modelo que será usado para todas as RPs nessas ramificações.

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

Altere o ramo de destino de um pedido de pull

Para a maioria das equipes, quase todas as solicitações pull têm como alvo a mesma ramificação, como main ou develop. No entanto, quando é necessário apontar para uma ramificação diferente, é fácil esquecer de alterar a ramificação padrão de destino. Com o novo recurso para alterar a ramificação de destino de uma solicitação pull ativa, essa agora é uma ação simples. Basta clicar no ícone de lápis perto do nome da ramificação de destino no cabeçalho da solicitação pull.

Além de apenas corrigir erros, o recurso para alterar ramificações de destino também facilita o "redirecionamento" de uma solicitação pull quando a ramificação de destino foi mesclada ou excluída. Considere um cenário em que você tenha uma PR direcionada a uma ramificação de funcionalidades que contém algum recurso do qual as suas alterações dependem. Você deseja revisar as suas alterações dependentes isoladamente das outras alterações na ramificação do recurso, direcionando inicialmente para features/new-feature. Os revisores podem ver apenas suas alterações e deixar os comentários apropriados.

Agora, considere o que aconteceria se a branch de funcionalidade também tivesse um PR ativo e fosse fundida em main antes das suas alterações? Anteriormente, teria que abandonar as suas alterações e criar um novo PR em main, ou mesclar o seu PR em features/new-feature, e, em seguida, criar outro PR de features/new-feature para main. Com esta nova ação para atualizar a ramificação de destino, você pode simplesmente alterar a ramificação de destino do PR features/new-feature de para main, preservando todo o contexto e comentários. Alterar a ramificação de destino até cria uma nova atualização para a RP, o que facilita a análise de diffs anteriores antes da alteração da ramificação de destino.

Os autores de extensões podem consultar informações contextuais 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, ID e 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 do Azure Repos, null será retornado.

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

Tubulações

Gerir processos de construção usando a nova página Construções

Estamos fazendo várias melhorias e lançando uma nova versão da página Compilações . Esta nova versão combina o diretório de todos os seus pipelines de compilação e a lista de compilações atuais para que você possa navegar rapidamente pelas compilações do seu projeto para ver seu status. Inclui também uma pré-visualização das análises 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 e-mails de conclusão de compilação e implantação foram atualizados para serem mais filtráveis por regras de e-mail. Agora, a linha de assunto inclui informações mais relevantes em um piscar de olhos, a carroceria 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]

Eis 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

Durante as várias fases de compilação e lançamento, diferentes termos foram historicamente utilizados para conceitos semelhantes. Noutros casos, os significados dos termos eram vagos. Por exemplo, dizer 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:

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

Gerencie pipelines de liberação usando a nova página Releases

Uma experiência de usuário nova e totalmente redesenhada está disponível para a página inicial da versão. Veja uma lista dos pipelines de liberação que você libera com frequência à esquerda. Você também pode pesquisar os seus pipelines e marcá-los como favoritos.

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

Visualize o progresso do lançamento

A nova visualização de progresso da versão oferece atualizações em tempo real do progresso da implantação e acesso com um clique a mais detalhes. A nova visualização demonstra o pipeline de lançamento, tornando mais fácil compreender o que está a acontecer e mostra detalhes e ações apropriados em diferentes fases do lançamento.

Pipeline, detalhes da versão e ambientes

A visualização Pipeline mostra os artefatos da versão e os ambientes onde eles serão implantados. A área Release fornece detalhes de lançamento, como o gatilho de lançamento, versões de artefatos 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 tiverem sido definidas condições de pré ou pós-implantação para um ambiente, isso é indicado no ambiente com a presença das aprovações e portas. O progresso das aprovações e portões também aparece no status do meio ambiente. Você pode agir ou visualizar mais detalhes clicando no ícone de condição do ambiente pendurado no lado direito ou esquerdo do ambiente.

Confirmações e itens de trabalho

Com cada nova versão, você pode ver a lista de commits associados e itens de trabalho para cada ambiente separadamente clicando no ambiente. Se a lista for longa, use filtros para encontrar uma confirmação ou item de trabalho em que você esteja interessado.

Progresso e logs da implantação

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

Você pode clicar nos logs para aceder a uma vista focada.

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

Os grupos de máquinas no Test Hub foram descontinuados no TFS 2017 RTM. Com o 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 Machine File Copy' versão 1.* e da tarefa 'PowerShell on Target Machines' versão 1.*. Para que os seus pipelines continuem a funcionar,

• Tem de mudar para a tarefa 'Windows Machine File Copy' versão 2.* e fornecer o FQDN completo da máquina de destino em vez de apenas o nome da máquina.
• E mude para a tarefa 'Powershell on Target Machine' versão 2.* ou posterior e forneça o nome de domínio totalmente qualificado (FQDN) da máquina ou o nome da máquina seguido pelas portas de Gerenciamento Remoto do Windows (http/https). Por exemplo, targetMachine:5985 ou targetMachine:5986

Resultados dos testes e extensibilidade

Os resultados da execução do teste também são apresentados 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 apresentem ainda mais informações para um ambiente. Consulte a documentação de contribuições e extensões para obter mais informações.

Configurar compilações usando YAML

Os pipelines de compilação baseados em YAML estão disponíveis no seu Servidor de DevOps do Azure. 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 oferecer suporte a pipelines de compilação baseados em YAML de forma mais perfeita, alteramos o comportamento padrão para que todos os novos recursos criados (por exemplo, conexões de serviço, grupos de variáveis, pools de agentes e arquivos seguros) possam ser usados em todo o pipeline desse projeto. Se você quiser um controle mais rígido sobre seus recursos, você pode desativar o modelo de autorização padrão (veja a figura abaixo). Quando você fizer isso, alguém com permissões para usar o recurso deve salvar explicitamente o pipeline no editor da Web depois que uma referência de recurso é adicionada ao arquivo YAML.

Encadear builds relacionadas usando gatilhos de conclusão de build

Os grandes produtos têm vários componentes que dependem uns dos outros. Estes componentes são muitas vezes construídos de forma independente. Quando um componente a montante (uma biblioteca, por exemplo) muda, as dependências a jusante têm de ser reconstruídas 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 uma compilação upstream podem ser baixados e usados na compilação posterior, e você também pode obter dados dessas variáveis: Build.TriggeredBy.BuildId, Build.TriggeredBy.DefinitionId, Build.TriggeredBy.BuildDefinitionName. Consulte a documentação sobre gatilhos de compilação para obter mais informações.

Tenha em mente 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 é útil se seus requisitos incluírem diferentes definições de configuração, opções ou uma equipe diferente para possuir o processo dependente.

Atualize o seu agente localmente

Às vezes, as tarefas instaladas a partir da Galeria exigem uma versão mais recente do agente de pipelines. Se o seu Servidor de DevOps do Azure puder se conectar à Internet, as versões mais recentes serão baixadas automaticamente. Se não, então você tem que atualizar manualmente cada agente. A partir desta versão, você pode configurar seu Servidor de DevOps do Azure para procurar os arquivos do pacote do agente em seu disco local em vez de na Internet. Isso lhe dá flexibilidade e controle sobre quais versões de agente você disponibiliza, sem ter que expor seu Servidor de DevOps do Azure à Internet.

Novo URL do selo de status da compilação

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

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

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

Para compatibilidade com versões anteriores, continuaremos a suportar as URLs antigas dos emblemas de compilação.

Adicionar contadores de compilações personalizados às suas compilações

Os contadores de builds fornecem uma maneira exclusiva de númerar e rotular compilações. 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 sempre que você executa uma compilação. Você faz isso na guia variáveis de uma definição. Esta nova funcionalidade dá-lhe mais potência das seguintes formas:

• Você pode definir um contador personalizado e definir seu valor inicial. Por exemplo, você pode iniciar seu contador em 100. $(rev:r) começa sempre em 0.
• Você pode usar sua própria lógica personalizada para redefinir um contador. $(rev:r) está vinculado à geração de números de compilação e é redefinido automaticamente sempre que há um novo prefixo no número de compilação.
• Você pode definir vários contadores por definição.
• Você pode consultar o valor de um contador fora do contexto de uma compilação. Por exemplo, você pode contar o número de compilações que foram executadas 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 compilação.

Validações de conformidade e segurança do Azure Policy nos Pipelines

Queremos garantir a estabilidade e a segurança do software no início do processo de desenvolvimento, ao mesmo tempo que juntamos desenvolvimento, segurança e operações. Para fazer isso, adicionamos suporte para a Política do Azure.

O Azure Policy ajuda-o a gerir e evitar problemas de TI com definições de políticas que impõem regras e efeitos aos seus recursos. Quando você usa a Política do Azure, 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 de 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 ARM.

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

Compilar para plataformas Linux em ARM e Windows de 32 bits

O agente de plataforma cruzada de código aberto do Azure Pipelines sempre foi suportado em Windows, macOS e Linux de 64 bits (x64). Com esta versão, estamos introduzindo duas novas plataformas suportadas: Linux/ARM e Windows/32-bit. Estas novas plataformas dão-lhe a capacidade de construir em 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 oferece informações de teste ricas e contextualizadas para Pipelines. A nova experiência fornece uma exibição de teste em andamento, experiência de depuração em página inteira, histórico de teste no contexto, relatório de execução de teste abortada e resumo ao nível de execução.

Ver a execução de testes em curso

Testes, como integração e testes funcionais, podem ser executados por um longo tempo, por isso é importante ver a execução do teste a qualquer momento. Com a Visualizaçã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-o a tomar medidas mais rapidamente. Você pode depurar uma falha ou abortar, arquivar um bug ou abortar o pipeline. O recurso está atualmente disponível tanto para o pipeline de compilação como para o de lançamento, utilizando a VS Test Task na fase Multi Agent, e a Publish Test Results Task ou publicando os resultados de teste através de API(s). No futuro, planejamos estender essa experiência para execução de testes usando um único agente.

A exibição abaixo mostra o resumo do teste em andamento na visualizaçã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 In-Progress Resumo do teste acima, você pode exibir o resumo detalhado do teste junto com as informações de teste reprovadas ou abortadas em Planos de teste. O resumo do teste é atualizado em um intervalo periódico com a capacidade de atualizar a exibição detalhada sob demanda, com base na disponibilidade de novos resultados.

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

As mensagens de erro e os traços de pilha são longos por natureza e precisam de espaço suficiente para visualizar 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.

Ver 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, colocamos o histórico de testes no contexto na guia Planos de teste para compilação e lançamento. As informações do histórico de teste são fornecidas de forma progressiva, começando com a definição de compilação atual ou o ambiente para o teste selecionado, seguido por outras ramificações e ambientes para a compilação e a versão, respectivamente.

Ver testes abortados

A execução do teste pode ser abortada devido a vários motivos, como código de teste incorreto, fonte em teste e problemas ambientais. Independentemente do motivo do abortamento, é importante diagnosticar o comportamento e identificar a causa raiz. Agora você pode visualizar os testes abortados e as execuções de teste, juntamente com as execuções concluídas em Planos de teste. O recurso está atualmente disponível tanto para o fluxo de trabalho de compilação como para o de distribuição, usando VS Test Task na fase de Multi Agente ou ao publicar resultados de teste através de API(s). No futuro, planejamos estender essa experiência para execução de testes usando um único agente.

Suporte à rastreabilidade de teste e aos ambientes de implementação no histórico de testes

Estamos adicionando suporte para visualizar 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 liberação como pipelines de liberação 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ê poderia descobrir se está passando na configuração regional inglesa, mas falhando em uma configuração regional 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 tem falhado.

Rever os resultados resumidos dos testes

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 por dados). Uma vez que estes testes estão relacionados, têm de ser comunicados juntamente com o resultado global obtido com base nos resultados individuais dos testes. Com esta atualização, introduzimos uma versão melhorada dos resultados de teste apresentados como uma hierarquia na guia Testes de uma versão. Vejamos um exemplo.

Anteriormente, introduzimos a capacidade de executar novamente testes com falha na tarefa VS Test . No entanto, apenas 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 do teste como uma tentativa. Além disso, a API de Gerenciamento de Teste agora oferece 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.

Ver as análises do teste nos Pipelines

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

Você pode agrupar os resultados do teste por vários elementos, identificar os principais testes para sua filial ou arquivos de teste, ou aprofundar-se num teste específico para ver tendências e entender problemas de qualidade, como a intermitência.

Veja a análise de teste para compilações e lançamento, visualização abaixo:

Para obter mais informações, consulte nossa 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 requerem um agente ou nenhum computador 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 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 que você mantenha várias tarefas em fases sem agente. As tarefas na mesma fase seriam executadas de forma sequencial, tal como acontece nas fases do agente. Consulte a documentação das fases do servidor para obter mais informações.

Expor progressivamente e fasear implantações usando portas de liberação

Usando portas de liberaçã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 imediatamente e você pode adicionar mais portões do Marketplace. Você poderá verificar se todos os critérios necessários para uma implantação foram atendidos. Consulte a documentação de portões de liberação para obter mais informações.

Suspenda as implantações até que os portões sejam bem-sucedidos de forma consistente

As portas de liberação permitem a avaliação automática dos critérios de integridade antes que uma liberação seja promovida para o próximo ambiente. Por padrão, a liberação progride após o recebimento de uma amostra bem-sucedida para todos os portões. Mesmo que um portão seja irregular e a amostra bem-sucedida recebida seja ruído, a liberação progride. Para evitar esses tipos de problemas, pode-se agora configurar o lançamento para verificar a consistência do estado de saúde por um período mínimo antes de continuar. Em tempo de execução, a liberação garantiria que avaliações consecutivas dos portões fossem bem-sucedidas antes de permitir a promoção. O tempo total de avaliação depende do "tempo entre a reavaliação" e normalmente seria maior do que a duração mínima configurada. Para mais informações, consulte a documentação sobre o controlo da implementação de lançamentos usando gates.

Implantar automaticamente em novos destinos num grupo de implementaçã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.

Implante continuamente as compilações identificadas pelo processamento após a compilação

Os gatilhos de implantação contínua criam uma versão na 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 depois que o processamento for concluído. Agora você pode aproveitar as tags de compilação, 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 gostaria de 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 em rascunho e acionar a liberação com a variável.

Passar variáveis de ambiente para tarefas

Os autores de tarefas 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 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 valores de segredos sejam passados de forma segura para os scripts. Isso é preferível a passar os segredos como argumentos para os scripts, porque o sistema operativo no agente pode registar a invocação de processos, incluindo os 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 rapidamente uma cópia do seu grupo de variáveis, atualizar os valores apropriadamente e salvá-lo como um novo grupo de variáveis.

Ignorar uma porta de liberação para uma implantação

As portas de liberação permitem a avaliação automática dos critérios de integridade antes que uma liberação seja promovida para o próximo ambiente. Por padrão, o pipeline de liberação progride somente quando todos os portões estão íntegros ao mesmo tempo. Em certas situações, como ao agilizar um lançamento ou depois de verificar manualmente a integridade, um aprovador pode querer ignorar uma barreira e permitir que o lançamento prossiga, mesmo que essa barreira ainda não tenha sido avaliada como íntegra. A documentação das etapas de lançamento para obter mais informações.

Realizar testes adicionais usando um disparador de lançamento de pull request

Você tem sido capaz de acionar uma compilação com base num pull request (PR) e obter esse feedback rápido antes de uma fusão há algum tempo. Agora pode também configurar um gatilho de Pull Request para um lançamento. O status da liberação será postado de volta no repositório de código e pode ser visto diretamente na página de RP. Isso é útil se você quiser executar testes funcionais ou manuais adicionais como parte do seu fluxo de trabalho de RP.

Criar uma ligação ao serviço do Azure com um principal 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 suportando a entidade de serviço que se autentica com um certificado, pode-se agora implantar no Azure Stack configurado com 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.

Funcionalidade Executar a partir de Pacote suportada em implementações do Serviço de Aplicações do Azure

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

O Serviço de Aplicativo suporta várias técnicas diferentes para implantar seus arquivos, como msdeploy (também conhecido como WebDeploy), git, ARM e muito mais. Mas todas estas técnicas têm uma limitação. Seus arquivos são implantados em sua pasta wwwroot (especificamente d:\home\site\wwwroot) e o tempo de execução 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 apontar para um ficheiro zip, e este é montado como sistema de ficheiros de só leitura em wwwroot. Isto tem várias vantagens:

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

Implementar contentores do Linux com a tarefa Implementação do Servidor de Aplicações

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

O modelo de hospedagem Linux para o 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 incorporada: Você traz o código do Aplicativo de Função e o Azure fornece e gerencia o contêiner (modo de imagem interno), portanto, nenhum conhecimento específico relacionado ao Docker é necessário. Isso é suportado na versão existente da tarefa Implantação do Serviço de Aplicativo.
2. Imagem de contêiner personalizada: Aprimoramos a tarefa Implantar 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 idioma específico 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 do Xcode suporta o recentemente lançado Xcode 10

Coincidindo com o lançamento do Xcode 10 pela Apple, agora você pode configurar seus projetos para construir ou ser testado 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. Consulte as orientações para usar o Xcode no Azure Pipelines.

Agilize a implantação no Kubernetes usando o Helm

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

Com a adição desta tarefa Helm, agora pode-se configurar um pipeline de CI/CD baseado em Helm para distribuir contêineres num cluster 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 no Lançamento

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 esta tarefa para alterar a versão do Helm utilizada em tarefas subsequentes, como a tarefa CLI do .NET Core. Adicionar essa tarefa antes da tarefa Helm Deploy em uma definição de compilação ou versão garante que você esteja empacotando e implantando seu aplicativo com a versão correta do Helm. Esta tarefa também ajuda na instalação opcional da ferramenta kubectl , que é um pré-requisito para o Helm funcionar.

Implantar continuamente na Base de Dados do Azure para MySQL

Agora pode-se efetuar implementações contínuas na Base de Dados da Azure para MySQL - a base 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 liberação usando uma tarefa nativa em vez de scripts do PowerShell.

Usar tarefas aprimoradas baseadas no PowerShell remoto do Windows

Estão disponíveis tarefas novas e melhoradas baseadas no PowerShell remoto do Windows. Essas melhorias incluem várias correções de desempenho e suportam logs em tempo real e comandos de saída do console, como Write-Host e Write-Output.

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

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

Filtrar ramificações para o GitHub Enterprise ou artefatos Git externos

Ao liberar a partir do GitHub Enterprise ou repositórios Git externos, agora você pode configurar as ramificações específicas que serão lançadas. Por exemplo, talvez tu queiras implantar apenas builds provenientes de um branch específico para a 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. Esta tarefa adquire uma versão específica do Go Tool necessária para o seu projeto e adiciona-a ao PATH do agente de compilação. Se a versão do Go Tool de destino 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, criar ou testar seu aplicativo. Você também pode usar essa tarefa para executar um comando Go personalizado de sua escolha.

Execute ou corra scripts Python integrados ou baseados em arquivo na sua linha de processo

Uma nova tarefa Python Script simplifica a execução de scripts Python em seu pipeline. A tarefa executará um script a partir de um arquivo Python (.py) em seu repositório, ou você pode 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 melhorada do Xcode e a saída de teste do xcpretty

xcpretty melhora a legibilidade da saída xcodebuild e gera resultados de teste no formato JUnit. A tarefa de compilação do Xcode agora usa automaticamente o xcpretty quando está disponível na máquina do agente, assim como nos agentes macOS hospedados. Embora a saída xcpretty possa ser diferente e menos detalhada do que a saída xcodebuild, disponibilizamos os logs completos do xcodebuild com cada compilação.

Planos de Teste

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

Agora você pode usar o cliente Test Runner (Planos de Teste do Azure) para executar testes manuais para aplicativos da área de trabalho. Isso ajudará você a mudar do Microsoft Test Manager para os Planos de Teste do Azure. Consulte as nossas orientações aqui. Usando o cliente Test Runner, você pode executar seus testes manuais e registrar os resultados do teste para cada etapa de teste. Você também tem recursos de coleta de dados, como captura de tela, registro de ação de imagem e gravação de áudio e vídeo. Se você encontrar um problema durante o teste, 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 (Planos de Teste do Azure) requer um download e uma instalação únicos do corredor. Selecione Executar para aplicativo de desktop , conforme mostrado abaixo.

Artefatos

Fontes a montante

O Azure DevOps Server 2019 traz atualizações substanciais para as fontes upstream disponíveis em seus feeds de Artefatos do Azure:

• 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 do Servidor de DevOps do Azure como fontes upstream ao seu feed, o que significa que você pode usar pacotes NuGet e npm desses feeds por meio do seu 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 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.

Acompanhar 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 as visualizações de lançamentos. Se seguir um pacote enquanto o vê através de uma vista, apenas obterá atualizações para novas versões que são promovidas para essa vista.

Alterar as configurações do feed sem ter que 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. Isto significa que não precisa de se preocupar com a perda de alterações ao alternar entre diferentes opções de configuração.

Simplificar a autenticação com o novo Fornecedor de Credenciais para várias plataformas para NuGet

A interação com feeds NuGet autenticados ficou muito melhor. O novo Provedor de Credenciais de Artefatos do Azure 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 de Artefatos do Azure, o Provedor de Credenciais adquirirá e armazenará automaticamente um token em nome do cliente NuGet que você está usando. Você não precisa mais armazenar e gerenciar manualmente um token em um arquivo de configuração.

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

Comprimir símbolos ao publicar numa partilha de ficheiros

Atualizámos a tarefa Index & Publish Symbols para suportar a compressão de símbolos quando são publicados numa partilha de ficheiros.

Wiki

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

Os desenvolvedores criam documentação para "APIs", "SDKs" e "documentos de ajuda explicando código" em repositórios de código. Os leitores, então, precisam filtrar 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.

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 de marcação na pasta selecionada serão publicados como um wiki. Isso também mapeará o chefe da ramificação para o wiki para que quaisquer alterações que você fizer no repositório Git sejam refletidas imediatamente.

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

Link para títulos dentro de uma página

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

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

Incorporar um vídeo no wiki

Agora você pode incorporar vídeos em uma página wiki de serviços online, como o Microsoft Stream e o YouTube. Você pode adicionar a URL de vídeo incorporada 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>
:::

Mudar o nome de um 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 ao seu wiki um nome memorável.

Abrir página num novo separador

Agora você pode clicar com o botão direito 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 UTF-8:

Ver 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-lhe uma pista visual de todos os links quebrados em uma página wiki.

Corrigir links quebrados ao mover páginas

Links de páginas quebradas são uma das principais causas da má qualidade da 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, isso 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.

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

Em seguida, será exibida uma lista dos links de página e itens de trabalho afetados antes de tomar qualquer ação.

Criar índice 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 markdown no Azure DevOps.

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

Adicionar metadados à documentação pode ajudar os leitores e os índices de pesquisa a captar e exibir conteúdo significativo. Nesta atualização, qualquer arquivo que contenha um bloco YAML no início do arquivo será transformado em uma tabela de metadados de um cabeçalho e uma linha. O bloco YAML deve assumir a forma de um YAML válido situado entre linhas com três traços. Ele suporta todos os tipos de dados básicos, lista, objeto como valor. A sintaxe é suportada no Wiki e na visualização do arquivo de código.

Exemplo de tags YAML:

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

Exemplo de tags YAML com uma 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 obstáculo para quaisquer solicitações de publicação de arquivos markdown hospedados em repositórios git em formato de wikis. Agora, você pode publicar código como wiki se tiver apenas a permissão Contribuir no repositório de código.

Elaboração de Relatórios

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

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

Para obter mais informações, consulte O que é o Google Analytics e o Roteiro de relatórios. O Google Analytics está em Visualização pública. Atualmente, contém dados para Placas e resultados de Testes Automatizados via Pipelines. Consulte Dados disponíveis no Serviço de análise.

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

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

Feedback

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