Descripción de las fases de canalización

Las canalizaciones permiten automatizar los pasos del proceso de implementación. El proceso puede incluir varios grupos lógicos de trabajos que quiera ejecutar. En esta unidad, obtendrá información sobre las fases de canalización y cómo usarlas para agregar procesos de control de calidad a las implementaciones de Bicep.

¿Qué son las fases de canalización?

Las fases le ayudan a dividir la canalización en varios bloques lógicos. Cada fase puede contener uno o varios trabajos. Los trabajos contienen una lista ordenada de pasos que se deben completar, como la ejecución de scripts de línea de comandos.

Puede usar las fases en la canalización para marcar una separación de intereses. Por ejemplo, al trabajar con código Bicep, validar el código es una tarea independiente de la implementación del archivo Bicep. Cuando se usa una canalización automatizada, la compilación y prueba del código se conoce a menudo como integración continua (CI). La implementación de código en una canalización automatizada a menudo se denomina implementación continua (CD).

Durante las fases de CI, comprueba la validez de los cambios que se han realizado en el código. Las fases de CI proporcionan control de calidad. Puede ejecutarlos sin afectar al entorno de producción en vivo.

En muchos lenguajes de programación, el código se debe compilar antes de que se pueda ejecutar. Cuando se implementa un archivo de Bicep se convierte, o transpila, de Bicep a JSON. Las herramientas realizan este proceso automáticamente. En la mayoría de las situaciones, no es necesario compilar manualmente el código de Bicep en plantillas JSON en la canalización. Pero se sigue usando el término integración continua cuando se habla de código de Bicep, porque todavía se aplican las demás partes de CI, como la validación del código.

Una vez que las fases de CI se ejecuten correctamente, debería haber aumentado la confianza de que los cambios realizados también se implementarán correctamente. En las fases de CD, el código se implementa en cada uno de los entornos. Normalmente, comienza con entornos de prueba y otros entornos que no son de producción y, a continuación, continúa con entornos de producción. En este módulo, implementarás en un único entorno. En un módulo posterior, aprenderá a ampliar la canalización de implementación para implementarla en varios entornos, como los de producción y los que no son de producción.

Las fases se ejecutan en una secuencia. Puede controlar cómo y cuándo se ejecuta cada fase. Por ejemplo, puede configurar las fases de CD para que solo se ejecuten después de que las fases de CI se ejecuten correctamente. O puede que tenga varias fases de CI que necesiten ejecutarse en secuencia, por ejemplo, para compilar el código y, a continuación, probarlo. También puede incluir una fase de reversión que solo se ejecute si se produce un error en las fases de implementación anteriores.

Desplazamiento a la izquierda

Mediante el uso de fases, puede comprobar la calidad del código antes de implementarlo. El uso de estas fases a veces se denomina desplazamiento a la izquierda.

Al escribir código, plantéese una escala de tiempo de las actividades que se llevan a cabo. La escala de tiempo comienza con las fases de planificación y diseño. Después, pasa a las fases de compilación y pruebas. Por último, implemente y brinde soporte a su solución. En el diagrama siguiente se muestran estas fases en una escala de tiempo.

Es una regla bien conocida en el desarrollo de software que, cuanto antes se detecta un error en el proceso (cuanto más cerca del inicio de la línea de tiempo), más fácil, más rápido y más barato es corregirlo. Cuanto más tarde en el proceso se detecte un error, más difícil será corregirlo.

Por lo tanto, el objetivo es desplazar la detección de problemas hacia el lado izquierdo del diagrama. A lo largo de este módulo, verá cómo puede agregar más validación y pruebas a la canalización a medida que avanza.

Incluso puede agregar la validación mucho antes de que comience la implementación. Cuando se trabaja con herramientas como Azure DevOps, las solicitudes de incorporación de cambios suelen representar los cambios que alguien del equipo quiere realizar en el código de la rama principal. Resulta útil crear otra canalización que ejecute automáticamente los pasos de CI durante el proceso de revisión de la solicitud de incorporación de cambios. Esta técnica permite validar que el código todavía funciona, incluso con los cambios propuestos. Si la validación se realiza correctamente, tiene cierta confianza en que el cambio no causará problemas cuando se combine con la rama principal. Si se produce un error en la comprobación, sabe que hay más trabajo que hacer antes de que la solicitud de cambios esté lista para combinarse.

Definición de una fase de canalización

Cada canalización tiene al menos una fase. Si la canalización solo tiene una fase, no es necesario definirla explícitamente. Azure Pipelines la define de forma automática. Cuando tiene varias fases en una canalización, debe definir cada una de ellas. Las fases se ejecutan en la secuencia que especifique.

Imagine que ha compilado un archivo de Bicep que tiene que implementar dos veces: en la infraestructura de Estados Unidos y en la de Europa. Antes de implementar el archivo, valide el código de Bicep. Esta es una ilustración de una canalización de varias fases que define este proceso:

Observe que este ejemplo tiene tres fases. La fase Validate (Validación) es similar a una fase de CI. Las fases DeployUS e DeployEurope se ejecutan a continuación. Cada uno implementa el código en uno de los entornos.

Aquí se muestra cómo se definen las fases en un archivo YAML de canalización:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  jobs: 
  - job: DeployEurope

Control de la secuencia de fases

De forma predeterminada, las fases se ejecutan en el orden que defina. Una etapa solo se ejecuta si la etapa anterior tiene éxito. Puede agregar dependencias entre las fases para cambiar el orden.

Siguiendo con el ejemplo anterior, imagine que quiere ejecutar las dos implementaciones en paralelo, de esta forma:

Puede especificar las dependencias entre fases mediante la palabra clave dependsOn:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: DeployUS
  dependsOn: Test
  jobs: 
  - job: DeployUS

- stage: DeployEurope
  dependsOn: Test
  jobs: 
  - job: DeployEurope

Cuando se usa la palabra clave dependsOn, Azure Pipelines espera a que la fase dependiente se complete correctamente antes de iniciar la siguiente fase. Si Azure Pipelines detecta que se cumplen todas las dependencias de varias fases, puede ejecutar esas fases en paralelo.

Es posible que desee ejecutar una fase cuando se produce un error en una fase anterior. Por ejemplo, esta es otra canalización. Si se produce un error en la implementación, inmediatamente después se ejecuta una fase denominada Reversión:

Puede usar la palabra clave condition para especificar una condición que se deba cumplir antes de que se ejecute una fase:

stages:

- stage: Test
  jobs:
  - job: Test

- stage: Deploy
  dependsOn: Test
  jobs: 
  - job: Deploy

- stage: Rollback
  condition: failed('Deploy')
  jobs: 
  - job: Rollback

En el ejemplo anterior, cuando todo es correcto, Azure Pipelines ejecuta primero la fase Validate (Validación) y después la fase Deploy (Implementación). Omite la fase Rollback (Reversión). Pero si se produce un error en la fase Deploy (Implementación), Azure Pipelines ejecuta la fase Rollback (Reversión). Obtendrá más información sobre la reversión más adelante en este módulo.

Cada trabajo se ejecuta en un nuevo agente. Esto significa que cada trabajo comienza desde un entorno limpio, por lo que en cada trabajo normalmente se necesita obtener el código fuente como primer paso.

Fases de implementación de Bicep

Una canalización de implementación típica de Bicep contiene varias fases. A medida que la canalización avanza por las fases, el objetivo es estar cada vez más seguro de que las fases posteriores serán correctas. Estas son las fases comunes de una canalización de implementación de Bicep:

1. Lint: use el linter de Bicep para comprobar que el archivo de Bicep está bien formado y no contiene errores obvios.
2. Validar: use el proceso de validación preparatoria de Azure Resource Manager para comprobar si hay problemas que pueden producirse durante la implementación.
3. Versión preliminar: use el comando what-if para validar una lista de cambios que se aplicarán en el entorno de Azure. Pida a una persona que revise manualmente los resultados hipotéticos y apruebe la canalización para continuar.
4. Deploy (Implementación): envíe la implementación a Resource Manager y espere a que se complete.
5. Prueba de humo: Ejecute comprobaciones básicas posteriores a la implementación en algunos de los recursos importantes que implementó. Estas revisiones se denominan pruebas de comprobación de la compilación de la infraestructura.

Es posible que la organización tenga otra secuencia de fases o que necesite integrar las implementaciones de Bicep en una canalización que implemente otros componentes. Una vez que comprenda cómo funcionan las fases, puede diseñar una canalización que se adapte a las necesidades.

A lo largo de este módulo, obtendrá más información sobre estas fases y creará progresivamente una canalización en la que se incluya cada una de ellas. También descubrirá lo siguiente:

• Cómo las canalizaciones detienen el proceso de implementación si ocurre algo inesperado durante cualquiera de las fases anteriores.
• Cómo configurar la canalización para que se pause hasta que compruebe manualmente lo que ha ocurrido en un trabajo anterior.