Compartir a través de


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.

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.

Nota:

La compatibilidad con las fases se agregó en Azure DevOps Server 2019.1.

Especificación de fases

Nota:

La compatibilidad con las fases se agregó en Azure DevOps Server 2019.1.

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.

Nota:

En Azure DevOps Server 2019, solo se pueden especificar grupos 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]

Especificación de dependencias

Nota:

La compatibilidad con las fases se agregó en Azure DevOps Server 2019.1.

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

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.

Nota:

La compatibilidad con las fases se agregó en Azure DevOps Server 2019.1.

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'))

Especificación de directivas de puesta en cola

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.

Especificación de aprobaciones

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.

En esta versión de Azure DevOps Server, aún no se admiten aprobaciones en canalizaciones YAML.

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.

Captura de pantalla de las fases que se van a ejecutar con la fase deshabilitada.