Agregar 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. Fases agrupa acciones en el proceso de desarrollo de software, como compilar la aplicación, ejecutar pruebas e implementar en 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, incluso si no la define explícitamente. También puede organizar las fases en un gráfico de dependencias para que una fase se ejecute antes que otra. Una fase puede tener hasta 256 trabajos.

Clásico

Organice en fases los trabajos de implementación en la canalización de versiones. Las fases principales de la tubería de lanzamiento. Entre los ejemplos se incluyen la ejecución de pruebas funcionales, la implementación en la preproducción y la implementación en producción.

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 límites lógicos en la canalización. En esos escenarios, puede especificar directamente los trabajos en el archivo YAML sin la stages palabra clave . Por ejemplo, si tiene una canalización sencilla que compila y prueba una aplicación pequeña sin necesidad de entornos o pasos de implementación independientes, puede definir todos los trabajos directamente sin usar fases.

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: BuildAndTest
  steps:
  - script: echo "Building the application"
  - script: echo "Running tests"

Esta canalización tiene una fase implícita y dos tareas. La stages palabra clave no se usa porque solo hay una fase.

jobs:
- job: Build
  steps:
  - bash: echo "Building"

- job: Test
  steps:
  - bash: echo "Testing"

Para organizar la canalización en varias fases, use la stages palabra clave . Este YAML define una canalización con dos fases en las que cada fase contiene varios trabajos y cada trabajo tiene pasos específicos para ejecutarse.

stages:
- stage: A
  displayName: "Stage A - Build and Test"
  jobs:
  - job: A1
    displayName: "Job A1 - build"
    steps:
    - script: echo "Building the application in Job A1"
      displayName: "Build step"
  - job: A2
    displayName: "Job A2 - Test"
    steps:
    - script: echo "Running tests in Job A2"
      displayName: "Test step"

- stage: B
  displayName: "Stage B - Deploy"
  jobs:
  - job: B1
    displayName: "Job B1 - Deploy to Staging"
    steps:
    - script: echo "Deploying to staging in Job B1"
      displayName: "Staging deployment step"
  - job: B2
    displayName: "Job B2 - Deploy to Production"
    steps:
    - script: echo "Deploying to production in Job B2"
      displayName: "Production deployment step"

Si especifica un pool en el nivel de etapa, todos los trabajos de esa etapa utilizan ese grupo, a menos que el grupo se especifique en el 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

Clásico

Para agregar una etapa a la canalización de publicación, seleccione la canalización de publicación en la página Versiones, seleccione Editar y, a continuación, seleccione la pestaña Canalización. Aunque la parte más importante de la definición de una etapa son las tareas de automatización, también puede configurar varias propiedades y opciones para una etapa en una canalización de publicación. Puedes:

• 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. La propiedad de la etapa no incluye automáticamente los permisos.
• 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, se ejecutan secuencialmente de forma predeterminada 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.

Para obtener más información sobre cómo definir fases, consulte fases en el esquema YAML.

Las siguientes fases de ejemplo se ejecutan secuencialmente. Si no usa una dependsOn palabra clave , las fases se ejecutan en el orden en que se definen.

stages:
- stage: Build
  displayName: "Build Stage"
  jobs:
  - job: BuildJob
    steps:
    - script: echo "Building the application"
      displayName: "Build Step"

- stage: Test
  displayName: "Test Stage"
  jobs:
  - job: TestJob
    steps:
    - script: echo "Running tests"
      displayName: "Test Step"

Fases de ejemplo que se ejecutan en paralelo:

stages:
- stage: FunctionalTest
  displayName: "Functional Test Stage"
  jobs:
  - job: FunctionalTestJob
    steps:
    - script: echo "Running functional tests"
      displayName: "Run Functional Tests"

- stage: AcceptanceTest
  displayName: "Acceptance Test Stage"
  dependsOn: [] # Runs in parallel with FunctionalTest
  jobs:
  - job: AcceptanceTestJob
    steps:
    - script: echo "Running acceptance tests"
      displayName: "Run Acceptance Tests"

Ejemplo de comportamiento de expansión y convergencia:

stages:
- stage: Test

- stage: DeployUS1
  dependsOn: Test    #  stage runs after Test

- stage: DeployUS2
  dependsOn: Test    # stage runs in parallel with DeployUS1, after Test

- stage: DeployEurope
  dependsOn:         # stage runs after DeployUS1 and DeployUS2
  - DeployUS1
  - DeployUS2

Clásico

Gestione las dependencias estableciendo activadores en cada fase del pipeline de lanzamiento.

• Las fases se ejecutan con un desencadenador o se inician manualmente.
• Con un desencadenador Después del lanzamiento, una etapa se inicia tan pronto como comienza el lanzamiento, ejecutándose en paralelo con otras etapas que tienen el mismo desencadenador.
• Con un desencadenador Etapa Posterior, se inicia una etapa después de que se completen todas las etapas 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.

Especificar políticas de puesta en cola

YAML

Las canalizaciones YAML no admiten políticas de cola. Cada ejecución de una canalización es independiente de las demás y las desconoce. En otras palabras, tus dos confirmaciones sucesivas podrían desencadenar dos canalizaciones, y ambas ejecutarán la misma secuencia de fases sin esperar una a la otra. 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ápido de las que se pueden implementar. Como alternativa, puede configurar varios agentes y, por ejemplo, estar creando lanzamientos desde la misma canalización de lanzamiento para implementar diferentes artefactos. En tales casos, resulta útil poder controlar cómo se ponen en cola varias versiones en una fase. Las políticas de cola proporcionan ese control.

Las opciones que puede elegir para una política 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, es posible que tenga una plantilla YAML que inserte una fase que realice la detección de malware en todas las canalizaciones. Si se establece isSkippable: false para esta etapa, el pipeline no podrá omitir la detección de malware.

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

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

Cuando una fase no se puede omitir, se muestra con una casilla deshabilitada en el panel de configuración Fases para ejecutar.