definição stages.stage

Estágios são uma coleção de trabalhos relacionados. Por padrão, os estágios são executados sequencialmente. Cada estágio é iniciado somente após a conclusão do estágio anterior, a menos que seja especificado de outra forma por meio 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 essa definição: estágios

Propriedades

stage cadeia de caracteres. Obrigatório como primeira propriedade.
ID do palco.

displayName cadeia de caracteres.
nome legível para o palco.

pool pool.
Pool em que os trabalhos nesta fase serão executados, a menos que especificado de outra forma.

dependsOn cadeia de caracteres | lista de cadeias de caracteres.
Todos os estágios que devem ser concluídos antes deste. 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 cadeia de caracteres.
Avaliar essa expressão de condição para determinar se esse estágio deve ser executado.

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

trabalhos jobs.
Trabalhos que compõem o palco.

lockBehavior cadeia de caracteres.
Solicitações de bloqueio de comportamento desse estágio devem ser exibidas em relação a outras solicitações de bloqueio exclusivas. sequencial | runLatest.

trigger cadeia de caracteres.
manual do gatilho de estágio ou automático (padrão). manual | Automático.

isSkippable booliano.
A configuração de false impede que o estágio 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 de – 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 de – 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 geralmente são 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 necessárias antes que um estágio que consome o recurso possa ser iniciado.

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

Bloqueio exclusivo

Em pipelines YAML, as verificações são usadas para controlar a execução de estágios 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 execução mais recente adquire o bloqueio para o recurso. Esse será o valor padrão se nenhuma lockBehavior for especificada.
• sequential – todas as execuções adquirem o bloqueio sequencialmente ao 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 das execuções anteriores. No entanto, há 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 implantem sequencialmente em um ambiente ou preservar o comportamento anterior de cancelar execuções antigas e permitir apenas o mais recente. Um valor de sequential implica que todas as execuções adquirem o bloqueio sequencialmente ao recurso protegido. Um valor de runLatest implica que apenas a execução mais recente adquire o bloqueio para o recurso.

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

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

Defina em um palco:

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

Definir no pipeline:

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

Bloqueio exclusivo no nível do estágio

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

Uma situação semelhante ocorre quando apenas uma execução de pipeline deve acessar um estágio a qualquer momento. Por exemplo, se você tiver um estágio implantado 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, isso requer o uso de um recurso de proxy, como um ambiente, e 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ê poderá especificar o bloqueio exclusivo no nível do estágio. Se você tiver um estágio com uma 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 do runLatest é diferente, pois cancela apenas runLatest builds para o mesmo branch, não para todos os branches do pipeline.

Exemplos

Este exemplo executa três estágios, um após o outro. O estágio do meio 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. Para fins de brevidade, os trabalhos e as 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

Consulte também

Saiba mais sobre de estágios de, de condições dee variáveis de .