stages.definição de estágio

Os estágios são uma coleção de trabalhos relacionados. Por padrão, os estágios são executados sequencialmente. Cada estágio começa somente após a conclusão do estágio anterior, a menos que especificado de outra forma através da propriedade dependsOn.

stages:
- stage: string # Required as first property. ID of the stage.
  displayName: string # Human-readable name for the stage.
  pool: string | pool # Pool where jobs in this stage will run unless otherwise specified.
  dependsOn: string | [ string ] # Any stages which must complete before this one.
  condition: string # Evaluate this condition expression to determine whether to run this stage.
  variables: variables | [ variable ] # Stage-specific variables.
  jobs: [ job | deployment | template ] # Jobs which make up the stage.
  lockBehavior: sequential | runLatest # Behavior lock requests from this stage should exhibit in relation to other exclusive lock requests.
  trigger: manual | automatic # Stage trigger manual or automatic (default).
  isSkippable: boolean # Setting false prevents the stage from being skipped. By default it's always true.
  templateContext: # Stage related information passed from a pipeline when extending a template.

Definições que fazem referência a esta definição: fases

Propriedades

stage string. Obrigatório como primeira propriedade.
ID do palco.

displayName string.
Nome legível por humanos para o palco.

pool piscina.
Pool onde os trabalhos neste estágio serão executados, a menos que especificado de outra forma.

dependsOn corda | lista de cadeias de caracteres.
Quaisquer etapas que devam ser concluídas antes desta. Por padrão, os estágios são executados sequencialmente na ordem definida no pipeline. Especifique dependsOn: [] para um estágio se ele não deve depender do estágio anterior no pipeline.

condition string.
Avalie essa expressão de condição para determinar se esse estágio deve ser executado.

variables variáveis.
Variáveis específicas do estágio.

jobs empregos.
Jobs que compõem o palco.

lockBehavior string.
As solicitações de bloqueio de comportamento desta etapa devem ser exibidas em relação a outras solicitações de bloqueio exclusivas. sequencial | runMais recente.

trigger string.
Acionador de palco manual ou automático (padrão). manual | Automático.

isSkippable booleano.
A configuração false impede que o palco seja ignorado. Por padrão, é sempre verdade.

templateContext templateContext.
Informações relacionadas ao estágio passadas de um pipeline ao estender um modelo. Para obter mais informações sobre templateContext, consulte Modelos de pipelines YAML estendidos agora podem ser passados informações de contexto para estágios, trabalhos e implantações e Modelos - Use templateContext para passar propriedades para modelos.

Observações

Para obter mais informações sobre templateContext, consulte Modelos de pipelines YAML estendidos agora podem ser passados informações de contexto para estágios, trabalhos e implantações e Modelos - Use templateContext para passar propriedades para modelos.

Use verificações de aprovação para controlar manualmente quando um estágio deve ser executado. Essas verificações são comumente usadas para controlar implantações em ambientes de produção.

As verificações são um mecanismo disponível para o proprietário do recurso . Eles controlam quando um estágio em um pipeline consome um recurso. Como proprietário de um recurso como um ambiente, você pode definir verificações que são necessárias antes que um estágio que consome o recurso possa ser iniciado.

Atualmente, as verificações de aprovação manual são suportadas em ambientes . Para obter mais informações, consulte Aprovações.

Fechadura exclusiva

Nos pipelines YAML, as verificações são usadas para controlar a execução de etapas em recursos protegidos. Uma das verificações comuns que você pode usar é uma verificação de bloqueio exclusiva . Essa verificação permite que apenas uma única execução do pipeline prossiga. Quando várias execuções tentam implantar em um ambiente ao mesmo tempo, a verificação cancela todas as execuções antigas e permite que a execução mais recente seja implantada.

Você pode configurar o comportamento da verificação de bloqueio exclusiva usando a propriedade lockBehavior, que tem dois valores:

• runLatest - Somente a última execução adquire o bloqueio para o recurso. Este é o valor padrão se nenhum lockBehavior for especificado.
• sequential - Todas as execuções adquirem o bloqueio sequencialmente para o recurso protegido.

Cancelar execuções antigas é uma boa abordagem quando suas versões são cumulativas e contêm todas as alterações de código de execuções anteriores. No entanto, existem alguns pipelines nos quais as alterações de código não são cumulativas. Ao configurar a propriedade lockBehavior, você pode optar por permitir que todas as execuções prossigam e sejam implantadas sequencialmente em um ambiente ou preservar o comportamento anterior de cancelar execuções antigas e permitir apenas as mais recentes. Um valor de sequential implica que todas as execuções adquirem o bloqueio sequencialmente para o recurso protegido. Um valor de runLatest implica que apenas a última execução adquire o bloqueio para o recurso.

Para usar a verificação de bloqueio exclusiva com implantações sequential ou runLatest, siga estas etapas:

1. Habilite a verificação de bloqueio exclusiva no ambiente (ou outro recurso protegido).
2. No arquivo YAML para o pipeline, especifique uma nova propriedade chamada lockBehavior. Isso pode ser especificado para todo o pipeline ou para um determinado estágio:

Montado num palco:

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

Definido no pipeline:

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

Fechadura exclusiva ao nível do palco

Alguns casos de uso exigem um pipeline para acessar um recurso específico apenas uma vez em um determinado momento. Para apoiar este caso, temos a verificação de bloqueio exclusiva descrita na seção anterior..

Uma situação semelhante ocorre quando apenas uma corrida de gasoduto deve acessar um estágio a qualquer momento. Por exemplo, se você tiver um estágio que implanta em um grupo de recursos do Azure, convém impedir que várias execuções de pipeline atualizem simultaneamente o mesmo grupo de recursos. Atualmente, para conseguir isso, é necessário usar um recurso de proxy, como um ambiente, e colocar a verificação de bloqueio exclusiva nesse ambiente. Essa abordagem pode ser demorada, adicionar complexidade e aumentar os esforços de manutenção.

Se você precisar garantir que apenas uma única execução de pipeline por vez possa acessar um estágio, você pode especificar o bloqueio exclusivo no nível do estágio. Se você tiver um estágio com um ID e especificar sua propriedade lockBehavior, um bloqueio será criado automaticamente para esse estágio. O comportamento sequencial permanece consistente para bloqueios no nível do recurso e no nível do estágio. No entanto, o comportamento runLatest é diferente, pois apenas cancela runLatest compila para a mesma ramificação, não para todas as ramificações do pipeline.

Exemplos

Este exemplo executa três estágios, um após o outro. A fase intermédia executa dois trabalhos em paralelo.

stages:
- stage: Build
  jobs:
  - job: BuildJob
    steps:
    - script: echo Building!
- stage: Test
  jobs:
  - job: TestOnWindows
    steps:
    - script: echo Testing on Windows!
  - job: TestOnLinux
    steps:
    - script: echo Testing on Linux!
- stage: Deploy
  jobs:
  - job: Deploy
    steps:
    - script: echo Deploying the code!

Este exemplo executa dois estágios em paralelo. Por uma questão de brevidade, os trabalhos e etapas são omitidos.

stages:
- stage: BuildWin
  displayName: Build for Windows
- stage: BuildMac
  displayName: Build for Mac
  dependsOn: [] # by specifying an empty array, this stage doesn't depend on the stage before it

Ver também

Saiba mais sobre estágios, condiçõese variáveis.