Adicionar estágios, 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. Estágios de ações de grupo em seu processo de desenvolvimento de software, como criar o aplicativo, executar testes e 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 tarefas, 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. Existem limites lógicos no seu pipeline, onde é possível pausá-lo e realizar 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. Uma etapa pode ter até 256 postos de trabalho.

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 na sua cadeia de lançamento. Os exemplos incluem a execução de testes funcionais, a implantação na pré-produção e a implantação na produção.

Um estágio num pipeline de distribuição consiste em jobs 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. 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 cria e testa um aplicativo pequeno sem exigir ambientes ou etapas de implantação separados, 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"

Este 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 o pipeline em vários estágios, use o stages comando. Este YAML define um pipeline com dois estágios, onde cada estágio contém vários trabalhos e cada trabalho tem etapas específicas para executar.

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 do estágio, todos os trabalhos nesse estágio usarão esse pool, a menos que o estágio seja 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

Clássico

Para adicionar uma etapa ao seu pipeline de versão, selecione o pipeline na página de Releases, selecione Editar e, em seguida, selecione a guia Pipeline. Embora a parte mais importante da definição de uma etapa sejam as tarefas de automação, também pode configurar várias propriedades e opções para uma etapa 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 da etapa são notificados sempre que uma implantação nessa etapa falha. A propriedade do palco não inclui automaticamente permissões.
• 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, eles são executados sequencialmente por padrão 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.

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 sã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"

Exemplos de estágios que são executados 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

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

• Os estágios podem ser executados com um gatilho ou iniciados manualmente.
• Com um disparador After release, um estágio começa assim que o lançamento se inicia, funcionando em paralelo com outros estágios que têm o mesmo disparador.
• Com um gatilho Após Etapa, uma etapa começa 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 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 utilizar uma condição personalizada, é comum usar 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 para sucesso ('JOBNAME/STAGENAME'), conforme demonstrado no exemplo seguinte, funcionam apenas para pipelines YAML.

YAML

Exemplo para executar um estágio com base no resultado da 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 definir os gatilhos Após a publicação ou Após a fase, você também pode definir os filtros de ramificação para os artefatos consumidos no lançamento. As liberações só serão implementadas para um estágio quando os filtros de ramificação estiverem satisfeitos.

Especificar políticas de enfileiramento

YAML

Os YAML pipelines não suportam políticas de enfileiramento. Cada execução de um pipeline é independente e não tem conhecimento das 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 estamos a trabalhar para introduzir políticas de enfileiramento em pipelines YAML, recomendamos que utilize 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 numa fase. As políticas de gestão de filas dão-lhe esse controlo.

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 na sua fase e ela for fisicamente capaz 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 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 os pedidos de aprovação antes da implementação para a etapa sejam enviados 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 QA e tem 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 elas serão implantadas no estágio de QA em paralelo. (se o estágio de QA não tivesse nenhum aprovador de pré-implantação definido, todas as cinco versões seriam 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, é enviada uma solicitação de aprovação pós-implementação para a versão R1. É somente depois que essa aprovação pós-implementação é concluída que a execução da versão R2 começa, e sua aprovação de pré-implementação é enviada. O processo continua assim para todas as versões à vez.

• Se especificares um limite e Implantar a versão mais recente e cancelar as outras, e o limite já tiver sido atingido, as versões R2, R3 e R4 serão ignoradas, e a pré-aprovação para R5 na fase de QA será enviada imediatamente após a conclusão da pós-aprovaçã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 ao proprietário do recurso para controlar se e quando um estágio pode consumir um recurso num pipeline. 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.

Neste momento, as verificações manuais de aprovação são implementadas 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, o seu pipeline pode incluir estágios para construção, teste, implantação em um ambiente de teste 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 este 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 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 uma etapa como não pode ser saltada

Marque um estágio como isSkippable: false para evitar que os utilizadores do pipeline saltem 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 definir isSkippable: false para este estágio, o seu pipeline não conseguirá esquivar-se da 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 é exibido com uma caixa de seleção desabilitada no painel de configuração Estágios para executar .