Descripción de las fases de canalización

Completado

Las canalizaciones le 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.

Las fases se pueden usar en la canalización para marcar una separación de intereses. Por ejemplo, cuando se trabaja con código de Bicep, la validación del código es un interés independiente de la implementación del archivo de 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).

En las fases de CI, se comprueba la validez de los cambios realizados en el código. Las fases de CI proporcionan control de calidad. Se pueden ejecutar sin afectar al entorno de producción en directo.

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 dentro de 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.

Después de que las fases de CI se ejecuten correctamente, debería haber aumentado la confianza de que los cambios que ha realizado también se implementarán correctamente. En las fases de CD, implementará el código en cada uno de los entornos. Normalmente, empezará con entornos de prueba y otros entornos que no son de producción y, después, pasará a entornos de producción. En este módulo, la implementación se realizará 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 bien, podría tener varias fases de CI que deben ejecutarse en secuencia, como la compilación del código y, después, probarlo. También podría incluir una fase de reversión que solo se ejecute si se ha producido 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. Estas fases a veces se denominan 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 a partir de las fases de planificación y diseño. Después, pasa a las fases de compilación y pruebas. Por último, realice la implementación y, después, tendrá que admitir la solución.

Una regla conocida en el desarrollo de software es que cuanto antes se encuentren los errores (cuanto más cerca estén a la izquierda de la escala de tiempo), más fácil, rápido y barato será corregirlos. Cuanto más tarde en el proceso se detecte un error, más difícil será corregirlo.

Por tanto, el objetivo es desplazar la detección de problemas hacia la izquierda del diagrama anterior. 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 incorporación de cambios esté lista para combinarse.

Importante

La eficacia de la validación automatizada y las pruebas es directamente proporcional a la de las pruebas que escriba. Es importante tener en cuenta los aspectos que necesita probar y los pasos que debe realizar para estar seguro de que la implementación es correcta.

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 realizar la implementación, 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. Después, se ejecutan las fases DeployUS e DeployEurope. 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 fase solo se ejecuta si la anterior se ha realizado correctamente. 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 han cumplido todas las dependencias de varias fases, puede ejecutarlas en paralelo.

Nota:

En realidad, las fases y los trabajos solo se ejecutan en paralelo si tiene suficientes agentes para ejecutar varios trabajos al mismo tiempo. Al usar agentes hospedados por Microsoft, es posible que tenga que adquirir trabajos paralelos adicionales para lograrlo.

En ocasiones querrá 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 agente nuevo. Eso significa que cada trabajo se iniciará desde un entorno limpio, por lo que en cada trabajo normalmente debe consultar 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. Validate (Validación): use el proceso de validación preparatoria de Azure Resource Manager para comprobar si hay problemas que podrían producirse al realizar la implementación.
3. Preview (Vista previa): use el comando hipotético para validar la lista de cambios que se aplicarán al 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. Smoke Test (Prueba de comprobación de la compilación): ejecute comprobaciones básicas posteriores a la implementación en algunos de los recursos importantes que ha implementado. 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 detienen las canalizaciones el proceso de implementación si ocurre algo inesperado en cualquiera de los trabajos anteriores.
• Cómo configurar la canalización para que se pause hasta que compruebe manualmente lo que ha ocurrido en un trabajo anterior.