Notas de versão do Azure DevOps Server 2019
| Developer Community System Requirements | License Terms | DevOps Blog | SHA-1 Hashes
Neste artigo, você encontrará informações sobre a versão mais recente para Azure DevOps Server.
Para saber mais sobre como instalar ou atualizar uma implantação de Azure DevOps Server, confira Requisitos de Azure DevOps Server. Para baixar produtos do Azure DevOps, visite a página Downloads do Azure DevOps Server.
A atualização direta para o Azure DevOps Server 2020 tem suporte do Azure DevOps Server 2019 ou do Team Foundation Server 2015 ou mais recente. Se a implantação do TFS estiver no TFS 2010 ou anterior, você precisará executar algumas etapas provisórias antes de atualizar para o Azure DevOps Server 2019. Para saber mais, confira Instalar e configurar o Azure DevOps localmente.
Atualizar com segurança do Azure DevOps Server 2019 para o Azure DevOps Server 2020
Azure DevOps Server 2020 apresenta um novo modelo de retenção de execução de pipeline (build) 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 do Azure DevOps Server 2019 para o 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.
- Estendeu a lista de caracteres permitidos das tarefas do PowerShell para Habilitar validação de parâmetro de argumentos de tarefas de shell.
Observação
Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente as tarefas.
Instalar patches
Importante
Lançamos atualizações para o agente do Azure Pipelines com o Patch 15 lançado em 12 de setembro de 2023. Se você não instalou as atualizações do agente conforme descrito nas notas de versão do Patch 15, recomendamos que você instale essas atualizações antes de instalar o Patch 16. A nova versão do agente após a instalação do Patch 15 será a 3.225.0.
Configurar o TFX
- Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.
Atualizar tarefas usando TFX
| Arquivo | Hash SHA-256 |
|---|---|
| Tasks20231103.zip | 389BA66EEBC32622FB83402E21373CE20AE040F70461B9F9AF9EFCED5034D2E5 |
- Baixe e extraia Tasks20231103.zip.
- Altere o diretório para os arquivos extraídos.
- 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 deve ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia variável no 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: Azure DevOps Server vulnerabilidade de execução remota de código.
- CVE-2023-38155: vulnerabilidade de elevação de privilégio do Azure DevOps Server e do Team Foundation Server.
Importante
Implante o patch em um ambiente de teste e verifique se os pipelines do ambiente funcionam conforme o esperado antes de aplicar a correção à produção.
Observação
Para implementar correções para esse patch, você precisará seguir várias etapas para atualizar manualmente o agente e as tarefas.
Instalar patches
- Baixe e instale Azure DevOps Server Patch 15 2019.0.1.
Atualizar o agente do Azure Pipelines
- Baixe o agente de: https://github.com/microsoft/azure-pipelines-agent/releases/tag/v3.225.0 - Agent_20230825.zip
- Use as etapas descritas na documentação de agentes auto-hospedados do Windows para implantar o agente.
Observação
O AZP_AGENT_DOWNGRADE_DISABLED deve ser definido como "true" para impedir que o agente seja rebaixado. No Windows, o comando a seguir pode ser usado em um prompt de comando administrativo, seguido por uma reinicialização. setx AZP_AGENT_DOWNGRADE_DISABLED true /M
Configurar o TFX
- Siga as etapas na documentação carregar tarefas na coleção de projetos para instalar e fazer logon com o tfx-cli.
Atualizar tarefas usando TFX
- Baixe e extraia Tasks_20230825.zip.
- Altere o diretório para os arquivos extraídos.
- 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 deve ser definida em pipelines que usam as tarefas afetadas.
No clássico:
Defina a variável na guia variável no 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: Azure DevOps Server vulnerabilidade de falsificação.
data de lançamento do Patch 13 do Azure DevOps Server 2019.0.1: 17 de maio de 2022
Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.
- Revogue todos os tokens de acesso pessoal depois que a conta do Active Directory de um usuário for 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.
- Resolvido a vulnerabilidade do Elasticsearch removendo a classe jndilookup dos binários log4j.
Etapas de instalação
- Atualize o servidor com o Patch 12.
- Verifique o valor do Registro em
HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1). - Execute o comando
PS C:\Program Files\{TFS Version Folder}\Search\zip> .\Configure-TFSSearch.ps1 -Operation updateupdate conforme fornecido no arquivo leiame. Ele pode retornar um aviso como: Não é possível se conectar ao servidor remoto. Não feche a janela, pois a atualização está executando novas tentativas até que ela seja concluída.
Observação
Se Azure DevOps Server e Elasticsearch estiverem instalados em computadores diferentes, siga as etapas descritas abaixo.
- Atualize o servidor com o Patch 12.
- Verifique o valor do Registro em
HKLM:\Software\Elasticsearch\Version. Se o valor do Registro não estiver lá, adicione um valor de cadeia de caracteres e defina a Versão como 5.4.1 (Nome = Versão, Valor = 5.4.1). - Copie o conteúdo da pasta chamada zip, localizada na
C:\Program Files\{TFS Version Folder}\Search\zippasta de arquivos remotos Elasticsearch. - Execute
Configure-TFSSearch.ps1 -Operation updateno computador do servidor Elasticsearch.
HASH SHA-256: 96C7AF3E3ED67C76451BA228427B3C0738EEB4A5835B6A91EBD3205A54C384D7
data de lançamento do Patch 11 do Azure DevOps Server 2019.0.1: 10 de agosto de 2021
Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.
- Correção do erro de interface do usuário da definição de build.
Azure DevOps Server data de lançamento do Patch 10 2019.0.1: 13 de abril de 2021
Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte.
- CVE-2021-27067: Divulgação de informações
Para aplicar o Patch 10, você precisará instalar a AzureResourceGroupDeploymentV2 tarefa.
Instalação da tarefa AzureResourceGroupDeploymentV2
Observação
Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows
Instalar
Extraia o pacote AzureResourceGroupDeploymentV2.zip para uma nova pasta no computador. Por exemplo: AzureResourceGroupDeploymentV2.
Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) de acordo com seu computador.
Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.
npm install -g tfx-cli
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 .
Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o Token de acesso pessoal.
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 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 data de lançamento do Patch 9 de 2019.0.1: 8 de dezembro de 2020
Lançamos um patch para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.
- CVE-2020-1325: vulnerabilidade de falsificação de Azure DevOps Server
- CVE-2020-17135: vulnerabilidade de falsificação de Azure DevOps Server
- CVE-2020-17145: vulnerabilidade de falsificação do Azure DevOps Server e do Team Foundation Server
- Correção do problema com o TFVC não processando todos os resultados
Importante
Leia as instruções completas fornecidas abaixo antes de instalar esse patch.
Instalação geral de patch
Se você tiver Azure DevOps Server 2019.0.1, instale Azure DevOps Server Patch 9 2019.0.1.
Verificando a instalação
Opção 1: execute
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 é instaladoc:\Program Files\Azure DevOps Server 2019no por padrão. Depois de instalar o patch 9 do Azure DevOps Server 2019.0.1, a versão será 17.143.30723.4 .
Instalação da tarefa AzurePowerShellV4
Observação
Todas as etapas mencionadas abaixo precisam ser executadas em um computador Windows
Pré-requisitos
Instale Azure PowerShell módulo Az do Azure Powershell no computador do agente privado.
Crie um pipeline com a tarefa AzurePowerShellV4 . Você verá apenas uma Falha no Erro Padrão na tarefa.
Instalar
Extraia o pacote AzurePowerShellV4.zip para uma pasta chamada AzurePowerShellV4.
Baixe e instale Node.js 14.15.1 e npm (incluídos no download do Node.js) de acordo com seu computador.
Abra um prompt de comando no modo de administrador e execute o comando a seguir para instalar o tfx-cli.
npm install -g tfx-cli
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 .
Execute o seguinte no prompt de comando. Quando solicitado, insira a URL do Serviço e o Token de acesso pessoal.
~$ tfx login
Copyright Microsoft Corporation
> Service URL: {url}
> Personal access token: xxxxxxxxxxxx
Logged in successfully
- 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>*
data de lançamento do Patch 8 do Azure DevOps Server 2019.0.1: 8 de setembro de 2020
Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.
- DTS 1713492 - Comportamento inesperado ao adicionar grupos do AD a permissões de segurança.
data de lançamento do Patch 7 do Azure DevOps Server 2019.0.1: 14 de julho de 2020
Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.
- CVE-2020-1326: Vulnerabilidade de script entre sites
- O pipeline de build mostra uma conexão incorreta para usuários não autorizados ao selecionar Outra fonte do Git.
- Correção de erro ao alterar Herança para Ativada ou Desativada na definição de build XAML.
Azure DevOps Server data de lançamento do Patch 6 de 2019.0.1: 10 de junho de 2020
Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.
- CVE-2020-1327: garantir que Azure DevOps Server sanibilize as entradas do usuário
- Adicionando suporte para SHA2 no SSH no Azure DevOps
Azure DevOps Server 2019.0.1 Data de lançamento do Patch 5: 10 de março de 2020
Lançamos um patch de segurança para Azure DevOps Server 2019.0.1 que corrige o seguinte. Confira a postagem no blog para saber mais.
- CVE-2020-0700: vulnerabilidade de script entre sites
- CVE-2020-0758: Vulnerabilidade de elevação de privilégio
- CVE 2020-0815: Vulnerabilidade de elevação de privilégio
data de lançamento do Patch 3 do Azure DevOps Server 2019.0.1: 10 de setembro de 2019
Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige os seguintes bugs. Confira a postagem no blog para saber mais.
- CVE-2019-1305 : vulnerabilidade XSS (cross site scripting) no Repos
- CVE-2019-1306 : vulnerabilidade de execução de código remoto no Wiki
data de lançamento do Patch 2 do Azure DevOps Server 2019.0.1: 13 de agosto de 2019
Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige o seguinte bug. Confira a postagem no blog para saber mais.
- Adicionamos informações às conexões de serviço para esclarecer que elas são autorizadas para todos os pipelines por padrão.
data de lançamento do Patch 1 do Azure DevOps Server 2019.0.1: 9 de julho de 2019
Lançamos um patch de segurança para o Azure DevOps Server 2019.0.1 que corrige os seguintes bugs. Confira a postagem no blog para saber mais.
- CVE-2019-1072 : Vulnerabilidade de execução de código remoto no acompanhamento de item de trabalho
- CVE-2019-1076 : Vulnerabilidade XSS (Cross Site Scripting) em solicitações de pull
data de lançamento do Azure DevOps Server 2019.0.1: 21 de maio de 2019
Azure DevOps Server 2019.0.1 é um acúmulo de correções de bugs. Ele inclui todas as correções nos patches do Azure DevOps Server 2019 lançados anteriormente. Você pode instalar diretamente Azure DevOps Server 2019.0.1 ou atualizar do Azure DevOps Server 2019 ou do Team Foundation Server 2012 ou mais recente.
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 2019.0.1 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Essa versão inclui correções para os seguintes bugs:
Azure Boards
- "Os critérios de campo para este plano têm um erro" ao configurar um Plano. Relatado por meio de Developer Community.
- apiwitcontroller.executequery gera uma exceção quando uma consulta tem a mesma coluna várias vezes.
- No modelo de objeto do cliente usando o escopo vso.work_full oauth, WorkItemServer.DownloadFile() falha.
- Copiar uma imagem inserida de um campo de item de trabalho para outro campo de item de trabalho em um projeto diferente pode criar uma imagem quebrada.
Azure Repos
- "TF401019: GitRepositoryNotFoundException".
Azure Pipelines
- A guia Análise de Teste tem um star (*) que indica a versão prévia, mesmo que esse recurso não esteja em versão prévia.
- Na guia Versões , a ação para gerenciar a segurança agora é mostrada a todos os usuários, independentemente de eles poderem alterar as permissões ou não.
- Nas páginas de aterrissagem versões, a ação iniciar versão de rascunho estava criando uma nova versão, mas agora inicia a versão de rascunho.
Azure Test Plans
- O filtro de 1 hora em TestRuns e TestResults CompletedDate é muito granular.
- No tipo de item de trabalho Caso de Teste , o tipo "Caso de Teste" não deve ser localizado.
- Os casos de teste não aparecem no MTM ou em um navegador.
- Erro "Estágio de validação: você não tem permissão para disparar versões no pipeline de lançamento associado" ao executar testes automatizados de um Plano de Teste. Relatado por meio de Developer Community.
- Usando a API de exclusão de caso de teste, os casos de teste podem ser excluídos de outros projetos. Relatado por meio de Developer Community.
- Clicar em um link de item de trabalho no Test Runner abre a URL do item de trabalho dentro do Test Runner em vez do navegador padrão.
- O caso de teste status não está sendo atualizado para os usuários que saem do Test Runner.
- O nome de usuário e o endereço de email não são mostrados na lista suspensa do usuário no Executor de Teste.
Azure Artifacts
- Mover para cima e Mover para baixo não são localizados em Upstreams.
Análise
- Os relatórios de análise podem mostrar dados incompletos porque o modelo está marcado como "pronto" antes de ser realmente concluído.
- Os widgets de velocidade, burndown e burnup exibem diferentes trabalhos planejados para usuários em fusos horários diferentes.
- Uma retenção pode ser colocada na ingestão de dados do Analytics durante a manutenção, o que pode causar relatórios obsoletos.
Geral
- Os itens de navegação à esquerda são pressionados no IE quando não há espaço suficiente.
Administração
- Registro em log adicional adicionado à Atualização de coleção para ajudar a depurar problemas.
- Quando TfsConfig offlineDetach falha, a mensagem de erro não é acionável.
- O serviço TfsJobAgent falha.
- A extensão De pesquisa não é instalada após a conclusão da configuração.
- O Console de Administração fica sem resposta quando o BD de configuração está corrompido.
- Os Ganchos de Serviço podem não processar corretamente as notificações.
- A indexação de Pesquisa de Código não é iniciada após a configuração da Pesquisa.
- Há cadeias de caracteres não localizadas nos resultados das páginas de pesquisa.
Esta versão inclui a seguinte atualização:
Suporte para Visual Studio 2019 (VS2019) na tarefa teste do Visual Studio
Adicionamos suporte para o Visual Studio 2019 à tarefa teste do Visual Studio em pipelines. Para executar testes usando a plataforma de teste do Visual Studio 2019, selecione as opções Mais recente ou Visual Studio 2019 na lista suspensa Versão da plataforma de teste.
data de lançamento do Patch 2 do Azure DevOps Server 2019: 14 de maio de 2019
Lançamos um patch de segurança para Azure DevOps Server 2019 que corrige os bugs a seguir. Confira a postagem no blog para saber mais.
- CVE-2019-0872 : Vulnerabilidade XSS (Cross Site Scripting) no Test Plans
- CVE-2019-0971 : Vulnerabilidade da divulgação de informações confidenciais na API do Repos
- CVE-2019-0979 : Vulnerabilidade XSS (Cross Site Scripting) no hub de Usuário
data de lançamento do Patch 1 do Azure DevOps Server 2019: 9 de abril de 2019
Lançamos um patch de segurança para Azure DevOps Server 2019 que corrige os bugs a seguir. Confira a postagem no blog para saber mais.
- CVE-2019-0857: vulnerabilidade de falsificação no Wiki
- CVE-2019-0866 : Vulnerabilidade de execução de código remoto no Pipelines
- CVE-2019-0867 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
- CVE-2019-0868 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
- CVE-2019-0869: vulnerabilidade de injeção de HTML em pipelines
- CVE-2019-0870 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
- CVE-2019-0871 : Vulnerabilidade XSS (Cross Site Scripting) no Pipelines
- CVE-2019-0874: vulnerabilidade XSS (cross site scripting) em pipelines
- CVE-2019-0875: vulnerabilidade de elevação de privilégio em Quadros
data de lançamento do Azure DevOps Server 2019: 5 de março de 2019
Observação
A Ferramenta de Migração de Dados estará disponível para Azure DevOps Server 2019 cerca de três semanas após esta versão. Você pode ver nossa lista de versões com suporte atualmente para importação aqui.
Data de lançamento do RC2: 22 de janeiro de 2019
Resumo das novidades no Azure DevOps Server RC2 de 2019
Adicionamos os seguintes recursos ao RC2:
- Vincular commits do GitHub Enterprise e solicitações de pull para Azure Boards itens de trabalho
- Configurar builds usando YAML
- As anotações de cartão incluem bugs e tipos de item de trabalho personalizados
- Seletor de branch aprimorado
- Alterações no Licenciamento de Pipeline de Implantação de Artefatos e Release Management
Data de lançamento do RC1: 19 de novembro de 2018
Resumo das novidades no Azure DevOps Server RC1 2019
Azure DevOps Server 2019 apresenta uma nova experiência de navegação e muitos novos recursos. Alguns dos destaques incluem:
- Nova experiência de navegação
- A extensão do marketplace de Análise para relatórios agora está disponível
- Suporte para banco de dados SQL do Azure
- Processar herança em novas coleções
- Hub Novos Itens de Trabalho
- Novos hubs de Quadros, Listas de Pendências e Sprints
- Novo hub de Consultas
- Padronizar descrições de solicitação de pull usando modelos
- Alterar o branch de destino de uma solicitação de pull
- Gerenciar pipelines de build usando a nova página Builds
- Gerenciar pipelines de lançamento usando a nova página Versões
- Visualizar o progresso da versão
- Atualizar localmente seu agente
- Expor progressivamente e fases de implantações usando portões de liberação
- Fontes upstream
- Criar sumário para páginas wiki
Você também pode ir para seções individuais para ver os novos recursos:
Geral
Anunciando Azure DevOps Server
Em 10 de setembro, anunciamos o Azure DevOps como a evolução do Visual Studio Team Services e do Team Foundation Server. Azure DevOps Server 2019 é nosso primeiro lançamento local com essa nova marca. Você pode encontrar mais informações em nossa postagem no blog.
Nova experiência de navegação
Estamos introduzindo uma nova navegação para modernizar a experiência do usuário. Essa nova navegação foi distribuída para o serviço do Azure DevOps e agora está disponível no Azure DevOps Server 2019. Confira nosso blog para obter mais informações.
Alterações em artefatos e licenciamento de pipeline de implantação de 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 o Artifacts. Agora, um uso de licença do Artifacts 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 serão mais obrigados a comprar Release Management Pipelines de Implantação. Assim como o Build Pipelines, Release Management Pipelines de Implantação agora estão incluídos no Azure DevOps Server 2019.
Suporte para banco de dados SQL do Azure
Para simplificar a experiência de execução do Azure DevOps 2019 no Azure, habilitamos o suporte para o Banco de Dados SQL do Azure (Uso Geral S3 e superior). Isso permitirá que você aproveite recursos de backup extensivos e opções de dimensionamento para atender às suas necessidades, reduzindo a sobrecarga administrativa da execução do serviço. Observe que sua VM host deve estar localizada na mesma região do Azure que seu banco de dados para manter a latência baixa. Para saber mais, confira a documentação .
Item de trabalho & testar APIs SOAP do modelo de objeto cliente 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 cliente. No entanto, ele será marcado como preterido em versões futuras do Azure DevOps Server. Você pode encontrar mais informações em nossa documentação.
Processar herança em novas coleções
A herança do processo agora está disponível em novas coleções. Os usuários precisarão tomar uma decisão consciente sobre o modelo de processo ao criar uma nova coleção. Consulte nossa documentação sobre o que é o modelo de herança e como ele é diferente do XML.
Caixa de pesquisa expandida
Entendemos a importância da pesquisa e estamos trazendo de volta a caixa de pesquisa expandida no cabeçalho do produto. Além disso, agora você pode invocar a caixa de pesquisa apenas clicando em "/" em qualquer página de serviço no Azure DevOps.
Esta é a caixa de pesquisa padrão:
Depois de digitar um "/", você verá a caixa de pesquisa expandida:
Meu submenu de trabalho
Um novo recurso que estamos muito animados para apresentar é o meu submenu de trabalho. Ouvimos comentários de que quando você está em uma parte do produto e deseja algumas informações de outra parte, você não quer perder seu contexto. Com esse novo recurso, você pode acessar esse submenu de qualquer lugar do produto e ele fornecerá uma rápida olhada em informações cruciais, incluindo seus itens de trabalho, solicitações de pull e todos os favoritos. Com esse novo submenu, se você estiver em Repos de cabeça para baixo em seu código, mas quiser marcar rapidamente em qual item de trabalho você deve trabalhar em seguida, basta clicar no submenu e ver os itens de trabalho atribuídos a você e pegar o próximo item.
Abaixo, você pode ver o submenu meu trabalho mostrando os itens de trabalho atribuídos a mim:
Aqui, você pode ver o segundo pivô que mostra as PRs atribuídas a mim. No submenu, você também tem um acesso de clique para exibir mais solicitações de pull:
Aqui você pode ver o último pivô, que é tudo o que você favoritou. Isso inclui suas equipes, painéis, quadros, listas de pendências, consultas e repositórios favoritos:
Boards
Vincular commits do GitHub Enterprise e solicitações de pull para Azure Boards itens de trabalho
As equipes que usam o GitHub Enterprise para código e desejam recursos avançados de gerenciamento de projetos agora podem integrar seus repositórios com Azure Boards. Ao conectar o GitHub e 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 commits e pull requests 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 um mensagem do commit, título de solicitação de pull ou descrição da solicitação de pull e Azure Boards criará um link para esse artefato. Por exemplo, considere uma mensagem do commit como esta:
Adds support for deleting connections. Fixes AB#20.
Isso criará um link do item de trabalho nº 20 para o commit no GitHub, que aparecerá na seção Desenvolvimento do item de trabalho.
Se as palavras "correção", "correções" ou "fixas" precedem o item de trabalho menção (conforme mostrado acima), o item de trabalho será movido para o estado concluído quando o commit for mesclado à 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 da compilação.
Novo hub de Itens de Trabalho
O Hub de Itens de Trabalho é nosso novo hub que servirá como a casa dos seus itens de trabalho! Aqui, você tem muitas exibições de lista diferentes de seus itens de trabalho com escopo reduzido para você. Você pode exibir Atribuído a mim para ver rapidamente todo o trabalho atribuído a você ou Recentemente atualizado , que mostra todos os itens de trabalho em seu projeto que foram atualizados mais recentemente. Todas as opções de lista podem ser vistas abaixo:
Se você quiser definir ainda mais o escopo de suas listas, poderá filtrar o tipo, atribuído a, estado, área, marcas e palavra-chave. Depois de ter a exibição de lista desejada, você poderá classificar os itens de trabalho simplesmente clicando no cabeçalho da coluna. Se uma coluna for muito estreita para você exibir o conteúdo completo da coluna, você poderá redimensionar facilmente a coluna na área de cabeçalho. Essas experiências podem ser vistas abaixo:
Novos hubs de Quadros, Listas de Pendências 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 era o lar de muitos recursos. Isso geralmente dificulta a localização do recurso ou da funcionalidade que os usuários estavam procurando. Para resolver esse problema, dividimos o hub backlogs em:
- O hub backlogs agora é o lar apenas das listas de pendências de um projeto. Uma lista de pendências é uma lista priorizada de trabalho para a equipe. As listas de pendências fornecem ferramentas de planejamento, como hierarquia de itens de trabalho, previsão e nova experiência de planejamento de sprint.
- O novo hub boards é o lar de todos os Quadros Kanban para um projeto. Os quadros são usados para comunicar status e fluxo. Cartões (itens de trabalho) se movem da esquerda para a direita através das colunas definidas pela equipe.
- O novo hub sprints é o lar de recursos usados para planejar e executar um incremento de trabalho. Cada sprint contém uma lista de pendências de sprint, um quadro de tarefas e uma exibição para gerenciar e definir a capacidade para a equipe.
Novo hub de Consultas
O novo hub de consultas simplifica muitos dos recursos de consultas existentes do hub antigo com uma aparência mais moderna, bem como fornece novos recursos para facilitar o acesso às consultas que são importantes para você. Alguns destaques da nova experiência incluem:
- Páginas de diretório com última modificação por informações e a capacidade de pesquisar consultas
- Breadcrumb com URLs exclusivas para pastas para marcar grupos importantes de consultas
- Acesso rápido às suas consultas favoritas na página de resultados
Leia mais sobre essas atualizações interessantes em nosso blog do DevOps.
Mover itens de trabalho para outro projeto e alterar um tipo de item de trabalho
Agora você pode alterar o tipo de item de trabalho ou mover itens de trabalho para outro projeto dentro de uma coleção de projetos. Esses recursos exigem que o data warehouse esteja desabilitado. Com o data warehouse desabilitado, você 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 lista de pendências de sprint.
- Use filtros para Assignee, Work Item Type, State e Tags para adaptar as exibiçõ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:
- Continuar de onde parou Esta nova seção fornece um link rápido diretamente para o último (Board | Lista de pendências | Sprint) você estava.
- Favoritos Todos os seus quadros favoritos, sprints e pendências em todas as equipes.
- Meu Todas as placas, listas de pendências e sprints para equipes às quais você pertence.
- Todos Uma lista completa de todas as placas, listas de pendências e sprints.
Menu Novas Opções de Exibição
Os novos hubs, incluindo 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 quadro de tarefas, ativar o painel lateral para mapeamento e planejamento de sprints ou explorar gráficos de detalhes de trabalho.
Leia mais sobre essas atualizações interessantes, o novo painel Perfil de equipe e Favoritos em nosso blog de DevOps.
Anotações de cartão incluem bugs e tipos de item de trabalho personalizados
As anotações de cartão são adoradas por sua exibição e interação intuitivas de lista marcar. Anteriormente, cartão anotações eram limitadas a tipos de nível de lista de pendências padrão e não eram compatíveis com bugs ou tipos personalizados. Com a nova versão, removemos a restrição 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 cartão foram expandidas para incluir todos os tipos de item de trabalho disponíveis para esse nível de lista de pendências.
Quando as anotações do item de trabalho estão habilitadas, as contagens para esse tipo de item de trabalho são incluídas no cartão como uma lista de marcar separada.
A criação rápida de tipos de item de trabalho habilitados também está disponível por meio cartão menu de contexto.
Mover o trabalho usando áreas e iterações sugeridas
Pode ser comum trabalhar na mesma área ou iteração e navegar repetidamente pelas hierarquias ao mover itens de trabalho. Os controles Demarcador e Área agora incluem uma lista de valores usados recentemente como Sugestões, fornecendo acesso rápido para definir e seguir em frente.
Além disso, as datas de iteração são incluídas à direita do nome para que você possa julgar rapidamente quando um item de trabalho deve ser entregue.
Trabalho de consulta na agenda de iteração com +/- @CurrentIteration
A @CurrentIteration macro que ajuda sua equipe a acompanhar o trabalho com base no agendamento de iteração agora dá suporte a deslocamento inteiro. Mantenha guias facilmente sobre o trabalho que não foi fechado com @CurrentIteration - 1 ou examine o trabalho planejado para iterações futuras com @CurrentIteration + 1. Consulte a postagem @CurrentIteration no Blog do Microsoft DevOps para obter mais informações.
Esclarecer agendamentos de iteração de consulta com o @CurrentIteration parâmetro Team
Se você tiver usado a @CurrentIteration macro em consultas no passado, talvez tenha notado que os resultados podem variar se o contexto de equipe for alterado entre o Teams com agendamentos de iteração diferentes. Agora, ao criar ou modificar uma consulta com a @CurrentIteration macro, você precisará selecionar também a Equipe com o agendamento de iteração relevante para a consulta. Com o parâmetro Team, você pode usar a @CurrentIteration macro na mesma consulta, mas entre equipes. Um exemplo pode ser uma consulta para itens de trabalho em dois projetos de equipe diferentes usando nomes de iteração diferentes e até mesmo agendamentos. Isso significa que não é mais preciso atualizar 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 para apenas 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.
Consultar campos de rich text vazios
Encontre itens de trabalho que tenham um campo de rich text vazio, como Descrição, usando o novo operador de consulta IsEmpty .
Encontre facilmente itens de trabalho existentes em experiências de vinculação e menção
Quando você deseja vincular dois itens de trabalho existentes, agora você pode encontrar facilmente o item que é importante para você usando nosso novo controle de pesquisa de item de trabalho. O seletor de consulta foi substituído por sugestões embutidas com base em seus itens de trabalho acessados recentemente, bem como um ponto de entrada para pesquisar um item de trabalho específico por ID ou título.
Abrir itens de trabalho da pesquisa
Anteriormente, não era possível abrir um item de trabalho na página de resultados da pesquisa se o painel de visualização do item de trabalho estivesse desativado. Isso dificultaria a pesquisa dos resultados da pesquisa. Agora você pode clicar no título do item de trabalho para abrir os itens de trabalho em uma janela modal.
Repos
Seletor de ramificação aprimorado
A maioria das experiências em Azure Repos exige que você selecione um repositório e, em seguida, um branch nesse repositório. Para melhorar essa experiência para organizações com um grande número de branches, estamos lançando um novo seletor de branch. O seletor agora permite que você selecione seus branches favoritos ou pesquise rapidamente um branch.
Receber notificações quando as políticas de solicitação de pull forem ignoradas
Para equipes que usam PRs (pull requests) e políticas de branch, pode haver ocasiões em que as pessoas precisam substituir e ignorar essas políticas - por exemplo, ao implantar um hotfix em um problema de produção no meio da noite. Faz sentido confiar nos desenvolvedores para fazer a coisa certa e usar a funcionalidade de substituição com moderação. Ao mesmo tempo, as equipes precisam de uma maneira de verificar se essas substituições de política estão sendo usadas nas situações certas. Para dar suporte a isso, adicionamos um novo filtro de notificação para permitir que usuários e equipes recebam alertas de email sempre que uma política for ignorada. Comece com o modelo A pull request criado ou atualizado 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 PR for concluída e as políticas forem ignoradas.
Permitir ignorar políticas de branch sem abrir mão da proteção por push
Há muitos cenários em que você tem a necessidade ocasional de ignorar uma política de branch – revertendo uma alteração que causou uma quebra de build, aplicando um hotfix no meio da noite, etc. Anteriormente, oferecemos uma permissão ("Isento de imposição de políticas") para ajudar as equipes a gerenciar quais usuários receberam a capacidade de ignorar políticas de branch ao concluir uma solicitação de pull. No entanto, essa permissão também concedeu a capacidade de enviar por push diretamente para o branch, ignorando totalmente o processo de PR.
Para melhorar essa experiência, dividimos a permissão antiga para oferecer mais controle às equipes que estão concedendo permissões de bypass. Há duas novas permissões para substituir a antiga:
- 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.
- Ignorar políticas ao enviar por push. Os usuários com essa permissão poderão enviar por push diretamente para branches que tenham políticas necessárias configuradas.
Ao conceder a primeira permissão e negar a segunda, um usuário poderá usar a opção de bypass quando necessário, mas ainda terá a proteção de enviar por push acidentalmente para um branch com políticas.
Observação
Essa alteração não introduz nenhuma alteração de comportamento. Os usuários que anteriormente receberam a permissão Permitir para "Isentos de imposição de política" receberão a permissão Permitir para ambas as novas permissões, para que possam substituir a conclusão em PRs e enviar por push diretamente para branches com políticas.
Consulte a documentação Definir permissões de branch para obter mais informações.
Descrever rapidamente as solicitações de pull usando mensagens de confirmação
Gravar mensagens de confirmação descritivas adiciona valor ao histórico de qualquer repositório Git. Para incentivar mensagens de confirmação de qualidade, novas solicitações de pull (PR) que têm vários commits exigirão que os colaboradores insiram um título manualmente.
As descrições de solicitação de pull continuarão vazias por padrão, mas um novo recurso facilitará a incorporação das mensagens de confirmação das confirmações de PR na descrição de PR. Para adicionar as mensagens de confirmação, basta clicar em Adicionar mensagens de confirmação para acrescentar as mensagens de confirmação ao final do texto de descrição de PR.
Criar solicitações de pull sem uma equipe padrão como revisor
Quando iniciamos a experiência de pr (solicitação de pull) pela primeira vez, pensamos que faria sentido atribuir todas as PRs ao contexto de equipe selecionado ao criar a PR. Esse comportamento tem sido um ponto de frustração, já que muitas pessoas não notam a conexão entre o contexto da equipe e a atribuição de PR.
Como parte das novas alterações de navegação, aproveitamos a oportunidade para alterar essa associação padrão com as equipes. Você observará duas alterações:
- Ao criar uma PR, nenhum revisor é adicionado por padrão. A lista de revisores tem um recurso para facilitar a adição de indivíduos e grupos que foram adicionados a PRs recentemente. A política de revisores necessária também pode ajudar as equipes que desejam garantir que revisores específicos sejam adicionados para revisar seu código.
- O hub pull requests tem uma nova seção personalizável. Por padrão, esta seção mostra PRs "Atribuídos às minhas equipes", fornecendo funcionalidade equivalente como a seção antiga. No entanto, se você pertencer a várias equipes, esta seção mostrará PRs atribuídas a qualquer uma de suas equipes. A seção também é personalizável – basta clicar na ação "Personalizar esta exibição" perto do cabeçalho da seção.
Padronizar descrições de solicitação de pull usando modelos
Escrever boas descrições de solicitação de pull é uma ótima maneira de ajudar os revisores a saber o que esperar ao revisar o código. Eles também são uma ótima maneira de ajudar a acompanhar coisas que devem ser feitas 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 facilitar a gravação de ótimas descrições das equipes e agora adicionamos esse recurso.
Além de dar suporte a um modelo de descrição de PR padrão, as equipes podem adicionar vários modelos, que são apresentados a você em um menu na página criar PR. Basta clicar no botão Adicionar um modelo para escolher entre qualquer modelo no repositório para anexá-lo à descrição de PR.
Também há suporte para modelos específicos de ramificação se você quiser aplicar um modelo diferente para uma PR em uma ramificação ou pasta de branch específica. Por exemplo, se você quiser ter um modelo específico para todos os branches que começam com "hotfix/", você poderá adicionar um modelo que será usado para todas as PRs nesses branches.
Consulte a documentação de modelos de solicitação de pull para saber mais sobre como criar e usar modelos.
Alterar o branch de destino de uma solicitação de pull
Para a maioria das equipes, quase todas as solicitações de pull visam o mesmo branch, como main ou develop. No entanto, no caso em que você precisa direcionar um branch diferente, é fácil esquecer de alterar o branch de destino do padrão. Com o novo recurso para alterar o branch de destino de uma solicitação de pull ativa, essa agora é uma ação simples. Basta clicar no ícone de lápis próximo ao nome do branch de destino no cabeçalho da solicitação de pull.
Além de apenas corrigir erros, o recurso para alterar branches de destino também facilita a "redirecionação" de uma solicitação de pull quando o branch de destino foi mesclado ou excluído. Considere um cenário em que você tem uma PR direcionada a um branch de recurso que contém algum recurso do qual suas alterações dependem. Você deseja examinar suas alterações dependentes isoladamente de outras alterações no branch de recurso, para que inicialmente features/new-featurevocê direcione . Em seguida, os revisores podem ver apenas suas alterações e deixar os comentários apropriados.
Agora, considere o que aconteceria se o branch de recurso também tivesse uma PR ativa e fosse mesclado main antes de suas alterações? Anteriormente, você teria que abandonar suas alterações e criar uma nova PR em mainou mesclar sua PR em e, em features/new-featureseguida, criar outra PR de features/new-feature para main. Com essa nova ação para atualizar o branch de destino, você pode simplesmente alterar o branch de destino da PR de features/new-feature para main, preservando todo o contexto e comentários. Alterar o branch de destino até cria uma nova atualização para a PR, o que facilita a análise de diferenças anteriores antes da alteração do branch de destino.
Os autores de extensão podem consultar o contexto sobre o repositório atual
Um dos desafios para um autor de uma extensão de controle de versão é obter o contexto do repositório que está sendo exibido para o usuário, como o nome, a ID e a URL. Para ajudar com isso, adicionamos o VersionControlRepositoryService como um serviço acessível por extensão. Usando isso, um autor de extensão pode consultar informações sobre o contexto atual do repositório Git na interface do usuário da Web. Atualmente, ele tem um método, getCurrentGitRepository().
- Se um repositório Git estiver 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, nulo será retornado.
Aqui está uma extensão de exemplo que usa esse serviço.
Pipelines
Gerenciar pipelines de build usando a nova página Builds
Estamos fazendo várias melhorias e lançando uma nova versão da página Builds . Esta nova versão combina o diretório de todos os pipelines de build e a lista de builds atuais para que você possa navegar rapidamente pelos builds do projeto para ver seus status. Ele também inclui uma visualização da análise de teste para o pipeline selecionado.
Gerenciar emails de conclusão de build e implantação melhor usando a formatação aprimorada
Os emails de conclusão de build e implantação foram atualizados para serem mais filtrados pelas regras de email. Agora, a linha de assunto inclui informações mais relevantes rapidamente, o corpo contém mais detalhes e seu estilo foi atualizado com a marca mais recente.
Os elementos do novo formato são:
[Build result] [pipeline name] - [repository:branch] - [project name] - [commit][Deployment result] [pipeline name] > [release name] : [stage name]
Veja alguns exemplos:
[Build succeeded] IdentityService.CI - MyRepo:main - MyProject - d3b90b80[Deployment succeeded] New release pipeline > NotificationSpecialRelease-1 : Stage 1
Siga a nova terminologia unificada do Azure Pipelines
Ao longo de builds e versões, diferentes termos têm sido usados historicamente para conceitos semelhantes. Em outros casos, os significados dos termos eram vagos. Por exemplo, informando a diferença entre um pool de agentes e uma fila de agentes.
A terminologia foi unificada no Azure Pipelines para esclarecer seus conceitos. Agora você verá os seguintes termos unificados:
| Termo anterior | Termo unificado | Significado |
|---|---|---|
| Agente hospedado | Agente hospedado pela Microsoft | Um agente de build/versão executado na infraestrutura hospedada na nuvem gerenciada pela Microsoft. |
| Agente privado | Agente auto-hospedado | Um agente de build/versão executado em um computador fornecido e gerenciado por você. |
| Pool de agentes | Pool de agentes | Um conjunto de computadores de agente no nível da organização que pode executar builds ou versões. |
| Fila do agente | Pool de agentes | Um conjunto de computadores de agente no nível do projeto que podem executar builds ou versões. Ele está vinculado a um pool de agentes no nível da organização. |
| Definição da compilação | Pipeline de build | Um conjunto de etapas de build de ponta a ponta para um aplicativo. |
| Build | Build | Uma instância de um pipeline de build que está em execução ou foi executada. |
| Fase | Trabalho | Uma série de tarefas que são executadas sequencialmente ou em paralelo em um agente. Um pipeline de build ou lançamento pode conter um trabalho ou um grafo de vários trabalhos. |
| Definição de versão | Pipeline de lançamento | Um conjunto de etapas de versão de ponta a ponta para um aplicativo ser implantado em vários estágios. |
| Versão | Versão | Uma instância de um pipeline de lançamento que está em execução ou foi executada. |
| Ambiente | Estágio | Uma entidade lógica e independente que representa onde você deseja implantar uma versão gerada a partir de um pipeline de lançamento. |
| Trabalho/pipeline simultâneo | Trabalho paralelo | Um trabalho paralelo oferece a capacidade de executar um único trabalho de build ou lançamento por vez em sua organização. Com mais trabalhos paralelos disponíveis, você pode executar mais trabalhos de build e lançamento ao mesmo tempo. |
| Ponto de extremidade de serviço | Conexão de serviço | Um grupo de configurações, como credenciais, usado para se conectar a serviços externos para executar tarefas em um build ou versão. |
Consulte a documentação Conceitos para obter mais informações.
Gerenciar pipelines de lançamento usando a nova página Versões
Uma experiência de usuário nova e totalmente reprojetada está disponível para a página de aterrissagem da versão. Confira uma lista dos pipelines de lançamento que você lança com frequência à esquerda. Você também pode pesquisar seus pipelines e favoritos deles.
Altere para a exibição de pastas para criar pastas para organização e segurança. A segurança pode ser definida em um nível de pasta.
Visualizar o progresso da versão
A nova exibição de progresso da versão fornece atualizações dinâmicas do progresso da implantação e acesso de um clique para obter mais detalhes. A nova exibição visualiza o pipeline de lançamento, facilitando a compreensão do que está acontecendo e apresenta os detalhes e as ações apropriados em diferentes estágios da versão.
Pipeline, detalhes de versão e ambientes
A exibição Pipeline mostra os artefatos da versão e os ambientes em que eles serão implantados. A área Versão fornece detalhes de versão, como o gatilho de versão, versões de artefato e marcas.
Os ambientes são modelados de forma a ajudar a entender seus status, juntamente com o progresso detalhado. A qualquer momento, você pode acessar os logs clicando no link status no ambiente.
Pré-implantação e pós-implantação
Se as condições de pré-implantação ou pós-implantação tiverem sido definidas para um ambiente, ela será indicada no ambiente com a presença das aprovações e portões. O progresso das aprovações e dos portões também aparece no status do ambiente. Você pode executar uma ação ou exibir mais detalhes clicando no ícone de condição do ambiente pendurado no lado direito ou esquerdo do ambiente.
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 inserir uma exibição focada.
Impacto da atualização para o Azure DevOps Server 2019 em tarefas: Cópia de Arquivo do Windows Machine e PoweShell no Computador de Destino
Os grupos de computadores em Hub de Teste foram preteridos no TFS 2017 RTM. Com Azure DevOps Server 2019, o serviço Grupos de máquinas não está mais disponível. Isso afetará os usuários da tarefa 'Cópia de Arquivo do Windows Machine' versão 1.* e da tarefa 'PowerShell on Target Machines' versão 1.*. Para que seus pipelines continuem funcionando,
- Você precisa alternar para a tarefa "Cópia de Arquivo do Windows Machine" versão 2.* e fornecer o fqdn completo para o computador de destino em vez de apenas o nome do computador.
- E alterne para a tarefa 'Powershell on Target Machine' versão 2.* ou posterior e forneça o fqdn completo do nome do computador ou do computador seguido pelas portas de Gerenciamento Remoto do Windows (http/https). Por exemplo, targetMachine:5985 ou targetMachine:5986
Resultados do teste e extensibilidade
Os resultados da execução do teste também são exibidos para cada ambiente. Clicar nos resultados do teste abre uma exibição que contém detalhes do teste, incluindo resultados de outras extensões que contribuem para o processo.
As extensões existentes funcionam nessa nova exibição, além disso, há novos pontos de extensibilidade para permitir que as extensões se desenvolvam para exibir ainda mais informações para um ambiente. Consulte a documentação de contribuições e extensões para obter mais informações.
Configurar builds usando YAML
Os pipelines de build baseados em YAML estão disponíveis em seu Azure DevOps Server. Automatize seu pipeline de integração contínua usando um arquivo YAML verificado em seu repositório. Uma referência completa para o esquema YAML pode ser encontrada aqui.
Para dar suporte a pipelines de build baseados em YAML de forma mais direta, alteramos o comportamento padrão para todos os novos recursos criados (por exemplo, conexões de serviço, grupos de variáveis, pools de agentes e arquivos seguros) para serem utilizáveis em todo o pipeline desse projeto. Se você quiser um controle mais rígido sobre seus recursos, poderá desabilitar o modelo de autorização padrão (veja a figura abaixo). Quando você faz isso, alguém com permissões para usar o recurso deve salvar explicitamente o pipeline no editor da Web depois que uma referência de recurso é adicionada ao arquivo YAML.
Encadear compilações relacionadas usando gatilhos de conclusão de build
Produtos grandes têm vários componentes que dependem uns dos outros. Esses componentes geralmente são criados de forma independente. Quando um componente upstream (uma biblioteca, por exemplo) é alterado, as dependências downstream precisam ser recompiladas e revalidadas. Normalmente, as equipes gerenciam essas dependências manualmente.
Agora você pode disparar um build após a conclusão bem-sucedida de outro build. 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.
Tenha em mente que, em alguns casos, um único build de várias fases pode atender às suas necessidades. No entanto, um gatilho de conclusão de build será útil se seus requisitos incluirem configurações, opções ou uma equipe diferente para possuir o processo dependente.
Atualizar localmente seu agente
As tarefas instaladas por meio da Galeria às vezes exigem uma versão mais recente do agente de pipelines. Se o Azure DevOps Server puder se conectar à Internet, as versões mais recentes serão baixadas automaticamente. Caso contrário, você precisará atualizar manualmente cada agente. A partir desta versão, você pode configurar seu Azure DevOps Server para procurar os arquivos de pacote do agente em seu disco local e não na Internet. Isso oferece flexibilidade e controle sobre quais versões de agente você disponibiliza, sem precisar expor seus Azure DevOps Server à Internet.
Nova URL de selo de status de build
Os selos de build inseridos na home page de um repositório são uma maneira comum de mostrar a integridade do repositório. Embora tivéssemos selos de construção até agora, houve alguns problemas:
- A URL não era intuitiva
- O selo não era específico de um branch
- Não havia como um usuário clicar no selo para levar o usuário ao build mais recente dessa definição
Agora estamos lançando uma nova API para selos de build que resolve esses problemas. A nova API permite que os usuários publiquem uma status por branch e podem levar os usuários para o build mais recente do branch selecionado. Você pode obter o Markdown para a nova URL de selo do status selecionando a ação de menu Selo de status na nova página Builds.
Para compatibilidade com versões anteriores, continuaremos a honrar as URLs de selo de build mais antigas também.
Adicionar contadores de build personalizados aos seus builds
Os contadores de build fornecem uma maneira exclusiva de numerar e rotular builds. Anteriormente, você poderia usar a variável especial $(rev:r) para fazer isso. Agora você pode definir suas próprias variáveis de contador em sua definição de build que são incrementadas automaticamente toda vez que você executa um build. Você faz isso na guia variáveis de uma definição. Esse novo recurso oferece mais energia das seguintes maneiras:
- Você pode definir um contador personalizado e definir seu valor de semente. Por exemplo, você pode iniciar o contador em 100. $(rev:r) sempre começa em 0.
- Você pode usar sua própria lógica personalizada para redefinir um contador. $(rev:r) está vinculado à geração de números de build e é redefinido automaticamente sempre que há um novo prefixo no número de build.
- Você pode definir vários contadores por definição.
- Você pode consultar o valor de um contador fora de um build. Por exemplo, você pode contar o número de builds executados desde a última redefinição usando um contador.
Consulte a documentação sobre variáveis definidas pelo usuário para obter mais informações sobre contadores de build.
Azure Policy validações de conformidade e segurança em Pipelines
Queremos garantir a estabilidade e a segurança do software no início do processo de desenvolvimento, juntando desenvolvimento, segurança e operações. Para fazer isso, adicionamos suporte para Azure Policy.
O Azure Policy ajuda você a gerenciar e impedir problemas de TI com definições de políticas que impõem regras e efeitos para seus recursos. Quando você usa Azure Policy, os recursos permanecem em conformidade com seus padrões corporativos e contratos de nível de serviço.
Para cumprir as diretrizes de conformidade e segurança como parte do processo de lançamento, aprimoramos nossa experiência de implantação do grupo de recursos do Azure. Agora, estamos falhando na tarefa de implantação do Grupo de Recursos do Azure com erros relacionados à política relevantes em caso de violações durante a implantação de modelos do ARM.
Além disso, adicionamos Azure Policy modelo de definição de versão. Isso permitirá que os usuários criem políticas do Azure e atribuam essas políticas a recursos, assinaturas ou grupos de gerenciamento da própria definição de versão.
Compilar em plataformas Linux/ARM e Windows de 32 bits
O agente multiplataforma do Azure Pipelines código aberto sempre foi compatível com Windows, macOS e Linux de 64 bits (x64). Com esta versão, estamos apresentando duas novas plataformas com suporte: Linux/ARM e Windows/32 bits. Essas novas plataformas oferecem a capacidade de criar plataformas menos comuns, mas não menos importantes, como o Raspberry Pi, um computador Linux/ARM.
Experiências aprimoradas para testes em pipelines
A guia Testes agora tem uma experiência moderna que fornece informações avançadas de teste no contexto para Pipelines. A nova experiência fornece uma exibição de teste em andamento, experiência de depuração de página inteira, histórico de teste de contexto, relatório de execução de teste anulada e resumo do nível de execução.
Exibir a execução de testes em andamento
Testes, como integração e testes funcionais, podem ser executados por muito tempo, portanto, é importante ver a execução do teste a qualquer momento. Com o modo de exibição de teste In-Progress, você não precisa mais aguardar a conclusão da execução do teste para saber o resultado do teste. Os resultados estão disponíveis quase em tempo real à medida que são executados, ajudando você a executar ações mais rapidamente. Você pode depurar uma falha ou anular, arquivar um bug ou anular o pipeline. No momento, o recurso está disponível para pipeline de build e lançamento usando a Tarefa de Teste do VS na fase de Vários Agentes, usando a Tarefa Publicar Resultados do Teste ou publicando resultados de teste usando API(s). No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.
A exibição a seguir mostra o resumo do teste In-Progress na nova exibição de progresso da versão, relatando a contagem total de testes e o número de falhas de teste em um determinado ponto no tempo.
Ao clicar no resumo do teste In-Progress acima, você pode exibir o resumo detalhado do teste juntamente com informações de teste com falha ou anuladas em Test Plans. O resumo do teste é atualizado em um intervalo periódico com a capacidade de atualizar a exibição de detalhes sob demanda, com base na disponibilidade de novos resultados.
Exibir detalhes de depuração de execução de teste na página inteira
Mensagens de erro e rastreamentos de pilha são longos por natureza e precisam de imóveis suficientes para exibir os detalhes durante a depuração. Para ter uma experiência de depuração imersiva, agora você pode expandir o modo de exibição de teste ou execução de teste para o modo de exibição de página inteira, enquanto ainda pode executar o necessário em operações de contexto, como criação de bugs ou associação de requisitos para o resultado do teste atual.
Exibir o histórico de teste no contexto
Historicamente, as equipes teriam que ir para o Hub de execuções para exibir o histórico de um resultado de teste. Com a nova experiência, trazemos o histórico de teste diretamente no contexto dentro da guia Test Plans para compilação e lançamento. As informações do histórico de teste são fornecidas de maneira progressiva, começando com a definição ou o ambiente de build atual para o teste selecionado, seguido por outros branches e ambientes para o build e a versão, respectivamente.
Exibir testes anulados
A execução do teste pode ser anulada devido a vários motivos, como código de teste inválido, origem em teste e problemas ambientais. Independentemente do motivo da anulação, é importante diagnosticar o comportamento e identificar a causa raiz. Agora você pode exibir os testes anulados e as execuções de teste, juntamente com as execuções concluídas em Test Plans. No momento, o recurso está disponível para pipeline de build e lançamento usando a Tarefa de Teste do VS na fase de Vários Agentes ou publicando resultados de teste usando API(s). No futuro, planejamos estender essa experiência para execução de teste usando o Agente Único.
Suporte a ambientes de rastreamento e lançamento de teste no Histórico de Testes
Estamos adicionando suporte para exibir o histórico de um teste automatizado agrupado por vários ambientes de versão nos quais o teste é executado. Se você estiver modelando ambientes de versão como pipelines de lançamento ou ambientes de teste e executando testes em tais ambientes, poderá descobrir se um teste está passando no ambiente de desenvolvimento, mas falhando no ambiente de integração. Você pode descobrir se ele está passando na localidade inglesa, mas falhando em um ambiente que tem localidade turca. Para cada ambiente, você encontrará a 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 falhou.
Examinar os resultados do teste resumido
Durante a execução do teste, um teste pode gerar várias instâncias de testes que contribuem para o resultado geral. Alguns exemplos incluem: testes que são executados novamente devido a falhas, testes compostos por uma combinação ordenada de outros testes (por exemplo, teste ordenado) ou testes com instâncias diferentes com base no parâmetro de entrada fornecido (testes controlados por dados). Como esses testes estão relacionados, eles precisam ser relatados junto com o resultado geral derivado com base nos resultados de teste individuais. Com essa atualização, apresentamos uma versão aprimorada dos resultados do teste apresentada como uma hierarquia na guia Testes em uma versão. Vamos examinar um exemplo.
Anteriormente, introduzimos a capacidade de executar novamente testes com falha na tarefa teste do VS . No entanto, 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 Testes agora dá suporte à capacidade de publicar e consultar resultados de teste hierárquicos. Consulte a documentação da API de resultados de teste para obter mais informações.
Observação
As métricas na seção resumo do teste (por exemplo, Total de testes, Aprovados etc.), são computadas usando o nível raiz da hierarquia em vez de cada iteração individual dos testes.
Exibir análise de teste em Pipelines
Acompanhar a qualidade do teste ao longo do tempo e melhorar a garantia de teste é fundamental para manter um pipeline íntegro. O recurso de análise de teste fornece visibilidade quase em tempo real dos dados de teste para builds e pipelines de lançamento. Ela ajuda a melhorar a eficiência do pipeline identificando problemas repetitivos de qualidade de alto impacto.
Você pode agrupar resultados de teste por vários elementos, identificar testes de chave para seu branch ou arquivos de teste ou fazer drill down em um teste específico para exibir tendências e entender problemas de qualidade, como problemas de integridade.
Veja a análise de teste para builds e lançamentos, versão prévia abaixo:
Para obter mais informações, confira a documentação.
Simplificar definições com várias tarefas sem agente
As tarefas em uma fase sem agente são orquestradas por e executadas no servidor. As fases sem agente não exigem um agente ou nenhum computador de destino. Ao contrário das fases do agente, apenas uma tarefa poderia ser adicionada a cada fase sem agente nas definições. Isso significava que várias fases tinham que ser adicionadas quando havia mais de uma tarefa sem agente no processo, tornando a definição volumosa. Flexibilizamos essa restrição, o que permite que você mantenha várias tarefas em fases sem agente. As tarefas na mesma fase seriam executadas sequencialmente, assim como em fases de agente. Consulte a documentação de fases do servidor para obter mais informações.
Expor progressivamente e fases de implantações usando portões de lançamento
Usando portões de versão, você pode especificar critérios de integridade do aplicativo que devem ser atendidos antes que uma versão seja promovida para o próximo ambiente. Todos os portões especificados são avaliados periodicamente antes ou depois de qualquer implantação, até que todos sejam bem-sucedidos. Quatro tipos de portões estão disponíveis prontos para uso e você pode adicionar mais portões do Marketplace. Você poderá auditar que todos os critérios necessários para uma implantação foram atendidos. Consulte a documentação para as entradas de versão para obter mais informações.
Manter implantações até que os portões tenham êxito consistentemente
Os portões de liberação permitem a avaliação automática dos critérios de integridade antes que uma versão seja promovida para o próximo ambiente. Por padrão, a versão progride após um exemplo bem-sucedido para todos os portões ter sido recebido. Mesmo que um portão seja irregular e o exemplo bem-sucedido recebido seja ruído, a versão progride. Para evitar esses tipos de problemas, agora você pode configurar a versão para verificar a consistência da integridade por uma duração mínima antes de progredir. Em tempo de execução, a versão garantiria que as avaliações consecutivas dos portões fossem bem-sucedidas antes de permitir a promoção. O tempo total para avaliação depende de "tempo entre reavaliação" e normalmente seria maior do que a duração mínima configurada. Consulte a documentação Liberar controle de implantação de implantação usando portões para obter mais informações.
Implantar automaticamente em novos destinos em um grupo de implantação
Anteriormente, quando novos destinos eram adicionados a um grupo de implantação, era necessária uma implantação manual para garantir que todos os destinos tivessem a mesma versão. Agora você pode configurar o ambiente para implantar automaticamente a última versão bem-sucedida nos novos destinos. Consulte a documentação Grupos de Implantação para obter mais informações.
Implantar continuamente builds marcados pelo processamento pós-build
Os gatilhos de implantação contínua criam uma versão na conclusão do build. No entanto, às vezes, os builds são pós-processados e o build só deve ser liberado após a conclusão desse processamento. Agora você pode aproveitar as marcas de build, que seriam atribuídas durante o pós-processamento, nos filtros de gatilho da versão.
Definir uma variável no momento da versão
Em uma definição de versão, agora você pode escolher as variáveis que deseja definir ao criar a versão.
O valor fornecido para a variável quando a versão é criada é usado apenas para essa versão. Esse recurso ajudará você a evitar várias etapas para Criar em Rascunho, atualizar as variáveis no rascunho e disparar a versão com a variável .
Passar variáveis de ambiente para tarefas
Os autores de tarefas de CI/CD podem definir uma nova propriedade, showEnvironmentVariables, no task.json para passar variáveis de ambiente para tarefas. Quando você faz isso, um controle extra é renderizado na tarefa no editor de build. Isso está disponível para as tarefas powershell, cmd e bash .
Isso 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 é preferencial para passar os segredos como argumentos para os scripts, pois o sistema operacional no agente pode registrar a invocação de processos, incluindo seus argumentos.
Clonar grupos de variáveis
Adicionamos suporte para clonagem de grupos de variáveis. Sempre que você quiser replicar um grupo de variáveis e apenas atualizar algumas das variáveis, não precisará passar pelo processo tedioso de adicionar variáveis uma a uma. Agora você pode fazer rapidamente uma cópia do grupo de variáveis, atualizar os valores adequadamente e salvá-lo como um novo grupo de variáveis.
Observação
Os valores da variável secreta não são copiados quando você clona um grupo de variáveis. Você precisa atualizar as variáveis criptografadas e salvar o grupo de variáveis clonado.
Ignorar um portão de lançamento para uma implantação
Os portões de liberação permitem a avaliação automática dos critérios de integridade antes que uma versão seja promovida para o próximo ambiente. Por padrão, o pipeline de lançamento progride somente quando todos os portões estão íntegros ao mesmo tempo. Em determinadas situações, como ao agilizar uma liberação ou depois de verificar manualmente a integridade, um aprovador pode querer ignorar um portão e permitir que a liberação progrida mesmo que esse portão ainda não tenha sido avaliado como íntegro. A documentação dos portões de lançamento para obter mais informações.
Executar testes adicionais usando um gatilho de liberação de solicitação de pull
Você 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. A status da versão será postada novamente no repositório de código e poderá ser vista diretamente na página pr. Isso será útil se você quiser executar testes funcionais ou manuais adicionais como parte do fluxo de trabalho de PR.
Criar conexão de serviço do Azure com a entidade de serviço que se autentica com um certificado
Agora você pode definir uma conexão de serviço do Azure com uma entidade de serviço e um certificado para autenticação. Com a conexão de serviço do Azure agora dando suporte à entidade de serviço que se autentica com um certificado, agora você pode implantar no Azure Stack configurado com o AD FS. Para criar uma entidade de serviço com autenticação de certificado, consulte o artigo sobre como criar uma entidade de serviço que se autentica com um certificado.
Executar do pacote com suporte em implantações de Serviço de Aplicativo do Azure
A versão da tarefa implantar Serviço de Aplicativo do Azure (4.*) agora dá suporte a RunFromPackage (anteriormente chamado runFromZip.
Serviço de Aplicativo dá suporte a várias técnicas diferentes para implantar seus arquivos, como msdeploy (também conhecido como WebDeploy), git, ARM e muito mais. Mas todas essas técnicas têm uma limitação. Seus arquivos são implantados na pasta wwwroot (especificamente d:\home\site\wwwroot) e, em seguida, o runtime executa os arquivos a partir daí.
Com Executar do Pacote, não há mais uma etapa de implantação que copia os arquivos individuais para wwwroot. Em vez disso, basta apontá-lo para um arquivo zip e o zip é montado em wwwroot como um sistema de arquivos somente leitura. Isso tem várias vantagens:
- Reduz o risco de problemas de bloqueio de cópia de arquivo.
- Pode ser implantado em um aplicativo de produção (com reinicialização).
- Você pode ter certeza dos arquivos que estão em execução no seu aplicativo.
- Melhora o desempenho de implantações de Serviço de Aplicativo do Azure.
- Pode reduzir os tempos de inicialização a frio, particularmente para as funções de JavaScript com árvores de pacote npm grandes.
Implantar contêineres do Linux com a tarefa Implantar do Servidor de Aplicativos
A versão 4.* da tarefa implantar Serviço de Aplicativo do Azure agora dá suporte à implantação de seu próprio contêiner personalizado para Azure Functions no Linux.
O modelo de hospedagem do Linux para Azure Functions baseia-se em contêineres do Docker que trazem maior flexibilidade em termos de empacotamento e aproveitamento de dependências específicas do aplicativo. As funções no Linux podem ser hospedadas em dois modos diferentes:
- Imagem de contêiner interno: Você traz o código do Aplicativo de Funções e o Azure fornece e gerencia o contêiner (modo de imagem interno), portanto, nenhum conhecimento específico relacionado ao Docker é necessário. Isso tem suporte na versão existente da tarefa Implantar Serviço de Aplicativo.
- Imagem de contêiner personalizada: Aprimoramos a tarefa Implantar Serviço de Aplicativo para dar suporte à implantação de imagens de contêiner personalizadas em Azure Functions no Linux. Quando suas funções precisam de uma versão de linguagem específica ou exigem uma dependência ou configuração específica que não é fornecida dentro da imagem interna, você pode criar e implantar uma imagem personalizada no Azure Function no Linux usando o Azure Pipelines.
A tarefa Xcode dá suporte ao Xcode 10 recém-lançado
Coincidindo com o lançamento do Xcode 10 da Apple, agora você pode definir seus projetos para 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 macOS hospedado pela Microsoft para executar essas compilações. Confira as diretrizes para usar o Xcode no Azure Pipelines.
Simplificar a implantação no Kubernetes usando o Helm
O Helm é uma ferramenta que simplifica a instalação e o gerenciamento de aplicativos kubernetes. Também ganhou muita popularidade e apoio da comunidade no último ano. Uma tarefa do Helm em Versão agora está disponível para empacotar e implantar gráficos do Helm no AKS (Serviço de Contêiner do Azure) ou em qualquer outro cluster do Kubernetes.
Com a adição dessa tarefa do Helm, agora você pode configurar um pipeline de CI/CD baseado no Helm para entregar contêineres em um cluster do Kubernetes. Confira a documentação Implantar usando o Kubernetes no Serviço de Contêiner do Azure para obter mais informações.
Controlar a versão do Helm usada na versão
A tarefa Instalador de Ferramentas do Helm adquire uma versão específica do Helm da Internet ou do cache de ferramentas e a adiciona ao PATH do agente (hospedado ou privado). Use essa tarefa para alterar a versão do Helm usada em tarefas subsequentes, como a tarefa da CLI do .NET Core . Adicionar essa tarefa antes da tarefa 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 certa do Helm. Essa tarefa também ajuda a instalar opcionalmente a ferramenta kubectl , que é um pré-requisito para o Helm funcionar.
Implantar continuamente no Banco de Dados do Azure para MySQL
Agora você pode implantar continuamente no Banco de Dados do Azure para MySQL – banco de dados MySQL do Azure como um serviço. Gerencie seus arquivos de script MySQL no controle de versão e implante continuamente como parte de um pipeline de lançamento usando uma tarefa nativa em vez de scripts do PowerShell.
Usar tarefas aprimoradas baseadas no PowerShell remoto do Windows
Tarefas novas e aprimoradas baseadas no Windows PowerShell remoto 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 de PSSession, controlar "ErrorActionPreference" e falhar no erro padrão.
Tarefa Cópia de Arquivo do Azure (versão: 2.*): é fornecida com o AzCopy mais recente (v7.1.0) que resolve um problema do GitHub.
Filtrar branches para artefatos github enterprise ou externos do Git
Ao liberar do GitHub Enterprise ou repositórios Git externos, agora você pode configurar os branches específicos que serão lançados. Por exemplo, talvez você queira implantar apenas builds provenientes de um branch específico para produção.
Criar aplicativos escritos em Go
Use a tarefa Go Tool Installer para instalar uma ou mais versões da Ferramenta Go em tempo real. Essa tarefa adquire uma versão específica da Ferramenta Go necessária para seu projeto e a adiciona ao PATH do agente de build. Se a versão da Ferramenta Go de destino já estiver instalada no agente, essa tarefa ignorará o processo de baixá-la e instalá-la novamente.
A tarefa Go ajuda você a baixar dependências, compilar ou testar seu aplicativo. Você também pode usar essa tarefa para executar um comando Go personalizado de sua escolha.
Executar scripts python embutidos ou baseados em arquivo em seu pipeline
Uma nova tarefa script python simplifica a execução de scripts python em seu pipeline. A tarefa executará um script de um arquivo Python (.py) em seu repositório ou você poderá inserir manualmente um script nas configurações da tarefa, para salvar como parte do pipeline. A tarefa usará a versão do Python no caminho ou você poderá especificar um caminho absoluto para um interpretador do Python a ser usado.
Aproveitar a saída de teste e compilação do Xcode aprimorada do xcpretty
xcpretty aprimora a legibilidade da saída do xcodebuild e gera resultados de teste no formato JUnit. A tarefa de build do Xcode agora usa automaticamente xcpretty quando está disponível no computador do agente, pois está em agentes macOS hospedados. Embora a saída xcpretty possa ser diferente e menos detalhada do que a saída do xcodebuild, disponibilizamos os logs xcodebuild completos com cada build.
Test Plans
Cliente do Test Runner (Azure Test Plans) para executar testes manuais para aplicativos da área de trabalho
Agora você pode usar o cliente test runner (Azure Test Plans) para executar testes manuais para aplicativos da área de trabalho. Isso ajudará você a mudar do Microsoft Test Manager para o Azure Test Plans. Consulte nossas diretrizes aqui. Usando o cliente test runner, você pode executar seus testes manuais e registrar os resultados do teste para cada etapa de teste. Você também tem recursos de coleta de dados, como captura de tela, log de ações de imagem e gravação de vídeo de áudio. Se você encontrar um problema ao testar, use o Test Runner para criar um bug com etapas de teste, capturas de tela e comentários incluídos automaticamente no bug.
O Executor de Teste (Azure Test Plans) requer um download único e uma instalação do executor. Selecione Executar para aplicativo da área de trabalho , conforme mostrado abaixo.
Artifacts
Fontes upstream
Azure DevOps Server 2019 traz atualizações substanciais para as fontes de upstream disponíveis nos feeds do Azure Artifacts:
- Você pode adicionar nuget.org fontes upstream a feeds existentes criados em versões anteriores do TFS. Procure a faixa acima dos pacotes do feed para obter mais informações, incluindo alterações de comportamento que você deve estar ciente antes de atualizar.
- Você pode adicionar outros feeds Azure DevOps Server como fontes de upstream ao feed, o que significa que você pode usar pacotes NuGet e npm desses feeds por meio do feed.
Também introduzimos uma nova função no Azure Artifacts: "Colaborador". Um Colaborador pode salvar pacotes de uma fonte de upstream, mas não pode publicar pacotes diretamente no feed (por exemplo, usando a publicação de nuget). Isso permite restringir a publicação de pacotes a um usuário confiável ou ao sistema de build, permitindo que seus engenheiros usem novos pacotes de suas fontes de upstream.
Seguir pacotes
Facilitamos ainda mais a configuração de notificações com um novo botão Seguir diretamente em cada pacote. O botão Seguir também é compatível com exibições de versão. Se você seguir um pacote enquanto o examina por meio de um modo de exibição, você só receberá atualizações para novas versões promovidas para esse modo de exibição.
Alterar as configurações do feed sem precisar salvar manualmente
Algumas das interações na página de configurações do feed foram aprimoradas. Agora, as alterações feitas, como a adição de um upstream ou uma permissão, são salvas imediatamente. Isso significa que você não precisa se preocupar com a perda de alterações ao alternar entre as configurações dinâmicas.
Simplificar a autenticação com o novo Provedor de Credenciais multiplataforma para NuGet
Interagir com feeds do NuGet autenticados ficou muito melhor. O novo Provedor de Credenciais do Azure Artifacts baseado no .NET Core funciona com msbuild, dotnet e nuget(.exe) no Windows, macOS e Linux. Sempre que você quiser usar pacotes de um feed do Azure Artifacts, o Provedor de Credenciais adquirirá e armazenará automaticamente um token em nome do cliente NuGet que você está usando. Você não precisa mais armazenar e gerenciar manualmente um token em um arquivo de configuração.
Para obter o novo provedor, vá para o GitHub e siga as instruções para seu cliente e plataforma.
Compactar símbolos ao publicar em um compartilhamento de arquivos
Atualizamos a tarefa 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. Em seguida, os leitores precisam examinar o código para encontrar a documentação certa. Agora você pode simplesmente publicar arquivos markdown de repositórios de código e hospedá-los no Wiki.
No Wiki, comece clicando em Publicar código como wiki. Em seguida, você pode especificar uma pasta em um repositório Git que deve ser promovida.
Depois de clicar em Publicar, todos os arquivos markdown na pasta selecionada serão publicados como um wiki. Isso também mapeará o cabeçalho do branch para o wiki para que todas as alterações feitas no repositório Git sejam refletidas imediatamente.
Confira a postagem no blog da documentação do produto para obter mais informações.
Vincular a títulos em uma página
Agora você pode clicar no ícone de link ao lado de qualquer título de seção em uma página wiki para gerar uma URL diretamente para essa seção. Em seguida, você pode copiar essa URL e compartilhá-la com os membros da equipe para vinculá-las diretamente a essa seção.
Anexar arquivos e imagens em pastas
Ao editar páginas wiki offline, pode ser mais fácil adicionar anexos de arquivo e imagens no mesmo diretório que a página wiki. Agora, você pode adicionar um anexo ou uma imagem em qualquer pasta no wiki e vinculá-lo à sua página.
Inserir um vídeo na wiki
Agora você pode inserir vídeos em uma página wiki de serviços online como Microsoft Stream e YouTube. Você pode adicionar a URL de vídeo inserida usando a seguinte sintaxe:
::: video
<iframe width="560" height="315" src="https://www.youtube.com/embed/7DbslbKsQSk" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
:::
Renomear uma wiki
Agora você pode renomear seu wiki na interface do usuário wiki e usando APIs REST. No menu Mais , clique em Renomear wiki para dar um nome memorável ao wiki.
Abrir página na nova guia
Agora você pode clicar com o botão direito do mouse em uma página wiki e abri-la em uma nova guia ou simplesmente pressionar CTRL + clique à esquerda em uma página wiki para abri-la em uma nova guia.
Reter caracteres especiais em títulos de página wiki
Agora você pode criar páginas wiki com caracteres especiais, como : < > * ? | -. Agora páginas com títulos como "Perguntas frequentes?" ou "Guia de configuração" pode ser criado no Wiki. Os seguintes caracteres são traduzidos para suas cadeias de caracteres codificadas 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 um ícone de link quebrado, fornecendo uma pista visual de todos os links quebrados em uma página wiki.
Corrigir links quebrados ao mover páginas
Links de páginas quebrados são uma das principais causas de má qualidade de página em qualquer solução de documentação. Anteriormente no Wiki, quando você moveu uma página dentro da estrutura de árvore ou renomeou uma página, ela poderia potencialmente quebrar links para a página de outras páginas e itens de trabalho. Agora, você pode marcar e corrigir links antes que eles sejam quebrados.
Importante
Lembre-se de usar a []() sintaxe markdown para links em páginas e o tipo de link da página Wiki em itens de trabalho para permitir que o Wiki localize e corrija esses links potencialmente quebrados. URLs de texto sem formatação e hiperlinks em itens de trabalho não serão captados por esse recurso.
Ao renomear ou mover uma página, você será solicitado a marcar para links absolutos ou relativos afetados.
Em seguida, você verá uma lista dos links de página e itens de trabalho afetados antes de agir.
Criar um sumário para páginas wiki
Às vezes, as páginas wiki podem ficar longas, com o conteúdo organizado em vários títulos. Agora você pode adicionar um sumário a qualquer página que tenha pelo menos um título usando a [[_TOC_]] sintaxe.
Você também pode inserir um sumário clicando no botão apropriado no painel de formato ao editar a página.
Consulte a documentação de diretrizes de markdown para obter mais informações sobre como usar markdown no Azure DevOps.
Metadados do Surface para páginas wiki e visualização de código usando marcas YAML
Adicionar metadados à documentação pode ajudar leitores e índices de pesquisa a captar e exibir conteúdo significativo. Nesta atualização, qualquer arquivo que contenha um bloco YAML no início do arquivo será transformado em uma tabela de metadados de uma cabeça e uma linha. O bloco YAML deve assumir a forma de conjunto YAML válido entre linhas triplas tracejadas. Ele dá suporte a todos os tipos de dados básicos, lista, objeto como valor. Há suporte para a sintaxe no Wiki e na versão prévia do arquivo de código.
Exemplo de marcas YAML:
---
tag: post
title: Hello world
---
Exemplo de marcas YAML com lista:
---
tags:
- post
- code
- web
title: Hello world
---
Publicar código como wiki com permissões do Contribute
Anteriormente, somente os usuários que tinham permissão Criar Repositório em um repositório git eram capazes de publicar código como wiki. Isso tornou os administradores ou criadores do repositório um gargalo para quaisquer solicitações para publicar arquivos markdown hospedados em repositórios git como wikis. Agora, você pode Publicar código como wiki se tiver apenas a permissão Contribuir no repositório de código.
Relatórios
A extensão do marketplace do Analytics para relatórios agora está disponível
A extensão do Marketplace de Análise agora está disponível para Azure DevOps Server. A análise é o futuro dos relatórios para o Azure DevOps e Azure DevOps Server. A instalação da extensão do Analytics fornece widgets avançados, integração do Power BI e acesso OData.
Para obter mais informações, marcar o Que é Análise e o Roteiro de Relatórios. A análise está em Visualização Pública. Atualmente, ele contém dados para boards e resultados de teste automatizado por meio de Pipelines. Consulte Dados disponíveis no Serviço de Análise.
Investigar o histórico de build por meio de um novo widget de dashboard de build
Temos um widget de histórico de build novo e aprimorado que você pode adicionar aos seus painéis. Com esse widget, agora você pode exibir um histórico de builds de um branch específico em seu dashboard e configurá-lo em um projeto público para visitantes anônimos.
Importante
Se você estiver procurando insights sobre seus builds XAML, continue usando o widget mais antigo e leia sobre como migrar de builds XAML para novos builds. Caso contrário, recomendamos que você mude para o widget mais recente.
Comentários
Adoraríamos ouvir sua opinião! Você pode relatar um problema ou fornecer uma ideia e rastreá-lo por meio de Developer Community e obter conselhos sobre o Stack Overflow.