Adicionar fases, 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. Os estágios podem ser usados para agrupar ações em seu processo de desenvolvimento de software (por exemplo, compilar o aplicativo, executar testes, implantar na pré-produçã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 palavra-chave dependsOn 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 as fases funcionam com trabalhos paralelos e licenciamento, confira Configurar e pagar por trabalhos paralelos.
Para descobrir como as fases se relacionam com outras partes de um pipeline, como trabalhos, confira Principais conceitos de pipelines.
Você também pode saber mais sobre como as fases se relacionam com partes de um pipeline no artigo fases 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 uma fase, 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. Há um limite de 256 vagas por estágio.
Observação
O suporte para fases foi adicionado no Azure DevOps Server 2019.1.
Especificar fases
Observação
O suporte para fases foi adicionado no Azure DevOps Server 2019.1.
No caso mais simples, você não precisa de limites lógicos em seu pipeline. Nesse caso, você não precisa usar explicitamente a palavra-chave stage. Você pode especificar diretamente os trabalhos no 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 o pipeline em vários estágios, use a palavra-chave stages.
stages:
- stage: A
jobs:
- job: A1
- job: A2
- stage: B
jobs:
- job: B1
- job: B2
Se você optar por especificar um no nível do pool estágio, todos os trabalhos definidos nesse estágio usarão esse pool, a menos que especificado no nível do trabalho.
Observação
No Azure DevOps Server 2019, os pools só podem ser especificados 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 uma fase é:
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]
Especificar dependências
Observação
O suporte para fases foi adicionado no Azure DevOps Server 2019.1.
Quando você define várias fases em um pipeline, por padrão, elas são executadas sequencialmente na ordem em que você as 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.
A sintaxe para definir várias fases e suas dependências é:
stages:
- stage: string
dependsOn: string
condition: string
Fases de exemplo que são executadas 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:
...
Fases de exemplo que são executadas 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
Definir condições
Você pode especificar as condições sob as quais cada fase é executada 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 êxito ('JOBNAME/STAGENAME') conforme mostrado no exemplo a seguir funcionam apenas para pipelines YAML.
Observação
O suporte para fases foi adicionado no Azure DevOps Server 2019.1.
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 fases 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 da execução se isso for 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 uma fase 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, confira Aprovações.
Ainda não há suporte para aprovações em pipelines YAML nesta versão do Azure DevOps Server.
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 pulável, o que significa que ele deve ser executado como parte da execução de pipeline.
- stage: malware_detection
displayName: Malware detection
isSkippable: false
jobs:
- job: check_job
...
Quando um estágio não puder ser pulado, ele será exibido com uma caixa de seleção desmarcada no painel de configuração Estágios a serem executados.
