Adicionar fases, dependências e condições

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

Um estágio é um limite lógico em um pipeline do Azure DevOps. Os estágios podem ser usados para agrupar ações em seu processo de desenvolvimento de software (por exemplo, criar o aplicativo, executar testes, implantar na pré-produção). Cada etapa contém um ou mais trabalhos.

Quando você define vários estágios em um pipeline, por padrão, eles são executados um após o outro. As etapas também podem depender umas das outras. Você pode usar a dependsOn palavra-chave para definir dependências. As etapas também podem ser executadas com base no resultado de uma etapa 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 trabalhos, consulte Principais conceitos de pipelines.

Você também pode saber mais sobre como os estágios se relacionam com partes de um pipeline no artigo Estágios do esquema YAML.

YAML

Pode organizar os trabalhos de pipeline em fases. Os estágios são as principais divisões em um pipeline: construir este aplicativo, executar esses testes e implantar na pré-produção são bons exemplos de estágios. Eles são limites lógicos em seu pipeline, onde você 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 estágios em um gráfico de dependência para que um estágio seja executado antes de outro. Há um limite de 256 vagas por etapa.

Clássico

Organize os trabalhos de implantação em seu pipeline de liberação em estágios. Os estágios são as principais divisões em seu pipeline de lançamento: executar testes funcionais, implantar na pré-produção e implantar na produção são bons exemplos de estágios de lançamento.

Um estágio em um pipeline de liberação consiste em trabalhos e tarefas.

Aprovações e portas, condições e gatilhos de implantação 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. Nesse caso, você não precisa usar explicitamente a stage palavra-chave. Você pode especificar diretamente os trabalhos em seu arquivo YAML.

# this has one implicit stage and one implicit job
pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

# this pipeline has one implicit stage
jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Se você organizar seu pipeline em vários estágios, usará a stages palavra-chave.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Se você optar por especificar um pool no nível do estágio, todos os trabalhos definidos nesse estágio usarão esse pool, a menos que especificado 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

A sintaxe completa para especificar um estágio é:

stages:
- stage: string  # name of the stage, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  pool: string | pool
  variables: { string: string } | [ variable | variableReference ] 
  jobs: [ job | templateReference]

Clássico

Para adicionar um estágio ao seu pipeline de liberação, selecione o pipeline de liberação na página Releases , selecione a ação a ser editada e selecione a guia Pipeline . Embora a parte mais importante da definição de um estágio sejam as tarefas de automação, você também pode configurar várias propriedades e opções para um estágio em um pipeline de versão. Pode:

• Edite o nome do palco aqui, se necessário.
• Designe um usuário ou um grupo para ser o proprietário do palco. Os proprietários de estágio são notificados sempre que uma implantação nesse estágio falha. Ser proprietário de um palco não vem automaticamente com nenhuma permissão.
• Exclua o estágio do pipeline.
• Altere a ordem dos estágios.
• Salve uma cópia do palco como um modelo de palco.
• Gerencie as configurações de segurança para o palco.

Especificar dependências

YAML

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

Os pipelines devem conter pelo menos um estágio sem dependências.

A sintaxe para definir vários estágios e suas dependências é:

stages:
- stage: string
  dependsOn: string
  condition: string

Exemplos de estágios que são executados sequencialmente:

# if you do not use a dependsOn keyword, stages run in the order they are defined
stages:
- stage: QA
  jobs:
  - job:
    ...

- stage: Prod
  jobs:
  - job:
    ...

Exemplos de estágios que são executados em paralelo:

stages:
- stage: FunctionalTest
  jobs:
  - job:
    ...

- stage: AcceptanceTest
  dependsOn: []    # this removes the implicit dependency on previous stage and causes this to run in parallel
  jobs:
  - job:
    ...

Exemplo de fan-out e fan-in:

stages:
- stage: Test

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

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

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

Clássico

Você controla as dependências definindo os gatilhos em cada estágio do pipeline de liberação:

• Os estágios são executados com um gatilho ou sendo iniciados manualmente.
• Com um gatilho After release , um estágio começa assim que o release começa, em paralelo com outros estágios que têm After release trigger.
• Com um gatilho de estágio After, um estágio começará depois que todos os estágios dependentes forem concluídos. Usando isso, você pode modelar o comportamento de fan-out e fan-in para estágios.

Definir condições

Você pode especificar as condições sob as quais cada estágio é executado com expressões. Por padrão, um estágio é executado se não depender de nenhum outro estágio ou se todos os estágios dos quais ele depende tiverem sido concluídos e bem-sucedidos. Você pode personalizar esse comportamento forçando um estágio a ser executado mesmo se um estágio anterior falhar ou especificando uma condição personalizada.

Se você personalizar a condição padrão das etapas anteriores para um estágio, removerá as condições de conclusão e sucesso. Portanto, se você usar uma condição personalizada, é comum usá-la and(succeeded(),custom_condition) para verificar se o estágio anterior foi executado com êxito. Caso contrário, a etapa é executada independentemente do resultado da etapa anterior.

Nota

As condições para falha ('JOBNAME/STAGENAME') e bem-sucedida ('JOBNAME/STAGENAME'), conforme mostrado no exemplo a seguir, funcionam apenas para pipelines YAML.

YAML

Exemplo para executar um estágio com base no status de execução de 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 utilização de uma condição personalizada:

stages:
- stage: A

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

Clássico

Ao especificar os gatilhos Após a liberação ou Após o estágio , você também pode especificar os filtros de ramificação para os artefatos consumidos na versão. As versões só serão implantadas em um estágio quando os filtros de ramificação estiverem satisfeitos.

Especificar políticas de enfileiramento

YAML

Os pipelines YAML não suportam políticas de enfileiramento. Cada execução de um pipeline é independente e desconhece outras execuções. Em outras palavras, suas duas confirmações sucessivas podem acionar dois pipelines, e ambos executarão a mesma sequência de estágios sem esperar um pelo outro. Enquanto trabalhamos para trazer políticas de enfileiramento para pipelines YAML, recomendamos que você use aprovações manuais para sequenciar e controlar manualmente a ordem de execução, se isso for importante.

Clássico

Em alguns casos, você poderá gerar compilações mais rapidamente do que elas podem ser implantadas. Como alternativa, você pode configurar vários agentes e, por exemplo, criar versões do mesmo pipeline de liberação para implantação de artefatos diferentes. Nesses casos, é útil poder controlar como várias versões são enfileiradas em um estágio. As políticas de fila dão esse controle.

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

• Número de implantações paralelas: use esta opção se provisionar dinamicamente novos recursos em seu estágio e ele for fisicamente capaz de lidar com a implantação de várias versões 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 esta opção se quiser implantar todas as versões sequencialmente nos mesmos recursos físicos compartilhados. Ao implantar as compilações por sua vez, uma após a outra, você garante que dois trabalhos de implantação não direcionem os mesmos recursos físicos simultaneamente, mesmo que haja vários agentes de compilação e liberaçã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.

  • Implantar as versões mais recentes e cancelar as outras: use esta opção se estiver produzindo compilações mais rapidamente do que as versões e quiser implantar apenas a compilação 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 liberação sejam criadas em rápida sucessão. Suponha que o primeiro estágio neste pipeline é chamado de QA e tem aprovadores de pré 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 elas serão implantadas no estágio de QA em paralelo. (se a seringa O estágio de QA não teve nenhum aprovador de pré-implantação definido, todas as cinco versões serão implantadas automaticamente em paralelo a este 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. Após essa aprovação ser concluída, a implantação da versão R1 para o estágio de QA começa. Em seguida, uma solicitação de aprovação pós-implantação é enviada para a versã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 todos os lançamentos por sua vez.

• Se você especificar um limite e Implantar 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 controle de qualidade será enviada imediatamente após a conclusão da aprovação pós-implantação para a versão R1.

Especificar aprovações

YAML

Você pode controlar manualmente quando um estágio deve ser executado usando verificações de aprovação. Isso é comumente 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 verificações que devem ser satisfeitas antes que um estágio que consuma esse recurso possa ser iniciado.

Atualmente, as verificações manuais de aprovação são suportadas 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 estágio no pipeline. Para obter mais informações, consulte Visão geral de aprovações de liberação e portões.

Adicionar um gatilho manual

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

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

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

No exemplo a seguir, o estágio de desenvolvimento é executado automaticamente, enquanto o estágio de produção requer acionamento 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 palco como imperdível

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

No exemplo a seguir, o estágio de deteção de malware é marcado como não pulável, o que significa que 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 pode ser ignorado, ele será exibido com uma caixa de seleção desabilitada no painel Estágios para executar a configuração.