A continuación vamos a adentraremos en una materia que, aunque pueda parecer básica, en ocasiones da muchos dolores de cabeza a los equipos de desarrollo. Analizaremos algunas de las estrategias de branching en GitHub más conocidas y pondremos en una balanza cada una de ellas.
¿Qué entendemos por una git branching strategy? Con este concepto nos referimos a la metodología de creación y actualización de ramas git que implementaremos en la operativa de nuestro equipo.
¿Porqué es necesaria una estrategia de git branching? El principal motivo de establecer una estrategia en equipo es poder efectuar los cambios necesarios que el proyecto demanda de la manera más segura y organizada.
Eso no significa que tengamos que ser nosotros mismos los que inventemos estas estrategias. Por suerte, existe mucha bibliografía al respecto y hoy veremos algunas de las más famosas. Trataremos de profundizar en cada una de ellas para que podamos compararlas entre sí fácilmente y elegir cual nos conviene más para nuestro caso de uso.
Trunk-Based Development
Definición
Esta estrategia de branching es muy curiosa puesto que no requiere el uso de ramas. En este caso, los desarrolladores integran sus cambios a la rama tronco (suele ser main o master), de ahí su nombre, una vez al día.
Pero, ¡cuidado! Esta rama central debe estar lista para su despliegue en cualquier momento.
El planteamiento detrás de esta estrategia es crear un espacio de despliegue super ágil y rápido. En este sentido, los desarrolladores se ven obligados a realizar commits más pequeños y subirlos de manera continua. El principal objetivo de la estrategia Trunk-Based Development es eliminar las ramas de larga duración. Como curiosidad, cabe señalar que el nombre de trunk-based proviene de la idea de que el proyecto debe ser como un árbol. La parte central, o el tronco, es lo que debe ser más grande. Por otro lado, las ramas serían pequeñas desviaciones del desarrollo que hay que podar.
Como podemos ver, esta metodología se basa en el despliegue continuo como piedra central. Pero, en un escenario de tanto despliegue, ¿cómo se versionan los productos? Aquí es donde entran las ramas de release, que sirven para estabilizar el código sin frenar el desarrollo de la rama trunk.
Imaginemos que queremos lanzar una versión mensual de nuestro producto. Unos días antes del despliegue, y para no interferir en dicha release, crearíamos la nueva rama de release que saldría del trunk. Éste sería un lugar estable donde probar y testear la release, protegiéndola del despliegue continuo al que se ve sometida la rama trunk. Una vez se trabaja en release, se ha podido avanzar sobre ella y generar algún commit nuevo que posteriormente será llevado a la rama principal con un cherry pick.
Por último, hay que destacar que esta metodología se ve muy ligada al concepto de features flag o indicadores de características. Esta condición permite que se pueda habilitar y deshabilitar una característica específica. De esta forma, se puede subir el código nuevo de dicha característica a pesar de estar incompleto, sabiendo que la característica estará deshabilitada.
Si tienes interés en investigar más acerca de esta metodología, te recomiendo visitar esta introducción a trunk based development.
Enfoque
- En mi opinión, esta estrategia está orientada a equipos pequeños. Principalmente, porque si en nuestro equipo tenemos 10 desarrolladores trabajando en la misma plataforma, puede ser bastante caótico el hecho de subir un commit listo para producción.
- También está orientada a procesos donde prima la puesta en producción y la velocidad. Desde mi punto de vista, no tiene mucho sentido en productos que necesitan la máxima robustez y seguridad. Esto no significa que no pueda ser una metodología segura. Hace falta mucho trabajo para mantener la capa de seguridad y, muchas veces, no se dispone ni de los conocimientos ni del tiempo necesario para ello.
- Desarrollo de un producto para un quick kick.
Ventajas
- Es muy rápida y permite reducir la distancia entre los miembros del equipo. Todos van alineados y genera iteraciones entre ellos muy cortas.
- Menos conflictos que en otras metodologías.
- Eliminación de las ramas infinitas que no terminan de fusionarse nunca.
- Un histórico de cambios muy limpio y sencillo de leer.
Inconvenientes
- Requiere un equipo muy maduro y, desde mi punto de vista, con mucha experiencia para que se aplique correctamente.
- Es necesario un muy buen sistema de CI/CD.
- Ausencia de entornos de preproducción. Se puede conseguir un entorno de PRE, pero habría que hacer un muy buen trabajo de Devops. Se haría mediante features, lo que puede ser un beneficio ya que no se mezclan cambios en los que cada uno de nosotros esté trabajando. Sin embargo, también añade complejidad al sistema.
- En mi opinión, el hecho de tener que mantener el feature flags es un gran inconveniente. Siempre he pensado que puede ser una fuente de errores o un overhead en la complejidad del sistema que no estaría dispuesto a pagar por ninguna metodología.
GitHub Flow
Definición
Esta metodología, al igual que la anterior, se basa en una rama principal sobre la cual vamos a sacar nuestras features. Esto es muy importante porque en GitHub Flow se pone mucho en valor la confianza que aporta la rama principal, en nuestro caso, master. Una vez que sacamos una feature branch, estaremos trabajando en dicha feature hasta terminarla. En el momento en el que la terminemos, podremos desplegar el último commit o estado de mi rama feature a producción.
Esta aproximación nos permite asegurarnos de que cuando desplegamos una feature, como lo hacemos directamente desde la propia rama, no estaremos desplegando nunca otras ramas que puedan encontrarse en nuestra rama principal fusionada.
Como te puedes imaginar, este sistema convive muy bien con entornos de despliegue continuo. Lo que se busca es cierta agilidad a la hora de desplegar. Además, y puesto que estamos haciéndolo directamente desde nuestra feature branch, también cierta capacidad también de rollout. La forma en la que siempre podremos hacer rollback es volviendo a la fuente de la verdad, que en nuestro caso sería master.
Cuando estamos 100% seguros de que nuestra feature está totalmente estable y desplegada, se fusionará con master. Esto hace que lo que llega a master siempre sea muy confiable.
Ahora bien, los entornos previos a producción también saldrán de la feature branch. De esta forma, mi entorno de operaciones deberá ser capaz de cambiar entre branches para poder probar los cambios antes del despliegue en producción.
Enfoque
- Equipos de tamaño variable, con experiencia en Continous Deployment.
Ventajas
- Mantiene un histórico muy sencillo y limpio.
- La rama master siempre será muy robusta. Además, permite tener un espacio de producción muy seguro con el rollback a master.
- Sencillez de ramas, no se generan mucho lío de ramas ni conflictos al salir todas del mismo punto.
Inconvenientes
- Es necesario tener un muy buen equipo de operaciones. Esta metodología se apoya en gran medida en los sistemas de rollout, rollback y CI/CD. Por este motivo, requiere bastantes conocimientos en operaciones.
GitFlow
Definición
Seguramente, es la metodología más conocida de todas y también la más completa. Aunque hay muchos detractores, lo cual es perfectamente comprensible, esta metodología se basa en dos tipos principales de branches. Por un lado, las ramas de despliegue y, por otro, las de desarrollo.
Empecemos hablando de las ramas de desarrollo. Todas las ramas de desarrollo salen de una rama fija llamada develop. Esta rama recoge todos los commits de desarrollo del resto de ramas feature, que en su nacimiento saldrán de ella. Posteriormente, se fusionarán de vuelta cuando se hayan terminado.
La rama de desarrollo podrá ejercer de mapeo de preproducción, siendo desplegado en dicho entorno todo commit que llegue a desarrollo. La condición última es que no se sube un commit directamente en esta rama, sino que los cambios llegarán de la fusión del pull request de una rama feature con develop.
Por otro lado, existen las ramas de despliegue, que serían las ramas release, hotfix y master. Desde develop, que actúa como preproducción, y una vez testeados nuestros cambios en dicho entorno, nacerá una rama release-x.x.x que impulsará en cambio hacia producción. Estas ramas serán las que estabilizarán un despliegue específico en el tiempo y, a su vez, permitirán materializar los cambios en un entorno de staging.
Durante este proceso de release probaremos los cambios en staging y, en caso de necesitar realizar cualquier cambio, lo haremos directamente en la rama de release. Una vez seguros de que la rama está estable, podremos realizar un pull request para subir los cambios a master que será mapeado con el entorno de producción. Este entorno de producción ha pasado ya varios cortafuegos, por los que no debería contener ningún bug. No obstante, en caso de que se produjera alguno, la metodología contempla un sistema para corregirlos.
Si tuviéramos que realizar un cambio de urgencia sobre producción y no queremos pasar por toda la liturgia que exige dicho cambio en esta metodología, podremos sacar una rama llamada hotfix desde master para aplicar el cambio y volver a fusionarse mediante pull request a master.
Este sistema genera dos puntos de generación de código. Por un lado, tenemos las ramas features y, por otr, tenemos hotfix y las ramas release, que tendrá que terminar fusionándose con develop para hacer conocedor de dichos cambios al resto de desarrollos.
Si te interesa profundizar en esta metodológica, puedes visitar este enlace de git-flow cheatsheet o este otro de flujo de trabajo de GitFlow.
Enfoque
- Equipos con proyectos de tamaño mediano o grande, basados en robustez e iteraciones más largas.
Ventajas
- Sólido y robusto en despliegues de múltiples versiones.
- Permite tener más de un entorno antes de producción.
- Ideal para desarrollos largos.
Inconvenientes
- Complejo para proyectos ágiles y rápidos.
- El entramado de ramas ralentiza la puesta en producción.
- Es más propenso a conflictos respecto a otras metodologías, debido a que los commits vienen de puntos diferentes.
Conclusión
Las estrategias de branching en Git ofrecen desarrolladores una metodología para gestionar el flujo de trabajo y mantener la estabilidad del código en producción. Trunk-Based Development, GitHub Flow y GitFlow destacan como algunas de las más utilizadas para equipos con diferente perfil.
Cada estrategia tiene ventajas y desventajas claras que impactan en la rapidez, la organización y la complejidad de la gestión del día a día. Trunk-Based Development es ágil y facilita el desarrollo continuo, aunque requiere un equipo experimentado y una excelente implementación de CI/CD. GitHub Flow, en cambio, es más sencillo y permite cambios rápidos, pero también depende de un fuerte respaldo del equipo de operaciones. Por su parte, GitFlow proporciona un enfoque estructurado y seguro para equipos grandes o desarrollos largos, aunque puede ralentizar la integración en entornos ágiles.
No obstante, no solo existen estas estrategias. En otros espacios exploraremos algunas otras que han quedado pendiente. Hasta entonces, ¡disfruta del desarrollo!
¡Eso es todo! Si este artículo te ha resultado interesante, te animamos a visitar la categoría Software para ver otros posts relacionados. ¡Hasta pronto!
