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.

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.

Clássico

Você pode organizar os trabalhos de implantação no pipeline de lançamento em fases. As fases são as principais divisões no fluxo de lançamento. Exemplos incluem a execução de testes funcionais, a implantação na pré-produção e a implantação em produção.

Um estágio em um pipeline de lançamento consiste em trabalhos e tarefas.

Aprovações e portões, condições de implantação e gatilhos, e políticas de enfileiramento controlam quando uma versão é implantada em um estágio.

Especificar fases

YAML

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

Clássico

Para adicionar um estágio ao pipeline de lançamento, selecione o pipeline de lançamento na página Versões , selecione Editar e, em seguida, selecione a guia Pipeline . Embora a parte mais importante da definição de um estágio seja as tarefas de automação, você também pode configurar várias propriedades e opções para um estágio em um pipeline de lançamento. Você pode:

• Edite o nome da fase aqui, se necessário.
• Designe um usuário ou um grupo para ser o proprietário da fase. Os proprietários da fase são notificados sempre que uma implantação nessa fase falha. A propriedade do estágio não inclui automaticamente permissões.
• Exclua a fase do pipeline.
• Alterar a ordem das fases.
• Salve uma cópia da etapa como um modelo de etapa.
• Gerencie as configurações de segurança para a fase.

Especificar dependências

YAML

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

Clássico

Gerenciar dependências configurando gatilhos em cada estágio do pipeline de lançamento.

• Os estágios são executados com um gatilho ou são iniciados manualmente.
• Com um gatilho após o lançamento, um estágio é iniciado assim que o lançamento começa, executando em paralelo com outros estágios que têm o mesmo gatilho.
• Com um gatilho Após o estágio, um estágio é iniciado após a conclusão de todos os estágios dependentes. Usando isso, você pode modelar o comportamento de fan-out e fan-in para fases.

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.

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

Clássico

Ao especificar após a liberação ou após o estágio de gatilhos, você também pode especificar os filtros de ramificação para os artefatos consumidos na liberação. As versões serão implantadas apenas em uma fase quando os filtros de ramificação forem atendidos.

Especificar políticas de enfileiramento

YAML

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.

Clássico

Em alguns casos, você pode conseguir gerar compilações mais rapidamente do que elas podem ser implantadas. Como alternativa, você pode configurar vários agentes e, por exemplo, gerar releases do mesmo pipeline de lançamento para a implantação de artefatos diferentes. Nesses casos, é útil poder controlar como várias versões são enfileiradas em uma fase. As políticas de enfileiramento oferecem esse controle.

As opções que você pode escolher para uma política de enfileiramento são:

• Número de implantações paralelas: use esta opção se você provisiona dinamicamente novos recursos em seu estágio e ele for capaz, fisicamente, de lidar com a implantação de múltiplos lançamentos em paralelo, mas quiser limitar o número de implantações paralelas.

• Se você especificar um número máximo de implantações, mais duas opções serão exibidas:

  • Implantar tudo em sequência: use essa opção se desejar implantar todas as versões sequencialmente nos mesmos recursos físicos compartilhados. Ao implantar as compilações em turnos, uma após a outra, você garante que dois trabalhos de implantação não se destinem aos mesmos recursos físicos simultaneamente, mesmo que haja vários agentes de build e versão disponíveis. Você também garante que as solicitações de aprovação de pré-implantação para o estágio sejam enviadas em sequência.

  • Implante as versões mais recentes e cancele as outras: use esta opção se você estiver produzindo builds mais rápido do que as versões e quiser implantar apenas o build mais recente.

Para entender como essas opções funcionam, considere um cenário em que as versões R1, R2, ..., R5 de um único pipeline de lançamento são criadas em rápida sucessão. Suponha que o primeiro estágio neste pipeline seja denominado QA e tenha aprovadores de pré-implantação e pós-implantação definidos.

• Se você não especificar um limite para o número de implantações paralelas, todas as cinco solicitações de aprovação serão enviadas assim que as versões forem criadas. Se os aprovadores aprovarem todas as versões, todas serão implantadas na fase QA em paralelo. (se o estágio de QA não tiver nenhum aprovador de pré-implantação definido, todas as cinco versões serão implantadas automaticamente em paralelo a esse estágio).

• Se você especificar um limite e implantar tudo em sequência e o limite já tiver sido atingido, a aprovação de pré-implantação para a versão R1 será enviada primeiro. Depois que essa aprovação for concluída, a implantação da versão R1 para o estágio de QA será iniciada. Em seguida, uma solicitação de aprovação pós-implantação é enviada para a liberação R1. É somente depois que essa aprovação pós-implantação é concluída que a execução da versão R2 começa e sua aprovação de pré-implantação é enviada. O processo continua assim para todas as versões por sua vez.

• Se você especificar um limite e implantar o mais recente e cancelar os outros, e o limite já tiver sido atingido, as versões R2, R3 e R4 serão ignoradas e a aprovação de pré-implantação para R5 no estágio de QA será enviada imediatamente após a aprovação pós-implantação para a versão R1 ser concluída.

Especificar aprovações

YAML

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.

Clássico

Você pode adicionar aprovações manuais no início ou no final de cada fase do pipeline. Para obter mais informações, consulte a visão geral de aprovações de lançamento e barreiras.

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.