Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.