Compartir a través de


stages.stage definition

Las fases son una colección de trabajos relacionados. De forma predeterminada, las fases se ejecutan secuencialmente. Cada fase se inicia solo después de que se complete la fase anterior a menos que se especifique lo contrario a través de la propiedad 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.
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.
  templateContext: # Stage related information passed from a pipeline when extending a template.
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.

Definiciones que hacen referencia a esta definición: fases de

Propiedades

stage cadena. Obligatorio como primera propiedad.
id. de la fase.

displayName cadena.
nombre legible para la fase.

pool grupo de.
Grupo donde se ejecutarán los trabajos de esta fase a menos que se especifique lo contrario.

cadena de dependsOn | lista de cadenas.
Todas las fases que deben completarse antes de esta. De forma predeterminada, las fases se ejecutan secuencialmente en el orden definido en la canalización. Especifique dependsOn: [] para una fase si no debe depender de la fase anterior de la canalización.

condition cadena.
Evaluar esta expresión de condición para determinar si se debe ejecutar esta fase.

variables variables.
variables específicas de la fase.

jobs trabajos.
trabajos que componen la fase.

lockBehavior cadena.
las solicitudes de bloqueo de comportamiento de esta fase deben mostrarse en relación con otras solicitudes de bloqueo exclusivas. secuencial | runLatest.

trigger cadena.
desencadenador stage manual o automático (valor predeterminado). manual | Automático.

isSkippable booleano .
Establecer false impide que se omita la fase. De forma predeterminada, siempre es true.

templateContext templateContext.
información relacionada con la fase que se pasa desde una canalización al extender una plantilla. Para obtener más información sobre templateContext, vea plantillas de canalizaciones de YAML extendidas ahora se pueden pasar información de contexto para fases, trabajos e implementaciones y plantillas de : usar templateContext para pasar propiedades a plantillas.

Observaciones

Para obtener más información sobre templateContext, vea plantillas de canalizaciones de YAML extendidas ahora se pueden pasar información de contexto para fases, trabajos e implementaciones y plantillas de : usar templateContext para pasar propiedades a plantillas.

Use comprobaciones de aprobación para controlar manualmente cuándo se debe ejecutar una fase. Estas comprobaciones se usan normalmente para controlar las implementaciones en entornos de producción.

Las comprobaciones son un mecanismo disponible para el propietario del recurso . Controlan cuándo una fase de una canalización consume un recurso. Como propietario de un recurso como un entorno, puede definir comprobaciones necesarias antes de que se pueda iniciar una fase que consume el recurso.

Actualmente, las comprobaciones de aprobación manual se admiten en entornos de . Para obtener más información, vea Aprobaciones.

Bloqueo exclusivo

En las canalizaciones de YAML, las comprobaciones se usan para controlar la ejecución de fases en recursos protegidos. Una de las comprobaciones comunes que puede usar es una comprobación de bloqueo exclusiva . Esta comprobación permite que solo se ejecute una sola ejecución desde la canalización. Cuando varias ejecuciones intentan implementar en un entorno al mismo tiempo, la comprobación cancela todas las ejecuciones antiguas y permite implementar la ejecución más reciente.

Puede configurar el comportamiento de la comprobación de bloqueo exclusiva mediante la propiedad lockBehavior, que tiene dos valores:

  • runLatest: solo la ejecución más reciente adquiere el bloqueo en el recurso. Este es el valor predeterminado si no se especifica ningún lockBehavior.
  • sequential: todas las ejecuciones adquieren el bloqueo secuencialmente en el recurso protegido.

Cancelar ejecuciones antiguas es un buen enfoque cuando las versiones son acumulativas y contienen todos los cambios de código de las ejecuciones anteriores. Sin embargo, hay algunas canalizaciones en las que los cambios de código no son acumulativos. Al configurar la propiedad lockBehavior, puede optar por permitir que todas las ejecuciones continúen e implementen secuencialmente en un entorno, o conserven el comportamiento anterior de cancelar ejecuciones antiguas y permitir solo lo más reciente. Un valor de sequential implica que todas las ejecuciones adquieren el bloqueo secuencialmente en el recurso protegido. Un valor de runLatest implica que solo la ejecución más reciente adquiere el bloqueo en el recurso.

Para usar la comprobación de bloqueo exclusiva con sequential implementaciones o runLatest, siga estos pasos:

  1. Habilite la comprobación de bloqueo exclusiva en el entorno (u otro recurso protegido).
  2. En el archivo YAML de la canalización, especifique una nueva propiedad denominada lockBehavior. Esto se puede especificar para toda la canalización o para una fase determinada:

Establézcalo en una fase:

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

Establézcalo en la canalización:

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

Bloqueo exclusivo en el nivel de fase

Algunos casos de uso requieren una canalización para acceder a un recurso específico solo una vez en un momento dado. Para admitir este caso, tenemos la comprobación de bloqueo exclusiva descrita en la sección anterior.

Se produce una situación similar cuando solo una ejecución de canalización debe acceder a una fase en cualquier momento dado. Por ejemplo, si tiene una fase que se implementa en un grupo de recursos de Azure, puede impedir que varias ejecuciones de canalización actualicen simultáneamente el mismo grupo de recursos. Actualmente, lograr esto requiere el uso de un recurso de proxy, como un entorno, y la colocación de la comprobación de bloqueo exclusiva en ese entorno. Este enfoque puede llevar mucho tiempo, agregar complejidad y aumentar los esfuerzos de mantenimiento.

Si necesita asegurarse de que solo una ejecución de canalización puede acceder a una fase, puede especificar el bloqueo exclusivo en el nivel de fase. Si tiene una fase con un identificador y especifica su propiedad lockBehavior, se crea automáticamente un bloqueo para esa fase. El comportamiento secuencial sigue siendo coherente para los bloqueos de nivel de recurso y de nivel de fase. Sin embargo, el comportamiento de runLatest difiere, ya que solo cancela runLatest compilaciones para la misma rama, no para todas las ramas de la canalización.

Ejemplos

En este ejemplo se ejecuta tres fases, una después de otra. La fase intermedia ejecuta dos trabajos en 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!

En este ejemplo se ejecutan dos fases en paralelo. Por motivos de brevedad, se omiten los trabajos y los pasos.

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 también

Obtenga más información sobre las fases de , condiciones de y variables de .