Compartilhar via


Adicionar estágios, dependências e condições

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Um estágio é um limite lógico em um pipeline de Azure DevOps. Agrupar ações em fases no seu processo de desenvolvimento de software, como criar o aplicativo, executar testes e implantar na preprodução. Cada fase contém um ou mais trabalhos.

Quando você define várias fases em um pipeline, por padrão, elas são executadas uma após a outra. Os estágios também podem depender uns dos outros. Você pode usar a dependsOn palavra-chave para definir dependências. Os estágios também podem ser executados com base no resultado de um estágio anterior com condições.

Para saber como os estágios funcionam com trabalhos paralelos e licenciamento, consulte Configurar e pagar por trabalhos paralelos.

Para descobrir como os estágios se relacionam com outras partes de um pipeline, como tarefas, consulte os principais conceitos de pipelines.

Você também pode aprender mais sobre a relação dos estágios com as partes de um pipeline no artigo sobre os estágios do esquema YAML.

Você pode organizar os trabalhos do pipeline em fases. As fases são as principais divisões em um pipeline: "criar este aplicativo", "executar esses testes" e "implantar na pré-produção" são bons exemplos de fases. São limites lógicos no pipeline em que se pode pausar o pipeline e executar várias verificações.

Cada pipeline tem pelo menos um estágio, mesmo que você não o defina explicitamente. Você também pode organizar fases em um grafo de dependência para que uma fase seja executada antes de outra. Um estágio pode ter até 256 tarefas.

Especificar fases

No caso mais simples, você não precisa de limites lógicos em seu pipeline. Para esses cenários, você pode especificar diretamente os trabalhos em seu arquivo YAML sem a stages palavra-chave. Por exemplo, se você tiver um pipeline simples que compila e testa um aplicativo pequeno sem exigir ambientes separados ou etapas de implantação, poderá definir todos os trabalhos diretamente sem usar estágios.

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

Esse pipeline tem um estágio implícito e duas tarefas. A stages palavra-chave não é usada porque há apenas um estágio.

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

Para organizar seu pipeline em vários estágios, use a palavra-chave stages. Esse YAML define um pipeline com dois estágios em que cada estágio contém vários trabalhos e cada trabalho tem etapas específicas a serem executadas.

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

Se você especificar um pool no nível de etapa, todos os trabalhos nessa fase usarão esse pool, a não ser que a etapa seja especificada no nível do trabalho.

stages:
- stage: A
  pool: StageAPool
  jobs:
  - job: A1 # will run on "StageAPool" pool based on the pool defined on the stage
  - job: A2 # will run on "JobPool" pool
    pool: JobPool

Especificar dependências

Quando você define vários estágios em um pipeline, eles são executados sequencialmente por padrão na ordem em que você os define no arquivo YAML. A exceção a isso é quando você adiciona dependências. Com dependências, as fases são executadas na ordem dos requisitos dependsOn.

Os pipelines devem conter pelo menos uma fase sem dependências.

Para obter mais informações sobre como definir estágios, consulte estágios no esquema YAML.

Os estágios de exemplo a seguir são executados sequencialmente. Se você não usar uma dependsOn palavra-chave, os estágios serão executados na ordem em que estão definidos.

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

Fases de exemplo que são executadas em paralelo:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

Exemplo de comportamento de fan-out e fan-in:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    #  stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Definir condições

Você pode especificar as condições sob as quais cada estágio é executado com expressões. Por padrão, uma fase será executada se não depender de nenhuma outra fase, ou se todas as fases das quais depende forem concluídas sem erros. Você pode personalizar esse comportamento ao especificar uma condição personalizada ou ao forçar a execução de uma fase, mesmo que uma fase anterior falhe.

Se você personalizar a condição padrão das etapas anteriores para uma fase, remova as condições de conclusão e êxito. Portanto, se você usar uma condição personalizada, é comum usar and(succeeded(),custom_condition) para marcar se a fase anterior foi executada com êxito. Caso contrário, a fase será executada independentemente do resultado da fase anterior.

Observação

As condições para falha ('JOBNAME/STAGENAME') e sucesso ('JOBNAME/STAGENAME'), conforme o exemplo abaixo, funcionam apenas para pipelines YAML.

Exemplo para executar uma fase com base no status de executar um estágio anterior:

stages:
- stage: A

# stage B runs if A fails
- stage: B
  condition: failed()

# stage C runs if B succeeds
- stage: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')

Exemplo de uso de uma condição personalizada:

stages:
- stage: A

- stage: B
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))

Especificar políticas de enfileiramento

Pipelines YAML não dão suporte a políticas de enfileiramento. Cada execução de um pipeline é independente e desconhece outras execuções. Em outras palavras, seus dois commits sucessivos podem disparar dois pipelines, e ambos executarão a mesma sequência de etapas sem esperar um pelo outro. Embora trabalhemos para trazer políticas de enfileiramento para pipelines YAML, recomendamos que você use aprovações manuais para sequenciar manualmente e controlar a ordem de execução, caso isso seja importante.

Especificar aprovações

Você pode controlar manualmente quando uma fase deve ser executada usando verificações de aprovação. Isso geralmente é usado para controlar implantações em ambientes de produção. As verificações são um mecanismo disponível para o proprietário do recurso controlar se e quando um estágio em um pipeline pode consumir um recurso. Como proprietário de um recurso, como um ambiente, você pode definir as verificações que devem ser satisfeitas antes que uma fase que consome o recurso possa começar.

Atualmente, há suporte para verificações manuais de aprovação em ambientes. Para obter mais informações, consulte Aprovações.

Adicionar um gatilho manual

Os estágios de pipeline YAML disparados manualmente permitem que você tenha um pipeline unificado sem executá-lo sempre até a conclusão.

Por exemplo, seu pipeline pode incluir estágios de compilação, teste, implantação em um ambiente de preparo e implantação para produção. Talvez você queira que todos os estágios sejam executados automaticamente, exceto a implantação de produção, que você prefere disparar manualmente quando estiver pronta.

Para usar esse recurso, adicione a propriedade trigger: manual a um estágio.

No exemplo a seguir, o estágio de desenvolvimento é executado automaticamente, enquanto o estágio de produção requer disparo manual. Ambos os estágios executam um script de saída Hello World.

stages:
- stage: Development
  displayName: Deploy to development
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'
- stage: Production
  displayName: Deploy to production
  trigger: manual
  jobs:
  - job: DeployJob
    steps:
    - script: echo 'hello, world'
      displayName: 'Run script'

Marcar um estágio como impossível de pular

Marque um estágio como isSkippable: false para impedir que os usuários do pipeline ignorem estágios. Por exemplo, você pode ter um modelo YAML que injeta um estágio que executa a detecção de malware em todos os pipelines. Se você definir isSkippable: false para esse estágio, o pipeline não poderá ignorar a detecção de malware.

No exemplo a seguir, o estágio de detecção de malware é marcado como não confiável, o que significa que ele deve ser executado como parte da execução do pipeline.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

Quando um estágio é não-pulável, ele é exibido com uma caixa de seleção desabilitada no painel de configuração Etapas a executar.

Captura de tela dos estágios a serem executados com o estágio desabilitado.