Gestión de Despliegue con Git Flow

Cuando trabajamos con diferentes entornos en un proyecto de desarrollo, es crucial contar con una estrategia clara de gestión de ramas y despliegue para evitar conflictos y asegurar un proceso ordenado. En esta entrada, veremos cómo manejar los entornos DEV, PRE, UAT, y PROD utilizando Git Flow, una herramienta poderosa para gestionar el ciclo de vida de las ramas de desarrollo.

Estructura de Entornos

Para entender mejor cómo se relacionan las ramas y los entornos, definimos nuestros 4 entornos principales:

• DEV: Entorno de desarrollo, donde los desarrolladores integran y prueban nuevas funcionalidades.
• PRE: Entorno de preproducción, utilizado por el equipo de QA para pruebas exhaustivas.
• UAT: Entorno de pruebas de aceptación por parte de los usuarios o stakeholders.
• PROD: Entorno de producción, donde se despliega el código final y estable.

Ramas en Git Flow

El flujo de trabajo con Git Flow se basa en las siguientes ramas principales:

• develop: Aquí se integran todas las nuevas funcionalidades, y este código se despliega en DEV.
• release: Una rama temporal que se crea para preparar una versión candidata a ser probada en PRE y UAT.
• main (o master): Es la rama que representa el código de producción, listo para ser desplegado en PROD.
• Feature branches: Ramas temporales creadas desde develop para implementar funcionalidades específicas.

Flujo de Trabajo con Git Flow

1. Desarrollo en DEV (Rama develop)

En el entorno DEV, los desarrolladores trabajan en nuevas funcionalidades. Para ello, crean ramas de feature a partir de develop, donde desarrollan sus tareas de manera aislada.

git checkout develop
git flow feature start nombre-de-la-feature

Cuando la funcionalidad está lista y ha sido probada, se integra de vuelta en develop:

git flow feature finish nombre-de-la-feature

Esta rama develop se despliega en DEV para asegurar que todas las funcionalidades funcionan en conjunto y no hay conflictos.

2. Pruebas en PRE (Rama release)

Una vez que el desarrollo en develop está completo y listo para ser probado más exhaustivamente, se crea una release branch. Esta rama se usa para estabilizar el código y se despliega en PRE para las pruebas de QA.

git flow release start nombre-de-la-release

En PRE, QA se encarga de realizar pruebas exhaustivas. Si se encuentran bugs menores, los corregimos directamente en la rama release. Estos cambios luego se integrarán tanto en develop como en main cuando la release esté lista para producción.

3. Validación en UAT (Rama release)

Después de pasar las pruebas en PRE, la misma rama release se despliega en UAT para ser probada por usuarios finales o stakeholders. Este entorno asegura que el sistema está listo para producción.

Si se encuentran más problemas en UAT, las correcciones también se aplican en la rama release, y se valida nuevamente hasta que todo esté correcto.

4. Despliegue en PROD (Rama main)

Cuando la rama release ha sido aprobada en UAT, se integra en la rama main para preparar el despliegue en PROD. Al finalizar la release, Git Flow se encargará de hacer el merge de release en main y también en develop para mantener ambas ramas sincronizadas.

git flow release finish nombre-de-la-release

Este comando también genera una etiqueta (tag) que marca la versión que se está desplegando en PROD.

Resumen Visual del Flujo:

1. Entorno DEV: Trabajamos en la rama develop y hacemos merge de las feature branches.
2. Entorno PRE (QA): Creamos una release branch desde develop y la desplegamos en PRE para las pruebas de QA.
3. Entorno UAT: La misma release branch se mueve a UAT para ser probada por los usuarios finales.
4. Entorno PROD: Si todo está bien en UAT, la rama release se mergea en main y se despliega en PROD.

¿Qué pasa si hay cambios entre UAT y PROD?

Pero como debemos actuar si entre UAT y PROD tenemos conflictos o cambios.

• Caso ideal: Si no hay cambios entre UAT y PROD, la misma rama release se puede mergear directamente en main para su despliegue.
• Si hay cambios en UAT: Si se hacen ajustes en UAT, estos deben aplicarse en la misma rama release. Luego, puedes finalizar la release y mergearla tanto en main como en develop.

Mejores Prácticas:

1. No trabajar directamente en develop o main:
   • Siempre usa feature branches para trabajar en funcionalidades específicas. Esto facilita el aislamiento del trabajo y evita conflictos tempranos.
2. Usa release branches para estabilización:
   • Crea una rama release para estabilizar el código y corregir errores antes de que llegue a producción. De esta forma, puedes seguir desarrollando en develop mientras QA y los stakeholders prueban la versión candidata.
3. Sincronización de ramas:
   • Cuando una rama release se ha finalizado, Git Flow hará el merge en main y develop automáticamente. Esto asegura que los nuevos cambios están siempre sincronizados.
4. Etiquetas de versiones:
   • Usa las etiquetas (tags) generadas por Git Flow para mantener un control de versiones claro en PROD.

Conclusión

Este flujo de trabajo garantiza una gestión eficiente del código, donde cada entorno tiene un propósito específico y las ramas de Git están alineadas con los ciclos de desarrollo, pruebas y despliegue. Usando Git Flow, puedes mantener un código limpio, bien organizado y con un ciclo de despliegue controlado, minimizando el riesgo de problemas en producción.

Artículos de interés:

Recursos Relacionados:

• Documentación Git Flow

Iván Portillo

Desarrollador de software con más de 7 años de experiencia, especializado en desarrollo web y backend. Con habilidades demostradas en PHP, Laravel, Symfony, y una amplia gama de tecnologías modernas. Apasionado por el diseño y desarrollo de software.