Estrategias de ramificación para la IaC - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Estrategias de ramificación para la IaC

La metodología Git típica usa una rama base troncal principal (por ejemplomain) para producción, una rama de desarrollo y ramas de características. Muchas organizaciones adoptan al instante este mismo diseño de infraestructura como código (IaC). Sin embargo, la metodología Git no es directamente compatible con los patrones de diseño de infraestructura comunes. Tenga en cuenta los siguientes puntos:

  • Las aplicaciones tienen varios entornos.

    • Entre los ejemplos de entornos se incluyen el entorno aislado, el desarrollo, la puesta en escena y la producción.

  • Los entornos no están estrechamente acoplados.

    • La producción suele ir estrechamente unida a una implementación provisional exitosa.

    • La producción y la puesta en escena suelen estar completamente desvinculadas del entorno de desarrollo.

    • Por lo general, el desarrollo está completamente desvinculado del entorno sandbox.

  • Cada aplicación tiene su propio conjunto de estándares de entorno.

    • Muchas aplicaciones no utilizan un entorno sandbox.

    • Algunas aplicaciones no requieren un entorno provisional, sino que utilizan una estrategia de despliegue azul/verde.

Imagine un escenario en el que un repositorio de aplicaciones ofrece tres entornos que utilizan una metodología basada en enlaces troncales. El entorno de desarrollo está vinculado a la develop sucursal, el almacenamiento provisional a la staging sucursal y la producción a la sucursal. main Para esta aplicación, se requiere una nueva función para conectar una pasarela de transporte a la solución, que está gestionada por otro equipo y repositorio. Un desarrollador escribe el código de infraestructura en una rama de funciones y lo fusiona con la develop rama cuando está listo. Todo parece estar bien.

Sin embargo, surge un desafío. Otro desarrollador tiene una historia de usuario independiente para una función distinta, la escribe en una rama de funciones y la fusiona con la develop rama. La segunda función ya está lista para incorporarse a la puesta en escena y la producción. Sin embargo, la función Transit Gateway original no está lista debido a un criterio de riesgo de la organización. Ahora todas las funciones están bloqueadas, desde la promoción hasta la producción, y el código de la aplicación está prácticamente congelado o roto.

En este escenario, considere las siguientes posibles soluciones:

  • La solución más común: aumentar la repetición del código (reducir el DRY) en las ubicaciones específicas de la estructura de código mediante la creación de ./environments carpetas independientes en el repositorio. Esto permite que el código de los entornos esté en el mismo repositorio, pero desacoplado.

  • Configure un proceso de CI/CD con una gestión compleja de variables.

  • Separe los entornos en repositorios separados.

  • La solución menos común: utilice varias ramas troncales.