Control de similitudes entre entornos mediante plantillas de canalización

5 minutos

Cuando se implementan cambios en varios entornos, los pasos de implementación para cada entorno son similares o incluso idénticos. En esta unidad va a aprender a usar plantillas de canalización para evitar la repetición y permitir la reutilización del código de canalización.

Implementación en varios entornos

Después de hablar con los compañeros del equipo del sitio web, decide usar la siguiente canalización para el sitio web de la empresa de juguetes:

Diagrama que muestra una serie de fases de canalización que incluyen las de las implementaciones de prueba y producción.

La canalización ejecuta el linter de Bicep para comprobar que el código de Bicep es válido y sigue los procedimientos recomendados.

El linting se produce en el código de Bicep sin necesidad de conectarse a Azure, por lo que no importa el número de entornos en los que se va a implementar. Solo se ejecuta una vez.
La canalización se implementa en el entorno de prueba. Esta fase exige:
1. Ejecutar la validación preparatoria de Azure Resource Manager.
2. Implementar el código de Bicep.
3. Ejecutar algunas pruebas en el entorno de prueba.
Si se produce un error en alguna parte de la canalización, se detiene toda ella para que se pueda investigar y resolver el problema. Pero si todo se ejecuta correctamente, la canalización pasa a implementarse en el entorno de producción:
1. La canalización ejecuta una fase de versión preliminar, que ejecuta la operación hipotética en el entorno de producción para indicar los cambios que se harían en los recursos de Azure de producción. La fase de versión preliminar también valida la implementación, por lo que no es necesario ejecutar una fase de validación independiente en el entorno de producción.
2. La canalización se pone en pausa para la validación manual.
3. Si se recibe la aprobación, la canalización ejecuta las pruebas de implementación y de aceptación de la compilación en el entorno de producción.

Algunas de estas fases se repiten en los entornos de prueba y producción, mientras que otras solo se ejecutan en entornos específicos:

Fase	Entornos
Lint	Ninguno: el linting no funciona en un entorno
Validación	Solo prueba
Versión preliminar	Solo producción
Implementar	Ambos entornos
Prueba de aceptación de la compilación	Ambos entornos

Si necesita repetir pasos de la canalización, puede intentar copiar y pegar las definiciones de los pasos, Sin embargo, es mejor evitar esta práctica. Es fácil cometer errores sutiles accidentalmente o que los elementos no se sincronicen cuando se duplica el código de la canalización. Además, en el futuro, si necesita realizar un cambio en los pasos, tiene que acordarse de aplicar el cambio en varios lugares.

Plantillas de canalización

Las plantillas de canalización permiten crear secciones reutilizables de definiciones de canalización. Las plantillas pueden definir pasos, trabajos o incluso fases completas. Puede usar plantillas para reutilizar partes de una canalización varias veces en una sola canalización, o incluso en varias canalizaciones. También puede crear una plantilla de un conjunto de variables que quiera reutilizar en varias canalizaciones.

Una plantilla es simplemente un archivo YAML que contiene el contenido reutilizable. Una plantilla simple de una definición de paso podría tener este aspecto y guardarse en un archivo de nombre script.yml:

steps:
- script: |
    echo Hello world!

Puede usar una plantilla en la canalización mediante la palabra clave template en el lugar donde normalmente definiría el paso individual:

jobs:
- job: Job1
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

Plantillas anidadas

También puede anidar plantillas en otras plantillas. Imagine que el archivo anterior se denomina jobs.ymly que crea un archivo de nombre azure-pipelines.yml que reutiliza la plantilla de trabajo en varias fases de canalización:

trigger:
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

stages:

- stage: Stage1
  jobs:
  - template: jobs.yml

- stage: Stage2
  jobs:
  - template: jobs.yml

Al anidar plantillas, o reutilizarlas varias veces en una sola canalización, debe tener cuidado de no usar accidentalmente el mismo nombre para varios recursos de canalización. Por ejemplo, cada trabajo de una fase necesita su propio identificador. Por lo tanto, si define el identificador de trabajo en una plantilla, no puede reutilizarla varias veces en la misma fase.

Cuando se trabaja con conjuntos complejos de canalizaciones de implementación, puede resultar útil crear un repositorio de Git dedicado para las plantillas de canalización compartidas. Luego puede reutilizar el mismo repositorio en varias canalizaciones, aunque sean de proyectos diferentes. En el resumen se proporciona un vínculo para obtener más información.

Parámetros de plantilla de canalización

Los parámetros de plantilla de canalización facilitan la reutilización de los archivos de plantilla, ya que se puede permitir que haya pequeñas diferencias en las plantillas cada vez que se usen.

Al crear una plantilla de canalización, puede indicar sus parámetros en la parte superior del archivo:

parameters: 
- name: environmentType
  type: string
  default: 'Test'
- name: serviceConnectionName
  type: string

Puede definir tantos parámetros como necesite. Pero al igual que sucede con los parámetros de Bicep, intente no usar en exceso los parámetros de plantilla de canalización. Debe facilitar que otra persona reutilice la plantilla sin tener que especificar demasiadas configuraciones.

Cada parámetro de plantilla de canalización tiene tres propiedades:

El nombre del parámetro, que se usa para hacer referencia al parámetro en los archivos de plantilla.
El tipo del parámetro. Los parámetros admiten varios tipos de datos diferentes, como de cadena, numéricos y booleanos. También puede definir plantillas más complejas que acepten objetos estructurados.
El valor predeterminado del parámetro, que es opcional. Si no especifica un valor predeterminado, se debe proporcionar un valor cuando se use la plantilla de canalización.

En el ejemplo, la canalización define un parámetro de cadena denominado environmentType, que tiene un valor predeterminado de Test y un parámetro obligatorio denominado serviceConnectionName.

En la plantilla de canalización se usa una sintaxis especial para hacer referencia al valor del parámetro. Use la macro ${{parameters.YOUR_PARAMETER_NAME}}, como en este ejemplo:

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

El valor de los parámetros se pasa a una plantilla de canalización mediante la palabra clave parameters, como en este ejemplo:

steps:
- template: script.yml
  parameters:
    environmentType: Test

- template: script.yml
  parameters: 
    environmentType: Production

También puede usar parámetros al asignar identificadores a los trabajos y las fases en plantillas de canalización. Esta técnica ayuda cuando se necesita reutilizar la misma plantilla varias veces en la canalización, así:

parameters:
- name: environmentType
  type: string
  default: 'Test'

jobs:
- job: Job1-${{parameters.environmentType}}
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2-${{parameters.environmentType}}
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

Condiciones

Puede usar condiciones de canalización para especificar si se debe ejecutar un paso, un trabajo o incluso una fase en función de una regla que especifique. Puede combinar parámetros de plantilla y condiciones de canalización para personalizar el proceso de implementación en muchas situaciones diferentes.

Por ejemplo, imagine que define una plantilla de canalización que ejecuta pasos de script. Tiene previsto reutilizar la plantilla en cada uno de los entornos. Al implementar el entorno de producción, quiere ejecutar otro paso. Aquí se muestra cómo hacerlo mediante la macro if y el operador eq (es igual a):

parameters: 
- name: environmentType
  type: string
  default: 'Test'

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

- ${{ if eq(parameters.environmentType, 'Production') }}:
  - script: |
      echo This step only runs for production deployments.

La condición aquí se convierte en: si el valor del parámetro environmentType es igual a "Production", ejecutar los siguientes pasos.

Sugerencia

Preste atención a la sangría del archivo YAML cuando use condiciones como la del ejemplo. Los pasos a los que se aplica la condición deben tener aplicada una sangría de un nivel adicional.

También puede especificar la propiedad condition en una fase, un trabajo o un paso. Este es un ejemplo en el que se muestra cómo usar el operador ne (no es igual a) para especificar una condición como si el valor del parámetro environmentType no es igual a "Production", ejecutar los pasos siguientes:

- script: |
    echo This step only runs for non-production deployments.
  condition: ne('${{ parameters.environmentType }}', 'Production')

Aunque las condiciones son una manera de agregar flexibilidad a la canalización, intente no usar demasiadas. Complican la canalización y hacen que sea más difícil comprender su flujo. Si hay muchas condiciones en la plantilla de canalización, es posible que esta no sea la mejor solución para el flujo de trabajo que planea ejecutar, y puede que tenga que rediseñar la canalización.