Guía para un mejor flujo de git para entornos automatizados

Cover

En 2010, Vincent Driessen escribió “A successful Git branching model”. Proporcionó un gran modelo para desarrollar aplicaciones en un repositorio organizado y siguiendo los conceptos de control de versiones semánticas, por lo que los equipos pudieron planificar lanzamientos, implementar funciones y revisiones sabiendo y reflejando los cambios en el repositorio GIT de manera consistente.

En Swapps, confiamos mucho en este método durante varios años, y rápidamente descubrimos que este método funciona principalmente cuando estamos trabajando en un proyecto con lanzamientos planificados y un equipo dedicado. En nuestro caso, trabajamos en diferentes proyectos al mismo tiempo, algunos de ellos están en etapa de desarrollo y otros están en modo de mantenimiento. Este enfoque se explica en un artículo anterior: “Sea menos ágil para ser más ágil”.

Las debilidades del Flujo Git

  • Muchas ramas.
  • Los desarrolladores olvidan actualizar las ramas de lanzamiento.
  • La rama Develop no siempre está actualizada con master.
  • La convención de nombres puede ser confusa: Feature vs hotfix.

Hay artículos que dicen que Git Flow puede ser dañino “Git Flow can be harmful” y proponen una alternativa más sencilla. Entiendo las razones y también me gusta la sencillez, pero ¿a qué precio? Si un enfoque complica un proyecto, es posible que debamos reconsiderarlo.

El riesgo de la sobresimplificaicón

Gitlab y Github han dado alternativas simplificadas donde proponen eliminar por completo las ramas de release y hotfix para tener solo una rama master y ramas de features todo el tiempo. Eso funciona bien para proyectos sin trabajo paralelo y características muy específicas y aisladas, pero en la vida real es muy común trabajar en problemas relacionados (por ejemplo, un sprint ágil) y necesitas una rama intermedia (la próxima rama de release o la de develop) para probar todo junto antes de implementarlo.

Para resolver eso, eliminan la equivalencia de master y producción y configuran manualmente las etiquetas o simplemente implementan manualmente (Github Flow) o incluso peor, crean una rama adicional para la producción (Gitlab Flow).

No sé qué piensas, pero creo que no vale la pena perder la automatización o agregar una rama para algo que ya está resuelto y estandarizado.

En otro artículo, mostraremos cómo automatizamos la implementación y la creación de etiquetas en función de nuestro flujo de Git.

Un nuevo Flujo Git

Hemos propuesto un enfoque más simple donde mantenemos las ventajas del Flujo Git original, el repositorio permanece estructurado, el flujo de trabajo se simplifica un poco y automatizamos lo repetitivo.

La clave es tener la posibilidad de tener un enfoque más simple como el propuesto por Github, pero aún tener la opción de tener lanzamientos con varias características cuando sea necesario.

Master sigue siendo el rey

Master significa producción, y es la rama conectada directamente al entorno donde reside la aplicación en vivo, por lo que tenemos nuestro flujo de trabajo de integración continua configurado para implementarse automáticamente en cualquier cambio en master

Se le permite crear features o ramas de hotfix basadas en master y luego crear pull requests para master, para que se implemente automáticamente.

Definición de Versiones

Las versiones son importantes porque agrupan el historial del desarrollo en términos de lanzamientos, por lo que tienes en tu repositorio cómo y cuándo se implementó el código. ¿Ves por qué es importante vincular lanzamientos e implementaciones?

Al seguir el control de versiones de SEM, siempre comenzamos con una versión menor definida, Ej. 0.1,1.0. Entonces, dependiendo de si estamos creando un pull request de una función a master o de una rama de lanzamiento a master, debemos definir la versión correcta para usar:

  • Feature a master: parche.
  • Lanzamiento a master: versión menor o mayor.

Para los siguientes ejemplos, asumiremos que comenzamos nuestro proyecto con la versión 0.1.0.

El enfoque más simple: Modo mantenimiento

Esto es especialmente útil para proyectos en modo de mantenimiento. Simplemente cree todas sus ramas de funciones basadas en master y creará parches para su aplicación.

Ejemplo:

  • Trabajamos en feature1, feature2, feature3 para nuestro proyecto.
  • Feature1 producirá la versión 0.1.1
  • Feature2 producirá la versión 0.1.2
  • Feature3 producirá la versión 0.1.3

En un contexto tradicional, habríamos llamado esas funciones como hotfixes, pero mantengamos las cosas simples en la convención de nomenclatura por ahora.

Lanzamientos a largo plazo con un conjunto de features

Se utiliza cuando planea implementar un conjunto de funciones, por lo que crea una rama de versión basada en la versión master y todas sus features se basarán en la versión específica.

Cuando sea el momento de lanzar todas las features, creará un pull request desde la rama de lanzamiento a master.

Ejemplo:

  • La versión actual en producción es 0.1.0.
  • Hemos planeado trabajar en feature1, feature2 and feature3 que se lanzarán en una semana.
  • La versión del siguiente lanzamiento será 0.2.
  • Creamos una nueva rama release/0.2 basada en master.
  • Feature1 es fusionada a release/0.2 sin versión.
  • Feature2 es fusionada a release/0.2 sin versión.
  • Feature2 es fusionada a release/0.2 sin versión. 
  • Pull request de release/0.2 a master.
  • release/0.2 es fusionado a master produciendo la nueva versión 0.2.

Trabajando en hotfixes mientras estamos en medio de un desarrollo de lanzamiento

Como pudo ver en los ejemplos anteriores, administramos las características de una versión en una versión de rama separada / x.x, mientras que los hotfixes se administran a través de parches y se fusionan directamente con master. Significa que podemos trabajar en hotfixes mientras estamos trabajando en una rama de lanzamiento sin problemas.

Tenga cuidado: ¡Mantenga actualizada la rama de lanzamiento!

Esta es una de las desventajas del enfoque de Git Flow. Somos humanos y nos olvidamos de cosas como actualizar la rama de lanzamiento con los cambios más recientes en master. Si no quiere tener problemas, necesita encontrar una manera de mantener la rama de lanzamiento siempre actualizada.

Para concluir…

Hemos proporcionado una alternativa al flujo estándar de Git que pretende obtener lo mejor de ambos mundos: robusto y simple, y explicamos por qué los enfoques proporcionados por Github y Gitlab no se ajustan a nuestras necesidades. Como siempre, puede utilizar cualquier enfoque que funcione mejor para usted. Lo más importante es que usted y su equipo comprendan el flujo de trabajo y mantengan la coherencia para que cualquier otro visor de repositorios futuro pueda entender.