Adición de fases, dependencias y condiciones

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Una fase es un límite lógico en una canalización de Azure DevOps. Las fases se pueden usar para agrupar acciones en el proceso de desarrollo de software (por ejemplo, compilar la aplicación, ejecutar pruebas, implementar en entorno de preproducción). Cada fase puede contener uno o varios trabajos.

Al definir varias fases en una canalización, de forma predeterminada, se ejecutan una después de la otra. Las fases también pueden depender entre sí. Puede usar la palabra clave dependsOn para definir dependencias. Las fases también se pueden ejecutar en función del resultado de una fase anterior con condiciones.

Para aprender cómo funcionan las fases con trabajos paralelos y licencias, consulte Configuración y pago de trabajos paralelos.

Para averiguar cómo se relacionan las fases con otras partes de una canalización, como los trabajos, consulte Conceptos de canalizaciones clave.

También puede aprender sobre cómo se relacionan las fases de una canalización en el artículo Fases del esquema YAML.

YAML

Puede organizar los trabajos de canalización en fases. Las fases son las divisiones principales de una canalización: compilar esta aplicación, ejecutar estas pruebas e implementar en el entorno preproducción son buenos ejemplos de fases. Son límites lógicos en la canalización donde puede pausar la canalización y realizar varias comprobaciones.

Cada canalización tiene al menos una fase aunque no la defina explícitamente. También puede organizar las fases en un gráfico de dependencias para que una fase se ejecute antes que otra. Hay un límite de 256 trabajos por etapa.

Clásico

Organice en fases los trabajos de implementación en la canalización de versiones. Las fases son las principales divisiones de la canalización de versiones: la ejecución de pruebas funcionales, la implementación en entorno de preproducción y la implementación en producción son buenos ejemplos de fases de lanzamiento.

Una fase de una canalización de versión consta de trabajos y tareas.

Las aprobaciones y validaciones, las condiciones y desencadenadores de implementación y las directivas de puesta en cola controlan cuándo se implementa una versión en una fase.

Especificación de fases

YAML

En el caso más sencillo, no necesita ningún límite lógico en la canalización. En ese caso, no es necesario usar explícitamente la palabra clave stage. Puede especificar directamente los trabajos en el archivo 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"

Si organiza la canalización en varias fases, use la palabra clave stages.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Si decide especificar un pool en el nivel de fase, todos los trabajos definidos en esa fase utilizarán ese grupo, a menos que se especifique a nivel de trabajo.

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

La sintaxis completa para especificar una fase es:

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]

Clásico

Para agregar una fase a la canalización de versión, seleccione la canalización de versión en la página Versiones, seleccione la acción Editar para modificarla y, luego, seleccione la pestaña Canalización. Aunque la parte más importante de definir una fase son las tareas de automatización, también puede configurar varias propiedades y opciones para una fase en una canalización de versión. Puede:

• Editar el nombre de la fase aquí si es necesario.
• Designar un usuario o un grupo como propietario de la fase. Los propietarios de la fase reciben una notificación cada vez que se produce un error en una implementación en esa fase. Ser propietario de una fase no se incluye automáticamente con ningún permiso.
• Eliminar la fase de la canalización.
• Cambiar el orden de las fases.
• Guardar una copia de la fase como plantilla de fase.
• Administrar la configuración de seguridad de la fase.

Especificación de dependencias

YAML

Al definir varias fases en una canalización, de forma predeterminada, se ejecutan secuencialmente en el orden en que se definen en el archivo YAML. La excepción a esto es cuando se agregan dependencias. Con las dependencias, las fases se ejecutan en el orden de los requisitos dependsOn.

Las canalizaciones deben contener al menos una fase sin dependencias.

La sintaxis para definir varias fases y sus dependencias es:

stages:
- stage: string
  dependsOn: string
  condition: string

Fases de ejemplo que se ejecutan secuencialmente:

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

Fases de ejemplo que se ejecutan en 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:
    ...

Ejemplo de distribución ramificada de entrada y salida:

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

Clásico

Puede controlar las dependencias estableciendo los desencadenadores en cada fase de la canalización de versión:

• Las fases se ejecutan con un desencadenador o se inician manualmente.
• Con un desencadenador Después del lanzamiento, una fase se inicia tan pronto como se inicia el lanzamiento, en paralelo con otras fases que tienen un desencadenador Después del lanzamiento.
• Con un desencadenador Después de la fase, se iniciará una fase después de que se completen todas las fases dependientes. Con esto, puede modelar el comportamiento de distribución ramificada de entrada y salida de las fases.

Definir condiciones

Puede especificar las condiciones en las que se ejecuta cada fase con expresiones. De manera predeterminada, una fase se ejecuta si no depende de ninguna otra fase, o si todas las fases de las que depende se han completado y funcionan correctamente. Puede personalizar este comportamiento forzando la ejecución de una fase aunque se produzca un error en una fase anterior o especificando una condición personalizada.

Si personaliza la condición predeterminada de los pasos anteriores de una fase, se eliminan las condiciones de finalización y éxito. Por lo tanto, si usa una condición personalizada, es habitual usar and(succeeded(),custom_condition) para comprobar si la fase anterior se ejecutó correctamente. De lo contrario, la fase se ejecuta independientemente del resultado de la fase anterior.

Nota:

Las condiciones de ("JOBNAME/STAGENAME") incorrectos y ("JOBNAME/STAGENAME") correctos que se muestran en el ejemplo siguiente solo funcionan con canalizaciones YAML.

YAML

Ejemplo para ejecutar una fase en función del estado de ejecución de una fase 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')

Ejemplo de uso de una condición personalizada:

stages:
- stage: A

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

Clásico

Al especificar desencadenadores Después de la versión o Después de la fase, también puede especificar los filtros de rama para los artefactos consumidos en la versión. Las versiones solo se implementarán en una fase en la que se cumplan los filtros de rama.

Especificación de directivas de puesta en cola

YAML

Las canalizaciones YAML no admiten directivas de puesta en cola. Cada ejecución de una canalización es independiente de las demás y las desconoce. En otras palabras, las dos confirmaciones sucesivas pueden desencadenar dos canalizaciones y ambas ejecutarán la misma secuencia de fases sin esperarse unas a otras. Mientras trabajamos para llevar las directivas de puesta en cola a las canalizaciones YAML, se recomienda usar aprobaciones manuales para secuenciar y controlar manualmente el orden de ejecución si este es importante.

Clásico

En algunos casos, es posible que pueda generar compilaciones más rápidas de las que se pueden implementar. Como alternativa, puede configurar varios agentes y, por ejemplo, crear versiones desde la misma canalización de versión para la implementación de diferentes artefactos. En tales casos, resulta útil poder controlar cómo se ponen en cola varias versiones en una fase. Las directivas de puesta en cola proporcionan ese control.

Las opciones que puede elegir para una directiva de puesta en cola son:

• Número de implementaciones paralelas: use esta opción si aprovisiona dinámicamente nuevos recursos en la fase y es físicamente capaz de controlar la implementación de varias versiones en paralelo, pero quiere limitar el número de estas.

• Si especifica un número máximo de implementaciones, aparecen dos opciones más:

  • Implementar todo en secuencia: use esta opción si quiere implementar todas las versiones secuencialmente en los mismos recursos físicos compartidos. Al implementar las compilaciones por turnos, una después de la otra, tiene la seguridad de que dos trabajos de implementación no se dirigen a la vez a los mismos recursos físicos, incluso si hay varios agentes de compilación y versión disponibles. También se asegura de que las solicitudes de aprobación previas a la implementación de la fase se envíen en secuencia.

  • Implementar la versión más reciente y cancelar las demás: use esta opción si va a generar compilaciones más rápidas que las versiones y solo quiere implementar la compilación más reciente.

Para comprender cómo funcionan estas opciones, considere un escenario en el que las versiones R1, R2, ..., R5 de una sola canalización de versión se crean en una sucesión rápida. Por ejemplo, supongamos que la primera fase de esta canalización se denomina Control de calidad y tiene definidos aprobadores previos y posteriores a la implementación.

• Si no especifica un límite para el número de implementaciones paralelas, las cinco solicitudes de aprobación se envían tan pronto como se crean las versiones. Si los aprobadores aprueban todas las versiones, todas se implementarán en la fase QA en paralelo. (si la fase Control de calidad no tenía definido ningún aprobador previo a la implementación, las cinco versiones se implementarán automáticamente en paralelo a esta fase).

• Si especifica un límite e elige Implementar todo en secuencia, y el límite ya se ha alcanzado, la aprobación previa a la implementación de la versión R1 se enviará primero. Una vez completada esta aprobación, comienza la implementación de la versión R1 en la fase QA. A continuación, se envía una solicitud de aprobación posterior a la implementación para la versión R1. Solo después de que se complete esta aprobación posterior a la implementación, comienza la ejecución de la versión R2 y se envía su aprobación previa a la implementación. El proceso continúa así para todas las versiones a su vez.

• Si especifica un límite y elige Implementar la versión más reciente y cancelar las demás, y el límite ya se ha alcanzado, se omitirán las versiones R2, R3 y R4 y la aprobación previa a la implementación de R5 en la fase Control de calidad se enviará inmediatamente después de que se complete la aprobación posterior a la implementación de la versión R1.

Especificación de aprobaciones

YAML

Puede controlar manualmente cuándo se debe ejecutar una fase mediante comprobaciones de aprobación. 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 para controlar si una fase de una canalización puede consumir un recurso y cuándo puede hacerlo. Como propietario de un recurso, por ejemplo, un entorno, puede definir las comprobaciones que deben cumplirse antes de que se pueda iniciar una fase que consuma ese recurso.

Actualmente, se admiten comprobaciones de aprobación manuales en entornos. Para más información, consulte Aprobaciones.

Clásico

Puede agregar aprobaciones manuales al principio o al final de cada fase de la canalización. Para más información, consulte Introducción a las aprobaciones y validaciones de versiones.

Adición de un desencadenador manual

Las fases de canalización YAML desencadenadas manualmente le permiten tener una canalización unificada sin ejecutarla siempre hasta su finalización.

Por ejemplo, la canalización puede incluir fases para compilar, probar, implementar en un entorno de ensayo e implementar en producción. Es posible que quiera que todas las fases se ejecuten automáticamente, excepto la implementación en producción, que prefiere desencadenar manualmente cuando esté lista.

Para usar esta característica, agregue la propiedad trigger: manual a una fase.

En el ejemplo siguiente, la fase de desarrollo se ejecuta automáticamente, mientras que la fase de producción requiere desencadenamiento manual. Ambas fases ejecutan un script de salida hola mundo.

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 una fase como no omitible

Marque una fase como isSkippable: false para evitar que los usuarios de canalización omitan las fases. Por ejemplo, puede tener una plantilla YAML que inserte una fase que realice la detección de malware en todas las canalizaciones. Si establece isSkippable: false para esta fase, la canalización no podrá omitir la detección de malware.

En el ejemplo siguiente, la fase de detección de malware se marca como no omitible, lo que significa que se debe ejecutar como parte de la ejecución de la canalización.

- stage: malware_detection
  displayName: Malware detection
  isSkippable: false
  jobs:
  - job: check_job
    ...

Cuando una fase es no omitible, se mostrará con una casilla deshabilitada en el panel de configuración Fases para ejecutar.