Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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.
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.
Especificación de fases
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
Especificación de dependencias
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
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.
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'))
Especificar políticas de puesta en cola
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.
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.
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.