Estrategias de branching – No solo existe git-flow

Hoy vamos a hablar de estrategias de ramificación en proyectos software. Hace tiempo escribimos sobre git-flow, pero también existen otras estrategias de ramificación. Dependiendo del proyecto en el que estemos, el tamaño del equipo, la manera de liberar nuevas funcionalidades, etc. podemos elegir la estrategia que mejor se adapte a nuestra variables del proyecto.

Estrategia Mainline Branch

Es la estrategia más simple y bastante efectiva para equipos muy pequeños. Solo 1 rama principal, cada desarrollador crea una rama para trabajar en una funcionalidad y al terminar «mergean» con la rama master. La rama master siempre está lista para subir. En otras palabras, la rama master solo contiene código de calidad, testado y nunca estará rota.

Si usasemos Git, cada desarrollador tendría si propia rama local, trabajaría en una nueva funcionalidad o resolvería un bug. Cuando terminase la tarea, «mergearía» con la rama master y todo estaría listo para subir.

Viendo la figura, las ramas A, B y C son ramas locales. Manteniendo esta estrategia de ramificación, nos aseguramos de no perder el tiempo haciendo más «mergeos» de los necesarios. Este enfoque funcionaría a la perfección con procedimientos automatizados de despliegue, cada vez que hay un push sobre la rama master, el sistema de despliegue lanzaría los tests y desplegaría en producción los cambios.

Ventajas

• No tenemos muchas ramas en el código, por lo que los flujos de trabajo son muy simples, así como las mezclas de ramas.
• Al tener solo una rama, todos los desarrolladores deberíamos hacer commits pequeños, para que nos sea relativamente sencillo deshacer los errores.
• Hace que los desarrolladores testeemos más el código antes de subir, ya que el código irá directamente a producción.
• Teniendo un buen sistema de automatización de despliegues tendremos todos los cambios siempre listos en producción.

Desventajas

• El hecho de que supongamos que la rama master siempre está lista de producción hace que si el equipo no tiene una buena infraestructura de test pueda ser arriesgado subir a producción.
• Esta estrategia puede ser muy apropiada para sitios web, pero podría no serlo para software que debe ser instalado. Ya que el hecho de tener actualizaciones frecuentes sería un handicap para los usuarios de nuestra aplicación.

Una rama por funcionalidad (Branch Per Feature Deployment Strategy)

En esta estrategia, tenemos una rama por funcionalidad. Una vez que estamos seguros de que la funcionalidad funciona correctamente y se ha probado, se combina con la rama de integración, (un fork de la rama principal/master cuya única finalidad es hacer que la rama principal nunca esté rota. Idealmente cualquier cosa que esté en la rama master, está lista para subir a producción. Normalmente en este tipo de estrategia, los despliegues son algo más manuales, ya que al mezclar con la rama master, puede que tengamos conflictos.

Con esta estrategia, estamos siempre cuidando que todo lo que sube a producción esta probado, ya que «tenemos una pausa» antes de subir. El concepto de pull request está muy ligado a esta estrategia. Una vez que hemos creado una nueva funcionalidad y estamos seguros de que está completa, enviamos una solicitud de pull request a la rama de integración. Esta solicitud es manualmente y si todo está correcto, se «mergea». Por eso decimos que master siempre está listo para despliegue.

Ventajas

• Esta estrategia está centrada en el despliegue rápido de código.
• A diferencia de la estrategia anterior, tenemos un paso de generación opcional. Podemos elegir cuando queremos mezclar con la rama master, lo que hace que podamos subir muchas nuevas funcionalidades a la vez.

Desventajas

• Si la rama donde hemos creado una nueva funcionalidad tarda mucho en «mergearse» con master, seguramente tengamos conflictos, por lo que los desarrolladores debemos mantener actualizadas las ramas hasta que son mergeadas.
• Tenemos que ser cuidadosos con el nombre de las ramas, por ejemplo podemos nombrar cada rama con el ID de la tarea de Jira o similar, ya que si no puede sernos difícil si tenemos muchas funcionalidades abiertas.
• Es necesario que los desarrolladors vayan limpiando ramas viejas cuando mezcla con master. Esto no es una gran desventaja, pero si no se limpia a menudo podemos llegar a tener demasiadas ramas «muertas».

Estrategia basada en entornos (Environment Based Branching Strategy)

Si tenemos un entorno de desarrollo,un entorno de preproducción y un entorno de producción. Podemos tener una rama por cada entorno. Partimos de la rama master, que es la que tenemos para desarrollar y creamos una rama con una nueva funcionalidad. Cuando la funcionalidad esta terminada, volvemos a mezclar con master. Cuando queremos subir a producción, mergeamos la rama master con la rama del entorno de preproducción. Probamos en preproducción que todo esté listo y mergeamos con la rama de producción cuando queramos subir a real.

Variación de la estrategia basada en entornos utilizada por Git

Git utiliza 4 ramas diferentes y las nombramos adecuadamente para entender para que cada rama. Además sigue la norma de que un commit solo puede propagarse a la siguiente rama, es decir, todos los merges están ordenados. Así el dibujo de las ramas se parece a una pirámide. Cada una de las ramas «inferiores» tienen commits que no están en las ramas «superiores». Para pasar de una rama a otra es necesario un proceso de «code review» para así poder integrarse en la siguiente rama.

• mantenimiento: esta rama contiene el código de la ultima versión estable.
• master: esta rama contiene commits que irán en la próxima versión.
• next: esta rama está destinada a probar funcionalidades para no comprometer la estabilidad de la rama master
• actualizaciones propuestas: esta rama contiene commits que todavía no están listos para incluirse en una rama superior.

Estrategia de ramificación basada en lanzamientos (Release Branching Strategy)

A veces es necesario liberar software antes de pasarlo a la rama master, para ello es necesario trabajar con ramas releases. En este caso, cada rama release contiene una versión menor. Después que anunciemos la liberación de la rama release, solo incluiremos los bugs realmente serios en la rama release. Si es posible, lo que haremos será mergear los bugs primero en master y después haremos chery-pick en la rama release. De esta manera evitaremos encontrar el bug en versiones posteriores. Cada vez que se incluye un bug-fix se incluye en una rama release, se suma uno al patch para cumplir con «Semantic Versioning». Algunos proyectos tambien tienen una rama estable que apunta a la ultima versión liberada.

Referencias

• Imágenes y post traducidos de http://www.javacodegeeks.com/2015/11/git-branching-strategies.html