Compartilhar via

Melhorias do YAML no Azure Pipelines – Atualização do Sprint 142

  • Artigo

Na Atualização do Sprint 142 do Azure DevOps, houve várias melhorias no YAML, como adicionar contadores personalizados aos seus builds, especificar branches para compilar para solicitações de pull e usar modelos embutidos. Também ativamos a nova navegação para todos os usuários, introduzimos um tema escuro e aprimoramos as experiências de vinculação e anexos em Azure Boards.

Confira a lista Recursos abaixo para obter mais informações.

Recursos

Geral:

Azure Boards:

Azure Repos:

Azure Pipelines:

Azure Test Plans:

Azure Artifacts:

Wiki:

Administração:

Geral

A nova navegação está ativada para todos os usuários

Ativamos nossa nova navegação para todos os usuários! Este é um marco importante na implantação do nosso novo design de produto. Enquanto estamos movendo todos para o novo modelo de navegação com esta versão, os usuários ainda poderão recusar e usar a navegação antiga até 16 de janeiro de 2019. Você pode recusar selecionando Visualizar recursos no menu abaixo do avatar no canto superior direito de cada página.

Consulte a postagem no blog Atualização de Navegação para obter mais informações.

Tema escuro

Uma de nossas solicitações de recursos de longa data foi oferecer um tema escuro. Estamos felizes em informá-lo de que isso agora está disponível como parte da nova navegação. Você pode ativar o tema escuro selecionando Tema no menu abaixo do avatar no canto superior direito de cada página.

Tema escuro

Azure Boards

Organizar materiais de referência com anexos de item de trabalho mais avançados

Anexar arquivos a itens de trabalho permite que você e sua equipe centralizem materiais de referência para que eles estejam sempre próximos quando você precisar deles. Agora é mais fácil adicionar um novo anexo simplesmente arrastando e soltando o arquivo em qualquer lugar no formulário do item de trabalho. Você pode continuar exibindo os anexos como uma lista ou alternar para uma exibição de grade para mostrar uma visualização em miniatura. Clique duas vezes no arquivo para abrir uma visualização e percorra-a para localizar rapidamente as informações necessárias.

Anexos de item de trabalho

Gerenciar dependências vinculando itens de trabalho em suas organizações

A vinculação de trabalhos relacionados ou dependentes oferece um contexto mais amplo ao trabalho que você está acompanhando e ajuda a gerenciar dependências com outras equipes. Com links para trabalho remoto, agora você pode acompanhar o trabalho entre organizações em sua empresa. Basta copiar a URL de um item de trabalho existente, ir para outro item de trabalho e criar um link usando um dos três novos tipos de link: Consumes From, Produces For e Remote Related. Consulte a documentação de vinculação de item de trabalho para obter mais informações sobre rastreabilidade em Azure Boards.

Observação

As permissões são respeitadas em ambas as organizações do Azure DevOps, que devem ter o mesmo Azure AD locatário.

Link remoto

À medida que você começa a gerenciar várias dependências, use o novo campo Contagem de Link Remoto em Consultas para listar os itens de trabalho que têm dependências remotas em seu projeto ou considere instalar a extensão do Rastreador de Dependências . Essa extensão, que foi criada pelo grupo do Windows na Microsoft para atender às suas necessidades de escala, baseia-se em links remotos para exibir uma hierarquia avançada e uma representação gráfica de suas dependências.

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

Azure Repos

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

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

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

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

Azure Pipelines

Adicionar contadores de build personalizados aos seus builds

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

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

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

Usar YAML para especificar branches a serem compilados para solicitações de pull

Os pipelines YAML podem especificar quais branches criar para PRs (solicitações de pull). Você pode escolher branches para incluir e excluir. Essa capacidade estava disponível anteriormente na interface do usuário da Web. Ao movê-lo para o arquivo YAML, ele se torna parte do fluxo de trabalho de configuração como código.

Um exemplo de como usar gatilhos de PR pode ser semelhante a:

pr:
  branches:
    include:
    - features/*
    exclude:
    - features/experimental/*
  paths:
    include:
    - **/*.cs

steps:
- script: echo My PR build!

Usar expressões de modelo YAML embutidas

Os modelos YAML são uma maneira poderosa de reutilizar partes de pipelines. Além de considerar o código comum, as expressões de modelo permitem alterar valores e controlar o que o YAML está incluído. Até agora, uma expressão de modelo tinha que ocupar todo o valor em uma expressão YAML. Este exemplo funcionaria porque a expressão é o valor inteiro da propriedade da solução .

- task: msbuild@1
  inputs:
    solution: ${{ parameters.solution }}

Agora relaxamos a restrição e permitimos modelos embutidos, como você vê no exemplo abaixo.

- script: echo The solution file is ${{ parameters.solution }}

Melhorar a solução de problemas com o log de inicialização de pipeline

Quando um pipeline é executado, o Azure Pipelines precisa garantir que a definição do pipeline esteja correta, decidir quais trabalhos agendar, solicitar que agentes executem os trabalhos e muito mais. Até agora, esse processo era completamente opaco, então quando as coisas deram errado, era quase impossível para um cliente solucionar o problema. Estamos introduzindo um novo tipo de log, chamado de log de inicialização de pipeline, o que torna esses detalhes visíveis. Você pode acessar o log de inicialização do pipeline escolhendo a opção Baixar todos os logs em um build concluído.

Retenção padrão para pipelines YAML

Estamos trabalhando em uma maneira de os usuários configurarem políticas de retenção para pipelines YAML. Até que esse novo recurso esteja disponível, aumentamos a retenção padrão para todos os builds YAML para 30 dias, já que muitos usuários desejam manter seus builds por mais tempo do que nossa retenção padrão de 10 dias anterior. Removemos a guia de retenção no editor de pipelines YAML até que o novo modelo esteja em vigor.

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). Neste sprint, 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.

Clonar grupos de variáveis

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

Clonar grupo de variáveis

Observação

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

Consulte commits e itens de trabalho para todas as fontes vinculadas

Continuando nosso compromisso com a melhor rastreabilidade, estamos felizes em anunciar que os clientes agora podem ver os detalhes dos itens de confirmação e de trabalho para todos os artefatos vinculados ao pipeline. Por padrão, o item de confirmação e de trabalho é comparado com a última implantação para o mesmo estágio. No entanto, você pode comparar com qualquer outra implantação anterior, se necessário.

Fontes vinculadas

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

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

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

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

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

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

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

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

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

Azure Test Plans

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

Agora você pode usar o cliente ATR (Azure Test Runner) 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 ATR, 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.

A ATR requer um download único e uma instalação do executor. Selecione Executar para aplicativo da área de trabalho , conforme mostrado abaixo.

Executor de Teste do Azure

Instalação do Executor de Teste do Azure

Azure Artifacts

Visualização pública do Pipeline Artifacts

Estamos lançando uma versão prévia pública do Pipeline Artifacts, um novo tipo de artefato altamente escalonável projetado para uso com o Azure Pipelines. O Pipeline Artifacts se baseia na mesma tecnologia usada pelo recurso Pacotes Universais anunciado recentemente e pode reduzir drasticamente o tempo necessário para armazenar saídas de build para grandes builds de classe empresarial.

Wiki

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.

Administração

PATs impõem CAP

Em fevereiro de 2017, anunciamos suporte para a CAP (Política de Acesso Condicional) do Azure Active Directory, mas havia uma limitação de que mecanismos de autenticação alternativos, como tokens de acesso pessoal, não impliquem o CAP. Estamos felizes em anunciar que preenchemos essa lacuna e o Azure DevOps agora honrará as políticas de isolamento de IP da CAP ao usar PATs, chaves SSH, credenciais de autenticação alternativas e OAuth. Os administradores não precisam fazer nada para aproveitar esse recurso. Ele será aplicado automaticamente a todas as políticas existentes.

Próximas etapas

Observação

Esses recursos serão implantados nas próximas duas a três semanas.

Leia sobre os novos recursos abaixo e vá até o Azure DevOps para experimentá-los por conta própria.

Ir para o Azure DevOps

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre esses recursos. Use o menu de comentários para relatar um problema ou fornecer uma sugestão.

Fazer uma sugestão

Você também pode receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.

Obrigada,

Aaron Bjork