Estrategias de Branching

Una "estrategia de branching" es un conjunto de reglas que un equipo de desarrollo de software acuerda seguir, en lo que respecta al uso del sistema de versionado elegido, como por ejemplo GitLab, GitHub, etc. Estas reglas definen como un equipo utiliza los branches para lograr un proceso de desarrollo concurrente, a través de un conjunto de reglas y convenciones que establecen:

• ¿Cuándo se debe crear un branch?
• ¿De qué otro branch deben derivarse el nuevo branch?
• ¿Cuándo se debe hacer merge?
• ¿Y a qué branch debería hacer el merge?

El objetivo de cualquier estrategia de branching es, permitir que los miembros del equipo que trabajan en la misma pieza de código fuente no afecten su código los unos a los otros. Es decir son las reglas que les permite. a un equipo de desarrollo, trabajar en forma colaborativa sin interferirse el trabajo entre ellos.

El tener definida una estrategia de branching, y su correcto cumplimiento, garantiza que todos los miembros del equipo sigan el mismo proceso para realizar cambios en el código fuente. La estrategia correcta mejora la colaboración, la eficiencia y la precisión en el proceso de entrega de software, mientras que la estrategia incorrecta (o ninguna estrategia) o el no cumplimiento de la definida, conduce a muchos errores y problemas de integración, que se traducen en horas de trabajo, mucho esfuerzo y sobre todo pérdida de tiempo lo que además conlleva asociada una perdida de dinero. 

Por lo tanto, una estrategia de branching debe buscar:

• Permitir optimizar la productividad de cada miembro del equipo.
• Habilitar el desarrollo en paralelo.
• Permitir releases estructurados y planificados.
• Evolucionar y adaptarse a los cambios que se realizan a diario en el código.
• Permitir múltiples versiones de software.

Se puede decir entonces que una estrategia de branching define el proceso de desarrollo o flujo de trabajo que el equipo debe seguir en el día a día para, garantizar un trabajo eficiente y un software de calidad.

Existen varias estrategias ya definidas y pueden existir tantas como equipo de desarrollo haya, en este artículo vamos a analizar las más populares basadas en branches o ramas.

Cabe destacar que definir una estrategia de branching es el primer paso de la definición de un proceso de desarrollo, el mismo debe completarse con las definiciones del proceso de CI/CD a seguir. Es decir, cuando y como se debe deployar el software generado para cada uno de los ambientes definidos, y que procesos estarán automatizados y cuáles no.

Estrategias más populares 

Dentro del mundo git, que es el sistema de versionado de código por excelencia en la actualidad, las estrategias más populares son las basadas en branches o ramas. Este tipo de estrategias permite a los desarrolladores crear una rama por cada desarrollo o tarea específica. Por ejemplo, se podrá crear un branch por cada requerimiento, bugs o historia de usuario, lo que da más independencia y autonomía a los desarrolladores, ya que al trabajar cada uno en su propio branch, les permite trabajar su código por separado, que luego será integrado con el resto del código generado, siguiendo el proceso que se haya establecido.

Entre las estrategias más utilizadas se encuentran las siguientes:

GitFlow

Es la estrategia más utilizada y fue creada en 2010 por Vincent Driessen [1] y está pensada para proyectos que tienen entregables y ciclos de desarrollo bien definidos. Es decir, para proyectos que tienen un ciclo de entregas prograrmadas.     

GitFlow está basado principalmente en dos branches que tienen una vida infinita:

• master ( o main): contiene el código de producción.
• develop: contiene el código de pre-producción. Cuando un desarrollador finaliza su feature, lo mergea contra esta rama..

Adicional a estos branches principales, durante el desarrollo se crean otros branches de soporte que tienen una vida finita, es decir, existen mientras exista el desarrollo para el cual fueron creadas:

• feature: se crea a partir de develop cuando una nueva funcionalidad necesita ser desarrollada. Al finalizar el desarrollo se hace merge a develop nuevamente.
• release: se crea a partir de develop para preparar una nueva versión del código que debe ser liberada en producción. Al finalizar el desarrollo se hace merge a develop y a master.
• hotfix: se crea a partir de master cuando es necesario corregir un error detectado en producción de manera urgente. Al finalizar el desarrollo se hace merge a develop y a master.

Diagrama del flujo de trabajo de GitFlow

Entre las ventajas de esta estrategia podemos decir que es una de las más fáciles de comprender, y es la más recomendada para proyectos estables y para equipos que contienen distintos tipos de desarrolladores, debido a que el control de las features más la release hace que el código sea más estable. Por otro lado, proporciona un control de versiones claro, ya que cada versión está etiquetada y probada individualmente. 

La desventaja que podemos observar en esta estrategia, es el hecho detener tantas barnches a mantener y se vuelve muy imperiosa la necesidad de recordar el realizar un merge entre ellas, para mantener la consistencia del código.

GitHub Flow

GitHub Flow, fue creado por GitHub [2] y es conocido en la comunidad de desarrolladores como una alternativa simple y ligera a GitFlow, la diferencia principal es la eliminación de la rama develop y la no existencia de los branches de “releases”, ya que está pensado para que la implementación en producción ocurra con frecuencia, incluso varias veces al día si es posible. 

Esta estrategía es ideal cuando se necesita mantener una única versión del código de producción.

En GitHub Flow existen solo dos tipos de branches:

• master (o main): el branch de código principal, es el que contiene el código que está listo para producción.
• features: son los branches de funcionalidades que permiten el desarrollo en paralelo. Estas branches son creadas desde master y se debe realizar un merge de la misma a la rama principal al finalizar el desarrollo, idealmente este paso debería realizarse mediante pull request,

Diagrama del flujo de trabajo de GitHub Flow

La principal aplicación de este flujo de trabajo, se da en proyectos de desarrollo donde se tienen features de duración corta (por ejemplo diarias) y/o en los casos donde se tiene la necesidad de entrega de valor constante.

Esta estrategia no es recomendable para los casos donde no se tiene el control del momento del pasaje a producción, por ejemplo porque se requiere de alguna aprobación externa, por ejemplo de un UAT, o se tiene solo ventanas de tiempo de deploy, por ejemplo fuera del horario laboral. Otro caso en donde no es viable su aplicación, es cuando se requiere una liberación de código más controlada, por ejemplo si se quiere solo liberar hotfix resueltos y no incorporar código evolutivo.

GitLab Flow

GitLab Flow [4] fue creado por GitLab para superar las "limitaciones" de GitHub Flow. Tiene un flujo de trabajo bastante similar a este último, siendo su principal diferencia es que adiciona el uso de branches por ambientes, por ejemplo, QA, Pre-Producción y Producción. Esto es debido a que considera los casos donde una nueva funcionalidad no siempre puede implementarse en entornos de producción, y teniendo en cuenta que una de las consignas de GitHub es que todo lo que haya en master es desplegado y hay ciertos casos en los que no es posible cumplirlo o no se necesita, tal como vimos al describir dicha estrategia.

GitLab Flow propone utilizar las siguientes branches: 

• master (o main): el branch de código principal. 
• features: son los branches de funcionalidades que permiten el desarrollo en paralelo. Estas branches son creadas desde master y se debe realizar un merge de la misma a la rama principal al finalizar el desarrollo, idealmente este paso debería realizarse mediante pull request,
• environment branches: se crea un branch por ambiente, las cuales son creadas a partir de master cuando el código se encuentra listo para desplegar en dicho ambiente. 

Diagrama del flujo de trabajo de GitLab Flow

Una característica de esta estrategia, es que al tener diferentes ramas por entorno permite configurar herramientas de CI y CD para que se despliegue automáticamente el código subido en cada una de esas ramas. La naturaleza de este flujo no requiere generar ramas de releases, ya que cada entorno será desplegado con cada merge request aceptada.

Seleccionando la mejor estrategia de branching

Git es una herramienta flexible y permite a los equipos de desarrollo utilizar una amplia variedad de flujos de trabajo y estrategias, lo que hace que seleccionar alguna de entre todas las opciones disponibles no sea tan fácil.

Respecto a la pregunta ¿Qué estrategia de branching se debería elegir?, no es posible dar una respuesta única que sea correcta en todos los casos y para todos los equipos. Sugerencias a tomar en cuenta para su elección:

• Empezar con lo más simple posible, solo avanzar hacia enfoques más complejos cuando surja la necesidad, no antes. 
• Elegir una estrategia que reduzca los diferentes “tipos” de branches disponibles para que los miembros del equipo elijan. 

Cabe destacar que en el presente artículo solo nos explayamos en un conjunto reducido de las estrategias existentes, y ducha selección fue hecha bajo la base de ser las más utilizadas, pero existen otras y seguramente aparecerán muchas más.

Referencias

1. A successful Git branching model: https://nvie.com/posts/a-successful-git-branching-model/
2. GitHub Flow - The best way to use Git and GitHub: https://githubflow.github.io/
3. Combine GitLab Flow and GitLab Duo for a workflow powerhouse:  https://about.gitlab.com/blog/2023/07/27/gitlab-flow-duo/
4. What is GitLab Flow?  https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/