Personalizar o fluxo de trabalho

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

Este artigo é um guia passo a passo sobre maneiras comuns de personalizar seu pipeline.

Pré-requisitos

Siga as instruções em Criar o seu primeiro pipeline para criar um pipeline funcional.

Compreender o azure-pipelines.yml ficheiro

Um pipeline é definido usando um arquivo YAML em seu repositório. Normalmente, esse arquivo é nomeado azure-pipelines.yml e está localizado na raiz do seu repo.

Vá para a página Pipelines no Azure Pipelines, selecione o pipeline que você criou e selecione Editar no menu de contexto do pipeline para abrir o editor YAML.

Examine o conteúdo do arquivo YAML.

 trigger:
 - main

 pool:
   vmImage: 'ubuntu-latest'

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

O pipeline é executado sempre que sua equipe envia uma alteração para a ramificação principal do repositório ou cria uma solicitação pull. Ele é executado em uma máquina Linux hospedada pela Microsoft. O processo de pipeline tem uma única etapa, que é executar a tarefa Maven.

Altere a plataforma para construir sobre

Você pode criar seu projeto em agentes hospedados pela Microsoft que já incluem SDKs e ferramentas para várias linguagens de desenvolvimento. Ou podes usar agentes autogeridos com ferramentas específicas de que precisas.

• Navegue até o editor do pipeline selecionando Editar pipeline na compilação ou selecionando Editar na página principal do pipeline.

• Atualmente, o pipeline é executado em um agente Linux:

  pool:
    vmImage: "ubuntu-latest"
  

• Para mudar para uma plataforma diferente, como Windows ou Mac, altere o vmImage valor:

  pool:
    vmImage: "windows-latest"
  

  pool:
    vmImage: "macos-latest"
  

• Selecione Salvar e confirme as alterações para ver seu pipeline executado em uma plataforma diferente.

Adicionar passos

Você pode adicionar mais scripts ou tarefas como etapas ao seu fluxo de trabalho. Uma tarefa é um script pré-empacotado. Você pode usar tarefas para criar, testar, publicar ou implantar seu aplicativo. Para Java, a tarefa Maven que usamos lida com resultados de teste e publicação, no entanto, você também pode usar uma tarefa para publicar resultados de cobertura de código.

• Abra o editor YAML para seu pipeline.

• Adicione o seguinte trecho ao final do arquivo YAML.

  - task: PublishCodeCoverageResults@2
    inputs:
      summaryFileLocation: "$(System.DefaultWorkingDirectory)/**/site/jacoco/jacoco.xml" # Path to summary files
      reportDirectory: "$(System.DefaultWorkingDirectory)/**/site/jacoco" # Path to report directory
      failIfCoverageEmpty: true # Fail if code coverage results are missing
  

• Selecione Salvar e confirme as alterações.

• Pode visualizar os resultados dos testes e da cobertura de código ao selecionar a sua build e aceder às abas Teste e Cobertura.

Desenvolva em várias plataformas

Você pode criar e testar seu projeto em várias plataformas. Uma maneira de fazer isso é com strategy e matrix. Você pode usar variáveis para colocar dados convenientemente em várias partes de um pipeline. Para este exemplo, usaremos uma variável para passar o 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 Salvar e confirme as alterações para ver sua compilação executar até três trabalhos em três plataformas diferentes.

Cada agente pode executar apenas um trabalho de cada vez. Para executar vários trabalhos em paralelo, você deve configurar vários agentes. Você também precisa de trabalhos paralelos suficientes.

Crie usando várias versões

Para criar um projeto usando diferentes versões desse idioma, pode usar um conjunto de versões e uma variável. Nesta etapa, você pode construir o projeto Java com duas versões diferentes do Java em uma única plataforma ou executar versões diferentes do Java em plataformas diferentes.

• Se desejar criar numa única plataforma e várias versões, adicione a seguinte matriz ao seu azure-pipelines.yml ficheiro antes da tarefa Maven e depois do 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 alterar a $(imageName) variável de volta para a plataforma de sua escolha.

• Se você quiser criar em várias plataformas e versões, substitua todo o conteúdo do arquivo azure-pipelines.yml antes da tarefa de publicação pelo seguinte trecho:

  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@4
    inputs:
      mavenPomFile: "pom.xml"
      mavenOptions: "-Xmx3072m"
      javaHomeOption: "JDKVersion"
      jdkVersionOption: $(jdkVersion)
      jdkArchitectureOption: "x64"
      publishJUnitResults: true
      testResultsFiles: "**/TEST-*.xml"
      goals: "package"
  

• Selecione Salvar e confirme as alterações para ver sua compilação executar dois trabalhos em duas plataformas e SDKs diferentes.

Personalizar gatilhos de CI

Os acionadores do pipeline fazem com que um pipeline seja executado. Você pode usar trigger: para fazer com que um pipeline seja executado sempre que enviar uma atualização para uma ramificação. Os pipelines YAML são configurados por padrão com um gatilho de CI na sua ramificação padrão (que geralmente é main). Você pode configurar gatilhos para ramificações específicas ou para validação de solicitação pull. Para um gatilho de validação de pull request, basta substituir a etapa trigger: por pr:, como mostrado nos dois exemplos abaixo. Por padrão, o pipeline é executado para cada alteração de solicitação pull.

• Se você quiser configurar gatilhos, adicione um dos seguintes trechos no início do azure-pipelines.yml arquivo.

  trigger:
    - main
    - releases/*
  

  pr:
    - main
    - releases/*
  

  Você pode especificar o nome completo da ramificação (por exemplo, main) ou um curinga de correspondência de prefixo (por exemplo, releases/*).

Definições do pipeline

Você pode exibir e definir as configurações do pipeline no menu Mais ações na página de detalhes do pipeline.

• Gerir a segurança - Gerir a segurança
• Renomear/mover - Edite o nome e o local da pasta do pipeline.
• Selo de status - Adicionar um selo de status ao seu repositório
• Excluir - Exclui o pipeline, incluindo todas as compilações e artefactos associados.
• Execuções Agendadas - Vista de Execuções Agendadas

Escolha Configurações para definir as seguintes configurações de pipeline.

No painel Configurações do pipeline , você pode definir as seguintes configurações.

• Processamento de novas solicitações de execução - Às vezes, você vai querer impedir que novas execuções comecem em seu pipeline.

  • Por padrão, o processamento de novas solicitações de execução é Habilitado. Essa configuração permite o processamento padrão de todos os tipos de gatilho, incluindo execuções manuais.
  • Os pipelines pausados permitem que as solicitações de execução sejam processadas, mas essas solicitações são enfileiradas sem realmente iniciar. Quando o processamento de novas solicitações estiver habilitado, o processamento de execução será retomado começando com a primeira solicitação na fila.
  • Os pipelines desativados impedem que os utilizadores iniciem novas execuções. Todos os gatilhos também são desativados enquanto essa configuração é aplicada. Todas as políticas de compilação que usam um pipeline desativado mostrarão a mensagem "Não é possível enfileirar compilação" ao lado da política de compilação na janela de visão geral de RP e o status da política de compilação será quebrado.

• Caminho do arquivo YAML - Se você precisar direcionar seu pipeline para usar um arquivo YAML diferente, poderá especificar o caminho para esse arquivo. Essa configuração também pode ser útil se você precisar mover/renomear seu arquivo YAML.

• Vincular automaticamente itens de trabalho incluídos nesta execução - As alterações associadas a uma determinada execução de pipeline podem ter itens de trabalho associados a eles. Selecione esta opção para vincular esses itens de trabalho ao processo. Quando a opção Vincular automaticamente os itens de trabalho incluídos nesta execução estiver selecionada, você deverá especificar uma ramificação específica ou * para todas as ramificações, que é o padrão. Se você especificar uma ramificação, os itens de trabalho serão associados apenas a execuções dessa ramificação. Se você especificar *, os itens de trabalho serão associados para todas as execuções.

  

  • Para receber notificações quando suas execuções falharem, veja como gerenciar notificações para uma equipe

Gerir a segurança

Você pode configurar a segurança de pipelines ao nível de projeto a partir das Mais ações na página inicial de pipelines e ao nível de pipeline na página de detalhes do pipeline.

Para dar suporte à segurança de suas operações de pipeline, você pode adicionar usuários a um grupo de segurança interno, definir permissões individuais para um usuário ou grupo ou adicionar usuários a funções predefinidas. Você pode gerenciar a segurança do Azure Pipelines no portal da Web, a partir do contexto de usuário ou administrador. Para obter mais informações sobre como configurar a segurança de pipelines, consulte Permissões de pipeline e funções de segurança.

Criar item de trabalho em caso de falha

# 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'

# 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: |
      curl \
        -X POST \
        -H 'Authorization: Basic $(System.AccessToken)' \
        -H 'Content-Type: application/json-patch+json' \
        -d '[
              {
                "op": "add",
                "path": "/fields/System.Title",
                "from": null,
                "value": "git clone failed"
              }
            ]' \
        "$(System.CollectionUri)$(System.TeamProject)/_apis//wit/workitems/$Bug?api-version=7.1-preview.3
"
    env:
        SYSTEM_ACCESSTOKEN: $(System.AccessToken)
    displayName: 'Create work item on failure'

Este exemplo usa dois trabalhos, mas essa mesma abordagem pode ser usada em vários estágios.

Próximos passos

Você aprendeu o básico para personalizar seu pipeline. Em seguida, recomendamos que você saiba mais sobre como personalizar um pipeline para o idioma usado:

• Núcleo do .NET
• Contentores
• Ir
• Java
• Node.js
• Píton

Ou, para expandir o seu pipeline de CI para um pipeline de CI/CD, inclua um trabalho de implantação com etapas para implantar a sua aplicação em um ambiente.

Para saber mais sobre os tópicos deste guia, consulte Trabalhos, Tarefas, Catálogo de tarefas, Variáveis, Gatilhos ou Solução de problemas.

Para saber o que mais pode ser feito em pipelines YAML, consulte a Referência do esquema YAML.