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.

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.

Clássico

Você pode organizar os trabalhos de implantação no pipeline de lançamento em fases. 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.

Uma fase em um pipeline de lançamento consiste em trabalhos e tarefas.

Aprovações e portões, condições de implantação e gatilhos e controle de políticas de enfileiramento quando uma versão é implantada em uma fase.

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 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.

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]

Clássico

Para adicionar uma fase ao pipeline de lançamento, selecione o pipeline de lançamento na página Versões, selecione a ação para Editá-lo e selecione a guia Pipeline. Embora a parte mais importante da definição de uma fase seja as tarefas de automação, você também pode configurar várias propriedades e opções para uma fase 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. Ser um proprietário de fase não vem automaticamente com nenhuma permissão.
• Exclua a fase do pipeline.
• Alterar a ordem das fases.
• Salve uma cópia da fase como um modelo de fase.
• Gerencie as configurações de segurança para a fase.

Especificar dependências

YAML

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

Clássico

Você controla as dependências definindo os gatilhos em cada fase do pipeline de lançamento:

• As fases são executadas com um gatilho ou sendo iniciadas manualmente.
• Com um gatilho After release, um estágio começa assim que o release começa, em paralelo com outros estágios que possuem gatilho After release.
• Com um gatilho Após fase, uma fase será iniciada após a conclusão de todas as fases 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 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.

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 os gatilhos Após a versão ou Após a fase, você também pode especificar os filtros de ramificação para os artefatos consumidos na versã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 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.

Clássico

Em alguns casos, você pode ser capaz de gerar as compilações de forma mais rápida do que eles podem ser implantados. Como alternativa, você pode configurar vários agentes e, por exemplo, criar versões do mesmo pipeline de lançamento para 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 essa opção se você provisionar dinamicamente novos recursos em sua fase e ela for fisicamente capaz de lidar com a implantação de várias versões em paralelo, mas você 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 quiser 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 nesse pipeline seja denominado QA e tenha 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 na fase de QA em paralelo. (se 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 eo 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 na fase de QA será iniciada. 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 for 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.

• Se você especificar um limite e Implantar mais recente e cancelar os outros , e o limite já tiver sido atingido, as versõesR2, R3 e R4serã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 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 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.

Clássico

Você pode adicionar aprovações manuais no início ou no final de cada fase do pipeline. Para obter mais informações, confira Visão geral de aprovações de versão e portões.