Personalizar o pipeline

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Este é um guia passo a passo sobre formas comuns de personalizar o seu oleoduto.

Pré-requisito

Siga as instruções na Criar o seu primeiro oleoduto para criar um gasoduto de trabalho.

Compreenda o azure-pipelines.yml ficheiro

Um oleoduto é definido usando um ficheiro YAML no seu repo. Normalmente, este ficheiro é nomeado azure-pipelines.yml e está localizado na raiz do seu repo.

Navegue na página Pipelines em Azure Pipelines, selecione o pipeline que criou e escolha Editar no menu de contexto do pipeline para abrir o editor YAML para o pipeline.

Nota

Para obter instruções sobre como visualizar e gerir os seus oleodutos no portal Azure DevOps, consulte os gasodutos de navegação.

Examine o conteúdo do ficheiro YAML.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

 steps:
 - task: Maven@3
   inputs:
     mavenPomFile: 'pom.xml'
     mavenOptions: '-Xmx3072m'
     javaHomeOption: 'JDKVersion'
     jdkVersionOption: '1.11'
     jdkArchitectureOption: 'x64'
     publishJUnitResults: false
     testResultsFiles: '**/surefire-reports/TEST-*.xml'
     goals: 'package'

Nota

O conteúdo do seu ficheiro YAML pode ser diferente dependendo da amostra repo com que começou, ou atualizações feitas em Pipelines Azure.

Este oleoduto funciona sempre que a sua equipa empurra uma mudança para o ramo principal do seu repo ou cria um pedido de puxar. Funciona numa máquina Linux, hospedada pela Microsoft. O processo de gasoduto tem um único passo, que é executar a tarefa Maven.

Alterar a plataforma para construir

Você pode construir o seu projeto em agentes hospedados pela Microsoft que já incluem SDKs e ferramentas para várias línguas de desenvolvimento. Ou pode usar agentes auto-hospedados com ferramentas específicas de que precisa.

  • Navegue para o editor para o seu pipeline selecionando editar a ação do gasoduto na construção ou selecionando Editar na página principal do pipeline.

  • Atualmente, o oleoduto funciona com um agente Linux:

    pool:
      vmImage: "ubuntu-latest"
    
  • Para escolher uma plataforma diferente como Windows ou Mac, altere o vmImage valor:

    pool:
      vmImage: "windows-latest"
    
    pool:
      vmImage: "macos-latest"
    
  • Selecione Guardar e, em seguida, confirme as alterações para ver o seu pipeline funcionar numa plataforma diferente.

Adicionar passos

Pode adicionar mais scripts ou tarefas como passos ao seu oleoduto. Uma tarefa é um script pré-embalado. Pode utilizar tarefas para construir, testar, publicar ou implementar a sua aplicação. Para a Java, a tarefa Maven que usámos lida com os resultados de testes e publicações, no entanto, também podes usar uma tarefa para publicar resultados de cobertura de código.

  • Abra o editor yaml para o seu oleoduto.

  • Adicione o seguinte corte no final do seu ficheiro YAML.

    - task: PublishCodeCoverageResults@1
      inputs:
        codeCoverageTool: "JaCoCo"
        summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml"
        reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco"
        failIfCoverageEmpty: true
    
  • Selecione Guardar e, em seguida, confirmar as alterações.

  • Pode ver os resultados da cobertura do seu teste e código selecionando a sua construção e indo para os separadores de Teste e Cobertura .

Construir em várias plataformas

Pode construir e testar o seu projeto em várias plataformas. Uma maneira de fazê-lo é com strategy e matrix. . Você pode usar variáveis para colocar convenientemente dados em várias partes de um oleoduto. Para este exemplo, usaremos uma variável para passar em nome da imagem que queremos usar.

  • No seu azure-pipelines.yml ficheiro, substitua este conteúdo:

    pool:
      vmImage: "ubuntu-latest"
    

    com o seguinte conteúdo:

    strategy:
      matrix:
        linux:
          imageName: "ubuntu-latest"
        mac:
          imageName: "macOS-latest"
        windows:
          imageName: "windows-latest"
      maxParallel: 3
    
    pool:
      vmImage: $(imageName)
    
  • Selecione Guardar e, em seguida, confirme as alterações para ver a sua construção correr até três empregos em três plataformas diferentes.

Cada agente só pode gerir um trabalho de cada vez. Para executar vários trabalhos em paralelo, tem de configurar vários agentes. Também precisa de empregos paralelos suficientes.

Construir usando várias versões

Para construir um projeto usando diferentes versões desse idioma, você pode usar uma matrix de versões e uma variável. Neste passo, você pode construir o projeto Java com duas versões diferentes de Java numa única plataforma ou executar diferentes versões de Java em diferentes plataformas.

Nota

Não é possível utilizar strategy múltiplos vezes num contexto.

  • Se pretender construir numa única plataforma e em várias versões, adicione a seguinte matriz ao seu azure-pipelines.yml ficheiro antes da tarefa Maven e depois da .vmImage

    strategy:
      matrix:
        jdk10:
          jdkVersion: "1.10"
        jdk11:
          jdkVersion: "1.11"
      maxParallel: 2
    
  • Em seguida, substitua esta linha na sua tarefa maven:

    jdkVersionOption: "1.11"
    

    com esta linha:

    jdkVersionOption: $(jdkVersion)
    
  • Certifique-se de mudar a $(imageName) variável de volta para a plataforma à sua escolha.

  • Se pretender construir em várias plataformas e versões, substitua todo o conteúdo do seu azure-pipelines.yml ficheiro antes da tarefa de publicação com o seguinte corte:

    trigger:
    - main
    
    strategy:
      matrix:
        jdk10_linux:
          imageName: "ubuntu-latest"
          jdkVersion: "1.10"
        jdk11_windows:
          imageName: "windows-latest"
          jdkVersion: "1.11"
      maxParallel: 2
    
    pool:
      vmImage: $(imageName)
    
    steps:
    - task: Maven@3
      inputs:
        mavenPomFile: "pom.xml"
        mavenOptions: "-Xmx3072m"
        javaHomeOption: "JDKVersion"
        jdkVersionOption: $(jdkVersion)
        jdkArchitectureOption: "x64"
        publishJUnitResults: true
        testResultsFiles: "**/TEST-*.xml"
        goals: "package"
    
  • Selecione Save e, em seguida, confirme as alterações para ver a sua construção executar dois trabalhos em duas plataformas e SDKs diferentes.

Personalize os gatilhos ci

Os gatilhos do gasoduto fazem com que o gasoduto corra. Pode utilizar-se trigger: para fazer funcionar um oleoduto sempre que empurrar uma atualização para um ramo. Os gasodutos YAML são configurados por padrão com um gatilho CI no seu ramo padrão (que normalmente mainé ). Pode configurar gatilhos para ramos específicos ou para validação de pedido de puxar. Para um gatilho de validação de pedido de puxar, basta substituir o trigger: passo com pr: os dois exemplos abaixo indicados. Por predefinição, o gasoduto funciona para cada alteração de pedido de puxar.

  • Se quiser configurar os gatilhos, adicione qualquer um dos seguintes cortes no início do seu azure-pipelines.yml ficheiro.

    trigger:
      - main
      - releases/*
    
    pr:
      - main
      - releases/*
    

    Pode especificar o nome completo do ramo (por exemplo, main) ou um wildcard que combina prefixo (por exemplo, releases/*).

Definições do pipeline

Existem algumas definições de pipeline que não gere no seu ficheiro YAML, como a trajetória de ficheiro YAML e o estado ativado do seu pipeline. Para configurar estas definições, navegue na página de detalhes do pipeline e escolha Mais ações, Definições. Para obter mais informações sobre a navegação e navegação dos seus oleodutos, consulte os gasodutos de navegação.

Regulação do gasoduto.

A partir do painel de definições do Pipeline , pode configurar as seguintes definições.

  • Processamento de novos pedidos de execução - Por vezes , vai querer evitar que novas corridas comecem no seu oleoduto.

    • Por predefinição, o processamento de novos pedidos de execução está ativado. Esta definição permite o processamento padrão de todos os tipos de gatilho, incluindo as execuções manuais.
    • Os gasodutos parados permitem processar os pedidos de execução, mas esses pedidos são em fila sem realmente começar. Quando o novo processamento de pedido está ativado, o processamento de execução retoma começando com o primeiro pedido na fila.
    • Os gasodutos desativado impedem que os utilizadores iniciem novas operações. Todos os gatilhos também são desativados enquanto esta definição é aplicada.
  • Caminho de ficheiro YAML - Se alguma vez precisar de direcionar o seu pipeline para utilizar um ficheiro YAML diferente, pode especificar o caminho para esse ficheiro. Esta definição também pode ser útil se precisar de mover/mudar o seu ficheiro YAML.

  • Ligue automaticamente os itens de trabalho incluídos nesta execução - As alterações associadas a uma determinada execução do gasoduto podem ter itens de trabalho associados a eles. Selecione esta opção para ligar os itens de trabalho à execução. Quando se selecionam automaticamente os itens de trabalho incluídos nesta execução , tem de especificar um ramo específico ou * para todos os ramos, que é o padrão. Se especificar um ramo, os itens de trabalho só estão associados a execuções desse ramo. Se especificar *, os itens de trabalho estão associados para todas as execuções.

    Ligue automaticamente os itens de trabalho incluídos nesta execução.

Criar artigo de trabalho na falha

Os oleodutos YAML não têm um item de trabalho criar na definição de falha como oleodutos clássicos de construção. Os gasodutos de construção clássica são de uma única fase, e criar um item de trabalho sobre falha aplica-se a todo o oleoduto. Os gasodutos YAML podem ser em várias fases e uma regulação do nível do gasoduto pode não ser adequada. Para implementar Criar um item de trabalho sobre falha num oleoduto YAML, pode utilizar métodos como os Itens de Trabalho - Crie a chamada DEAPI rest ou o produto de trabalho das placas Azure DevOps CLI cria comando no ponto desejado no seu oleoduto.

O exemplo a seguir tem dois empregos. O primeiro trabalho representa o trabalho do oleoduto, mas se falhar, o segundo emprego funciona, e cria um bug no mesmo projeto que o oleoduto.

# When manually running the pipeline, you can select whether it
# succeeds or fails.
parameters:
- name: succeed
  displayName: Succeed or fail
  type: boolean
  default: false

trigger:
- main

pool:
  vmImage: ubuntu-latest

jobs:
- job: Work
  steps:
  - script: echo Hello, world!
    displayName: 'Run a one-line script'

  # This malformed command causes the job to fail
  # Only run this command if the succeed variable is set to false
  - script: git clone malformed input
    condition: eq(${{ parameters.succeed }}, false)

# This job creates a work item, and only runs if the previous job failed
- job: ErrorHandler
  dependsOn: Work
  condition: failed()
  steps: 
  - bash: |
      az boards work-item create \
        --title "Build $(build.buildNumber) failed" \
        --type bug \
        --org $(System.TeamFoundationCollectionUri) \
        --project $(System.TeamProject)
    env: 
      AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
    displayName: 'Create work item on failure'

Nota

O Azure Boards permite-lhe configurar o rastreio do seu item de trabalho utilizando vários processos diferentes, tais como Agile ou Basic. Cada processo tem diferentes tipos de artigos de trabalho, e nem todos os tipos de produto de trabalho estão disponíveis em cada processo. Para obter uma lista de tipos de produto de trabalho suportados por cada processo, consulte os tipos de artigos de trabalho (WITs).

O exemplo anterior utiliza parâmetros de tempo de execução para configurar se o gasoduto tem sucesso ou falha. Ao executar manualmente o gasoduto, pode definir o valor do succeed parâmetro. O segundo script passo no primeiro trabalho do oleoduto avalia o succeed parâmetro e só funciona quando succeed é definido como falso.

O segundo emprego no oleoduto tem uma dependência do primeiro emprego e só funciona se o primeiro emprego falhar. O segundo trabalho utiliza o produto de trabalho Azure DevOps CLI az cria comando para criar um bug. Para obter mais informações sobre o funcionamento dos comandos CLI do Azure DevOps a partir de um oleoduto, consulte comandos Run num oleoduto YAML.

Este exemplo utiliza dois postos de trabalho, mas esta mesma abordagem poderia ser utilizada em várias fases.

Nota

Também pode utilizar uma extensão de mercado como a falha de desbloqueio do "Create Bug", que tem suporte para oleodutos yaml em várias fases.

Passos seguintes

Aprendeste o básico de personalizar o teu oleoduto. Em seguida, recomendamos que aprenda mais sobre a personalização de um oleoduto para o idioma que utiliza:

Ou, para aumentar o seu oleoduto ci para um oleoduto CI/CD, inclua um trabalho de implantação com passos para implementar a sua app num ambiente.

Para saber mais sobre os tópicos neste guia consulte Empregos, Tarefas, Catálogo de Tarefas, Variáveis, Gatilhos ou Resolução de Problemas.

Para saber o que mais pode fazer nos oleodutos YAML, consulte a referência de esquema YAML.