Adicionar estágios, dependências, & condições

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Observação

Em Microsoft Team Foundation Server (TFS) 2018 e versões anteriores, pipelines de build e versão são chamados de definições, execuções são chamadas de builds, conexões de serviço são chamadas de pontos de extremidade de serviço, estágios são chamados de ambientes e trabalhos são chamados de fases.

O conceito de fases varia dependendo se você usa pipelines do YAML ou pipelines de lançamento clássicos.

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 estágios em um grafo de dependência para que um estágio seja executado antes de outro. Há um limite de 256 trabalhos para uma fase.

Observação

O suporte para estágios foi adicionado no Azure DevOps Server 2019.1.

Esta versão do TFS não dá suporte ao YAML.

Clássico

Você pode organizar os trabalhos de implantação no pipeline de lançamento em fases. As etapas são as principais divisões no pipeline de lançamento: "executar testes funcionais", "implantar em pré-produção" e "implantar em produção" são bons exemplos de estágios de lançamento.

Um estágio 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 um estágio.

Especificar estágios

YAML

Observação

O suporte para estágios 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 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, use 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 nessa fase usarão esse pool, a menos que especificado de outra forma 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 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]

Esta versão do TFS não dá suporte a pipelines YAML.

Clássico

Para adicionar um estágio ao pipeline de lançamento, selecione o pipeline de lançamento na página Lançamentos , selecione a ação para editá-lo e, em seguida, selecione a guia Pipeline . Embora a parte mais importante da definição de um estágio seja as tarefas de automação, você também pode configurar várias propriedades e opções para um estágio em um pipeline de lançamento. Você pode:

• Edite o nome do estágio aqui, se necessário.
• Designe um usuário ou um grupo para ser o proprietário do estágio. Os proprietários de estágio são notificados sempre que uma implantação nesse estágio falha. Ser um proprietário de estágio 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 estágio como um modelo de estágio.
• Gerencie as configurações de segurança do estágio.

Especificar dependências

YAML

Observação

O suporte para estágios foi adicionado no Azure DevOps Server 2019.1.

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 a isso é 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

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

Exemplo 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

Esta versão do TFS não dá suporte a pipelines YAML.

Clássico

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

• Os estágios são executados com um gatilho ou sendo iniciados manualmente.
• Com um gatilho de versão Após , um estágio será iniciado assim que a versão for iniciada, em paralelo com outros estágios que têm o gatilho Após a liberação .
• Com um gatilho de estágio After , um estágio será iniciado 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.

Condições

Você pode especificar as condições sob as quais cada estágio é executado. Por padrão, um estágio será executado se ele não depender de nenhum outro estágio ou se todos os estágios dos quais depende tiverem sido concluídos e tiverem êxito. 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, remova as condições de conclusão e êxito. Portanto, se você usar uma condição personalizada, é comum usar and(succeeded(),custom_condition) para verificar se o estágio anterior foi executado com êxito. Caso contrário, o estágio será executado 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

Observação

O suporte para estágios foi adicionado no Azure DevOps Server 2019.1.

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 uso de uma condição personalizada:

stages:
- stage: A

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

Esta versão do TFS não dá suporte a pipelines YAML.

Clássico

Ao especificar após a versão ou após os gatilhos de estágio , 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 um estágio quando os filtros de branch 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, suas duas confirmações sucessivas podem disparar dois pipelines, e ambos executarão a mesma sequência de estágios 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 se isso for importante.

Esta versão do TFS não dá suporte a pipelines YAML.

Clássico

Em alguns casos, você pode gerar builds mais rápido 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 um estágio. 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 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 na sequência: use essa opção se quiser implantar todas as versões sequencialmente nos mesmos recursos físicos compartilhados. Ao implantá-los, por sua vez, um após o outro, você garante que dois trabalhos de implantação não direcionem os mesmos recursos físicos simultaneamente, mesmo que haja vários agentes de build e lançamento 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 essa opção se você estiver produzindo versões mais rápidas do que as compilações e só quiser implantar 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 neste pipeline seja chamado de QA e tenha 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 concederem aprovação para todas as versões, todos eles serão implantados na fase de QA em paralelo. (se o estágio de QA não tiver nenhum aprovador de pré-implantação definido, todas as cinco versões serão implantadas automaticamente em paralelo a esse 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. Depois que essa aprovação for concluída, a implantação da versão R1 no estágio 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 é 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, por sua vez.

• Se você especificar um limite e implantar o 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 QA 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 um estágio deve ser executado usando verificações de aprovação. Isso geralmente é usado para controlar implantações em ambientes de produção. 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 atendidas antes que um estágio que consuma esse recurso possa começar.

Atualmente, há suporte para verificações de aprovação manuais em ambientes. Para obter mais informações, consulte Aprovações.

Ainda não há suporte para aprovações em pipelines YAML nesta versão do Azure DevOps Server.

Esta versão do TFS não dá suporte a pipelines YAML.

Clássico

Você pode adicionar aprovações manuais no início ou no final de cada estágio do pipeline. Para obter mais informações, consulte a visão geral de aprovações de lançamento e portões.