Información sobre la bifurcación
Al compilar plantillas de Bicep y trabajar en un repositorio de Git, todos los cambios del equipo se combinan finalmente en la rama principal del repositorio. Es importante proteger la rama principal para que no se implementen cambios no deseados en el entorno de producción. Sin embargo, también quiere que los colaboradores puedan trabajar de forma flexible, colaborar con el equipo y probar ideas fácilmente.
En esta unidad, obtendrá información sobre las estrategias de bifurcación y sobre cómo proteger la rama principal. También aprenderá a configurar un proceso de revisión para las ramas.
¿Por qué quiere proteger la rama principal?
La rama principal es el origen de lo que se implementa en los entornos de Azure. Para muchas soluciones, tendrá varios entornos, como los de desarrollo, control de calidad (QA) y producción. En otros escenarios, es posible que solo tenga un entorno de producción. Independientemente del número de entornos que use, la rama principal es la rama a la que contribuyen los miembros del equipo. En última instancia, sus cambios finalizan en la rama principal.
Un proceso típico puede ser parecido al siguiente:
- Un miembro del equipo clona el repositorio compartido.
- Realiza cambios locales en una rama de su propia copia local del repositorio.
- Cuando termine con sus cambios, los combinará en la rama principal del repositorio local.
- Inserta estos cambios en la rama principal del repositorio remoto.
- En algunos escenarios, la inserción del repositorio remoto desencadena una canalización automatizada para comprobar, probar e implementar el código. Obtendrá más información sobre las canalizaciones en otros módulos de Microsoft Learn.
En el siguiente diagrama se muestra este proceso:
Supongamos que los cambios del miembro del equipo introdujeron un error sutil. Una vez que se ejecuta el proceso completo, el error se encuentra ahora en la rama principal del proyecto y se implementa en producción. Es posible que no lo detecte hasta que intente implementarlo y obtenga un error. O bien, para otros tipos de errores, la implementación podría tener éxito, pero provocar problemas sutiles más adelante.
En otro escenario, suponga que un miembro del equipo está trabajando en una característica e inserta la mitad del trabajo finalizado de la característica en la rama principal del repositorio compartido. Ahora tiene cambios en la rama principal que no están terminados o probados. Estos cambios probablemente no deberían implementarse en su entorno de producción. Es posible que las implementaciones en producción deban bloquearse hasta que la característica esté acabada. Si las características recién finalizadas están en la rama principal, es posible que no pueda implementarlas en los clientes.
Sugerencia
Estos problemas son muy difíciles para los equipos grandes, en los que varias personas contribuyen al mismo código, pero la orientación de este módulo es valiosa en cuanto se colabora con más de una persona. La guía es valiosa incluso cuando solo se trabaja en un proyecto y se trabaja en varias características al mismo tiempo.
Una mejor manera de trabajar es mantener los cambios separados mientras trabaja en ellos. Luego, puede hacer que otro miembro del equipo revise los cambios antes de que se combinen en la rama principal del repositorio compartido del equipo. Este proceso ayuda al equipo a tomar una decisión fundamentada sobre el cambio antes de aprobar su combinación.
Ramas de características
Una rama de características indica un nuevo trabajo que se está iniciando. El trabajo podría ser un cambio en la configuración de un recurso definido en el archivo Bicep o un nuevo conjunto de recursos que debe implementarse. Cada vez que se inicia un nuevo trabajo, se crea una rama de características nueva.
Una rama de características se crea desde la rama principal. Al crear una rama, se asegurará de que empieza desde el estado actual del entorno de Azure. A continuación, realice todos los cambios necesarios.
Dado que todos los cambios de código se confirman en la rama de características, no interferirán con la rama principal del repositorio. Si otra persona del equipo necesita realizar un cambio urgente en la rama principal, puede hacerlo en otra rama de características que sea independiente de la de usted.
También puede colaborar en ramas de características. Al publicar e insertar la rama de características en el repositorio compartido, usted y los miembros del equipo pueden trabajar juntos en un cambio. También puede entregar una característica a otra persona para que la complete cuando usted se vaya de vacaciones.
Actualización de las ramas de características
Mientras la rama de características está en curso, es posible que otras características se combinen con la rama principal del repositorio. Esto significa que la rama de características y la rama principal del proyecto se separarán. Cuanto más se separen, más difícil será volver a combinar las dos ramas en un punto posterior y más conflictos de combinación podría encontrar.
Debe actualizar la rama de características periódicamente para incorporar los cambios realizados en la rama principal del repositorio. También es una buena idea actualizar la rama de características antes de empezar a combinar la rama de características de nuevo en la rama principal. De este modo, se asegura de que los nuevos cambios se puedan combinar fácilmente en la rama principal.
Sugerencia
Combine la rama principal con frecuencia en la rama de características.
Uso de ramas pequeñas y de corta duración
Objetivo de las ramas de características de corta duración. Este enfoque le ayuda a evitar conflictos de combinación al reducir la cantidad de tiempo que las ramas podrían salir de la sincronización. Este enfoque también facilita a sus compañeros comprender los cambios realizados, lo que resulta útil cuando necesita que alguien revise los cambios.
Divida grandes fragmentos de trabajo en partes más pequeñas y cree una rama de características para cada una. Cuanto mayor sea la característica, más tiempo necesitará alguien para trabajar en ella y más tiempo vivirá la rama de características. Puede implementar los cambios más pequeños en producción a medida que combina cada rama de características y crear gradualmente el trabajo más amplio.
Imagine que va a realizar algunos cambios en un conjunto de código Bicep. Va a mover algunas definiciones de recursos a módulos. También necesita agregar algunos recursos nuevos a sus archivos Bicep. Puede ser una buena idea realizar primero toda la refactorización del módulo, en su propia rama. Tras la combinación de los módulos, puede empezar a trabajar en las adiciones a los archivos Bicep. Al separar los cambios, se mantiene cada cambio (y su rama) en un tamaño pequeño y fácil de entender.
Cuando se trabaja de esta manera, puede resultar útil usar la palabra clave if para deshabilitar la implementación de recursos hasta que estén listos. El código de ejemplo siguiente muestra cómo usaría la palabra clave if para crear un archivo Bicep que define una cuenta de almacenamiento, pero deshabilita la implementación de dicha cuenta hasta que haya terminado con todos los cambios.
@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Premium_LRS'
}
}
Puede usar parámetros para especificar valores diferentes para la variable storageAccountReady en entornos diferentes. Por ejemplo, puede establecer el valor del parámetro en true para el entorno de prueba y false para el entorno de producción. De este modo, puede probar la nueva cuenta de almacenamiento en el entorno de prueba.
Nota:
Cuando llegue el momento de habilitar la característica en producción, recuerde que debe realizar los pasos siguientes para que el cambio sea efectivo:
- Cambiar el valor del parámetro.
- Volver a implementar el archivo de Bicep.
Combinación de ramas de características
Cuando haya terminado de trabajar en una rama de características, deberá combinarla en la rama principal del repositorio. Es una buena práctica revisar los cambios realizados en la rama de características antes de combinar. Las solicitudes de extracción le permiten revisar el código. Más adelante en este módulo nos centraremos en las solicitudes de extracción.
Protecciones de rama
En GitHub, puede configurar las protecciones de rama para la rama principal del repositorio compartido. Las protecciones de rama aplican reglas como las siguientes:
- No se puede combinar ningún cambio en la rama principal excepto a través de una solicitud de extracción.
- Los cambios deben ser revisados por al menos otras dos personas.
Si alguien intenta insertar una confirmación directamente en una rama protegida, se producirá un error en la inserción. Aprenderá a aplicar protecciones de rama en la siguiente unidad.
Directivas de rama
En Azure DevOps, puede configurar directivas de rama para la rama principal del repositorio compartido. Las directivas de rama aplican reglas como las siguientes:
- No se puede combinar ningún cambio en la rama principal excepto a través de una solicitud de extracción.
- Los cambios deben ser revisados por al menos otras dos personas.
Si alguien intenta insertar una confirmación directamente en una rama protegida, se producirá un error en la inserción. Aprenderá a aplicar directivas de rama en la unidad siguiente.
Otras estrategias de bifurcación
Al colaborar en el código Bicep, puede usar diferentes estrategias de bifurcación. Cada estrategia de bifurcación tiene ventajas e inconvenientes.
El proceso que ha aprendido hasta ahora es una versión de la estrategia de desarrollo troncal. En esta estrategia de bifurcación, el trabajo se realiza en ramas de características de corta duración y, posteriormente, se combina en una sola rama principal. Puede implementar automáticamente el contenido de la rama principal del repositorio compartido en producción cada vez que se combina un cambio, o bien podría procesar por lotes los cambios y publicarlos según una programación, como cada semana. El desarrollo troncal es fácil de entender y permite la colaboración sin mucha sobrecarga de trabajo.
Algunos equipos separan el trabajo que han completado del trabajo que han implementado en producción. Utilizan una rama de desarrollo de larga duración como destino para combinar sus ramas de características. Combinan la rama de desarrollo con la rama principal cuando publican cambios en producción.
Algunas otras estrategias de bifurcación requieren que cree ramas de versión. Cuando tenga un conjunto de cambios listos para implementarse en producción, cree una rama de versión con los cambios que se implementarán. Estas estrategias pueden tener sentido al implementar la infraestructura de Azure con una periodicidad regular o al integrar los cambios con muchos otros equipos.
Otras estrategias de bifurcación incluyen Gitflow, GitHub Flow y GitLab Flow. Algunos equipos usan GitHub Flow o GitLab Flow porque permite separar el trabajo de distintos equipos, además de separar las correcciones urgentes de errores de otros cambios. Estos procesos también pueden permitirle separar las confirmaciones en distintas versiones de la solución, lo cual se denomina selección exclusiva. Sin embargo, requieren más administración para asegurarse de que los cambios son compatibles entre sí. En la sección Resumen de este módulo se proporcionan vínculos a más información sobre estas estrategias de bifurcación.
La estrategia de bifurcación adecuada para su equipo depende de la forma en que el equipo funciona, colabora y crea versiones de sus cambios. Es una buena idea comenzar desde un proceso sencillo, como el desarrollo troncal. Si observa que el equipo no puede trabajar de forma eficaz mediante este proceso, introduzca gradualmente otras capas de bifurcación o adopte una estrategia de bifurcación, pero tenga en cuenta que a medida que agrega más ramas, la administración del repositorio se vuelve más compleja.
Sugerencia
Independientemente de la estrategia de bifurcación que use, es bueno usar directivas de rama para proteger la rama principal y usar solicitudes de extracción para revisar los cambios. Otras estrategias de bifurcación también presentan ramas importantes que debe proteger.
En este módulo se usa el desarrollo troncal con ramas de características, ya que es fácil de usar.