NOTAS WEB
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
(omaster
): 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:
- Entorno DEV: Trabajamos en la rama
develop
y hacemos merge de las feature branches. - Entorno PRE (QA): Creamos una release branch desde
develop
y la desplegamos en PRE para las pruebas de QA. - Entorno UAT: La misma release branch se mueve a UAT para ser probada por los usuarios finales.
- Entorno PROD: Si todo está bien en UAT, la rama
release
se mergea enmain
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 enmain
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 endevelop
.
Mejores Prácticas:
- No trabajar directamente en
develop
omain
:- Siempre usa feature branches para trabajar en funcionalidades específicas. Esto facilita el aislamiento del trabajo y evita conflictos tempranos.
- 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 endevelop
mientras QA y los stakeholders prueban la versión candidata.
- Crea una rama
- Sincronización de ramas:
- Cuando una rama
release
se ha finalizado, Git Flow hará el merge enmain
ydevelop
automáticamente. Esto asegura que los nuevos cambios están siempre sincronizados.
- Cuando una rama
- Etiquetas de versiones:
- Usa las etiquetas (
tags
) generadas por Git Flow para mantener un control de versiones claro en PROD.
- Usa las etiquetas (
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:
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.