Diseño de una canalización y estrategia de control de versiones
Cuando empiece a publicar código de Bicep reutilizable, probablemente use un enfoque manual. Es fácil determinar qué archivo de Bicep necesita publicar y probablemente tenga un proceso manual para incrementar el número de versión.
Si automatiza el proceso de publicación, debe tener en cuenta cómo automatizar estos pasos. En esta unidad aprenderá a adoptar un sistema de control de versiones que comunique los cambios realizados en el código. También aprenderá a definir el ámbito de las canalizaciones para publicar solo el código que espera.
Números de versión
En módulos de formación anteriores de Microsoft Learn ha aprendido sobre la importancia del control de versiones para las especificaciones de plantilla y los módulos de Bicep. Puede elegir entre muchos enfoques de control de versiones diferentes. En muchas ocasiones se recomienda usar un sistema de control de versiones de varias partes. Un sistema de control de versiones de varias partes consta de una versión principal, una versión secundaria y un número de revisión, similar al ejemplo siguiente:
En el ejemplo anterior la versión principal es 1, la versión secundaria es 4 y el número de revisión es 106.
Los cambios en diferentes partes de los números de versión comunican información importante sobre los tipos de cambios en el código:
Siempre que realice un cambio importante debe incrementar el número de versión principal. Por ejemplo, supongamos que agrega un nuevo parámetro obligatorio o quita un parámetro del archivo de Bicep. Estos son ejemplos de cambios importantes, ya que Bicep requiere que se especifiquen parámetros obligatorios en el momento de la implementación y no permite establecer valores para parámetros inexistentes. Por lo tanto, debe actualizar el número de versión principal.
Siempre que agregue algo nuevo al código que no sea un cambio importante, debe incrementar el número de versión secundaria. Por ejemplo, supongamos que agrega un nuevo parámetro opcional con un valor predeterminado. Los parámetros opcionales no son cambios importantes, por lo que debe actualizar el número de versión secundaria.
Siempre que realice correcciones de errores de compatibilidad con versiones anteriores u otros cambios que no afecten al funcionamiento del código, debe incrementar el número de revisión. Por ejemplo, supongamos que refactoriza el código de Bicep para hacer un mejor uso de variables y expresiones. Si la refactorización no cambia el comportamiento del código de Bicep, actualice el número de revisión.
La canalización también puede establecer automáticamente el número de revisión. El número de compilación de la canalización se puede usar como número de revisión. Esta convención ayuda a garantizar que los números de versión siempre sean únicos, incluso si no actualiza los demás componentes de los números de versión.
Por ejemplo, supongamos que usa un módulo de Bicep publicado anteriormente con un número de versión de 2.0.496. Verá que hay disponible una nueva versión del módulo con el número de versión 2.1.502. El único cambio significativo es para el número de versión secundaria, lo que indica que no debe esperar un cambio importante al usar la nueva versión.
Nota:
El control de versiones semántico es una estructura de control de versiones formalizada similar al control de versiones de varias partes. El control de versiones semántico incluye componentes adicionales en el número de versión, junto con reglas estrictas sobre cuándo se debe establecer o restablecer cada componente. En el resumen se incluye un vínculo para más información sobre el control de versiones semántico.
El equipo debe decidir cómo definir qué es un cambio importante para el control de versiones. Por ejemplo, suponga que ha creado un módulo de Bicep que implementa una cuenta de almacenamiento. Ahora va a actualizar el archivo de Bicep para habilitar puntos de conexión privados en la cuenta de almacenamiento. Va a agregar una zona DNS privada al archivo de Bicep al mismo tiempo.
En ese ejemplo es posible que pueda realizar el cambio sin afectar a los parámetros o salidas del archivo de Bicep. De este modo, es posible que cualquier persona que implemente el archivo no observe que hay algo diferente. Pero este cambio presenta una diferencia significativa en el comportamiento de los recursos, por lo que, a pesar de todo, puede decidir tratarlo como una actualización de versión principal.
También puede optar por usar una estrategia de control de versiones más sencilla, como simplemente usar el número de compilación de la canalización como número de versión. Aunque este enfoque es más fácil de implementar, significa que no se pueden comunicar eficazmente las diferencias entre las versiones con las personas que usan el código.
Versiones y canalizaciones
Cuando publica el código de forma interactiva, por ejemplo, mediante la CLI de Azure, probablemente piense en el número de versión que asignará a la especificación de plantilla o al módulo cuando lo publique. Pero en una canalización de implementación automatizada debe cambiar el enfoque para asignar números de versión. La canalización no puede detectar automáticamente cambios importantes o aconsejar cuándo debe incrementar los números de versión principal o secundaria. Considere detenidamente el control de versiones antes de publicar la especificación de plantilla o el módulo.
Un enfoque consiste en almacenar un archivo de metadatos con el código de Bicep, como se muestra en el diagrama siguiente:
Cada vez que actualice el código de Bicep, actualiza la información de versión en el archivo de metadatos correspondiente. Asegúrese de identificar correctamente los cambios importantes y los no disruptivos para incrementar correctamente los números de versión.
Sugerencia
Si el equipo revisa el código de Bicep mediante solicitudes de incorporación de cambios, pida a los revisores que validen si los cambios en el código requieren cambiar los números de versión principal o secundaria.
Verá cómo puede usar un archivo de metadatos en el ejercicio siguiente.
¿Cuántas canalizaciones crear?
Es habitual crear una colección de especificaciones de plantilla y módulos. A menudo tiene sentido mantener este código en el mismo repositorio de Git.
Mediante el uso de filtros de ruta de acceso en Azure Pipelines, puede crear canalizaciones independientes para cada módulo o especificación de plantilla dentro del repositorio. Este enfoque le ayuda a evitar la publicación de una nueva versión de cada archivo de Bicep dentro del repositorio cada vez que cambie un archivo. Puede usar plantillas de canalización para definir los pasos de la canalización en un archivo centralizado, lo que permite que la canalización de cada módulo y especificación de plantilla se mantenga ligera.
Por ejemplo, supongamos que tiene una estructura de archivos similar a la que se ha ilustrado anteriormente. Puede configurar tres canalizaciones independientes, una para cada archivo de Bicep. Seleccione cada pestaña para ver la definición de canalización correspondiente y su filtro de ruta de acceso:
trigger:
batch: true
branches:
include:
- main
paths:
include:
- 'module-1/**'
stages:
- template: pipeline-templates/publish-module.yml
parameters:
path: 'module-1/main.bicep'
Supongamos que solo cambia el archivo módulo-2/main.bicep. Solo se ejecuta la canalización para el módulo 2. Pero si cambia varios archivos en la misma ejecución, se activarán todas las canalizaciones pertinentes.
Nota:
El enfoque de creación de una canalización para cada uno de los archivos de Bicep reutilizables es sencillo y flexible. Pero puede resultar complicado cuando tiene un gran número de archivos de Bicep, o si no desea mantener canalizaciones independientes para cada módulo y especificación de plantilla.
También puede escribir scripts en la canalización para buscar el código que ha cambiado y publicar solo esos archivos. Este es un enfoque más complejo y está fuera del ámbito de este módulo de Microsoft Learn.
Entornos para código de Bicep reutilizable
Si implementa en Azure mediante Bicep, es habitual usar varios entornos para ayudarle a validar y a probar el código antes de que se publique en un entorno de producción. En módulos de formación anteriores de Microsoft Learn ha aprendido a trabajar con varios entornos desde una canalización de implementación.
Algunas organizaciones aplican los mismos principios a los módulos de Bicep y a las especificaciones de plantilla. Por ejemplo, puede publicar primero nuevas versiones de los módulos en un registro que no sea de producción para que los usuarios de cada módulo puedan probar las versiones nuevas. Después de autorizar los cambios, puede publicar los módulos en el registro de producción de la organización.
Al igual que las implementaciones normales, puede usar trabajos y plantillas de canalización para definir la secuencia de implementación en todos los entornos. En este módulo de Microsoft Learn publicamos en un único entorno para simplificar la canalización.
Cuando consume módulos de un registro o usa una especificación de plantilla como módulo de Bicep, puede usar alias. En lugar de especificar el nombre del registro o la ubicación de la especificación de plantilla cada vez que define un módulo, use su alias.
Mediante el uso de alias puede hacer que el proceso de implementación funcione fácilmente en varios entornos. Por ejemplo, cuando define un módulo puede usar un alias en lugar de un nombre de registro. A continuación, puede diseñar una canalización de implementación para configurar el alias al que se van a asignar:
- Un registro de módulos de desarrollo cuando implemente en un entorno de espacio aislado.
- Un registro de producción cuando implemente en otros entornos.
Nota:
Los alias no se aplican al publicar. Solo funcionan cuando se usan especificaciones de plantilla o módulos dentro de un archivo de Bicep.