Diseñar un flujo de trabajo y una 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 los flujos de trabajo 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.
El flujo de trabajo también puede establecer automáticamente el número de revisión. El número de ejecución del flujo de trabajo 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 que alguien más ha publicado. El módulo tiene 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 ejecución del flujo de trabajo 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 cualquier persona que use el código.
Versiones y flujos de trabajo
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 un flujo de trabajo de implementación automatizado debe cambiar el enfoque para asignar números de versión. El flujo de trabajo 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ántos flujos de trabajo?
Es habitual crear una colección de especificaciones de plantilla y módulos. A menudo tiene sentido mantenerlos en el mismo repositorio de Git.
Mediante el uso de filtros de ruta de acceso en Acciones de GitHub, puede crear flujos de trabajo 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 flujos de trabajo reutilizables para definir los pasos del flujo de trabajo en un archivo centralizado, lo que permite que el flujo de trabajo de cada módulo y especificación de plantilla se mantenga ligero.
Por ejemplo, supongamos que tiene una estructura de archivos similar a la que se ha ilustrado anteriormente. Puede configurar tres flujos de trabajo independientes, uno para cada archivo de Bicep. Seleccione cada pestaña para ver la definición de flujo de trabajo correspondiente y su filtro de ruta de acceso:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Supongamos que solo cambia el archivo módulo-2/main.bicep. Solo se ejecuta el flujo de trabajo del módulo 2. Pero si cambia varios archivos en la misma ejecución, se activarán todos los flujos de trabajo pertinentes.
Nota:
El enfoque de crear un flujo de trabajo 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 flujos de trabajo independientes para cada módulo y especificación de plantilla.
También puede escribir scripts en el flujo de trabajo 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 formación de Microsoft Learn.
Entornos para código de Bicep reutilizable
Al implementar en Azure mediante Bicep, es habitual usar varios entornos para ayudarle a validar y probar el código antes de publicar el código en un entorno de producción. En módulos de formación anteriores de Microsoft Learn ha aprendido a trabajar con varios entornos desde un flujo de trabajo 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. A continuación, una vez las hayan aprobado, 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 flujos de trabajo reutilizables para definir la secuencia de implementación en los entornos. En este módulo de formación de Microsoft Learn publicamos en un único entorno para simplificar el flujo de trabajo.
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 en varios entornos. Por ejemplo, cuando define un módulo puede usar un alias en lugar de un nombre del registro. A continuación, puede diseñar un flujo de trabajo de implementación para configurar el alias al que se le van a asignar:
- Un registro de módulos de desarrollo al implementar 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.