En la entrada anterior vimos cómo utilizamos la rama develop y las features branches para desarrollar la primera versión de la aplicación. En este entrega veremos cómo utilizar las release branches  para preparar la puesta en producción de nuestra aplicación.

¿Para qué necesitamos una release branch?

El objetivo de estas ramas es preparar nuestra aplicación para su puesta en producción. En algunos equipos, estas ramas son las que se vuelcan en los servidores de pre-producción para hacer el testing final: se corrigen bugs, se pule la interfaz, se ajusta la maquetación…se hace la puesta a punto final de la aplicación antes de liberar la versión definitiva. Vamos a crear una release branch para la versión 1.0. Utilizando la línea de comandos, ejecutamos

$ git flow release start 1.0

Switched to a new branch 'release/1.0'
Summary of actions:
- A new branch 'release/1.0' was created, based on 'develop'
- You are now on branch 'release/1.0'

Follow-up actions:

- Bump the version number now!
- Start committing last-minute fixes in preparing your release

- When done, run:

git flow release finish '1.0'

Tras ejecutar estos comandos el repositorio queda de la siguiente manera:

Una vez creada la rama, empezamos el proceso de corrección y depuración, que en el ejemplo que nos ocupa da como resultado varios commits a la rama release/1.0. Así queda el repositorio cuando hemos terminado de arreglar todos los bugs y estamos listos para que nuestro proyecto pase a producción:

Cerrando la rama release con git-flow

En este punto, nuestro código fuente está testado, todos los bugs corregidos (o eso pensamos) y todo está listo para entregar la versión 1.0. Para cerrar la rama, ejecutamos

$ git flow release finish 1.0

Cuando ejecutamos este comando git-flow nos va a pedir que introduzcamos tres mensajes:

• El primero de ellos es el mensaje del merge commit resultado de incorporar los cambios de release/1.0 en master

• El segundo mensaje es el mensaje que git-flow pondrá a la etiqueta que va a crear para identificar esta versión

• El tercero y último será el mensaje que git-flow pondrá en el merge commit resultado de incorporar la rama release/1.0 en develop

Cuando el comando termina, se nos muestra un resumen de todas las acciones que han tenido lugar:

En rojo hemos indicado las acciones que git-flow ha ido ejecutando y que pueden resumirse en los siguientes comandos:

git checkout master
git merge release/1.0 --no-ff
git tag v1.0
git checkout develop
git merge release/1.0 --no-ff
git branch -d release/1.0

El repositorio queda de la siguiente manera:

Despliegue en producción

Dado que en este ejemplo estamos trabajando con una web HTML, el despliegue en producción es muy sencillo:

• Sincronizamos las rama master con git push
  

git checkout master
git push

• En el servidor en producción ejecutamos

git checkout master
git pull

Variaciones de este flujo

Cuando estamos trabajando en la rama release, puede darse el caso de que algunos bugs sean más complicados de resolver de lo esperado. Si eso ocurre, siempre podemos crear una rama dentro de release para corregir ese bug y, una vez terminado, incorporar los cambios a la rama release.

Conclusión

En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la liberación de nuevas versiones de nuestro código fuente. Creando una rama específica para la puesta a punto de la versión, conseguimos que mientras una parte del equipo está trabajando release/1.0, otra parte puede avanzar en nuevas funcionalidades usando feature branches en la rama develop.

Lo que se debe evitar es utilizar la rama release para desarrollar nuevas funcionalidades. Si esto ocurre quiere decir que hemos pasado el código a pre-producción demasiado pronto.

En la siguiente entrega veremos cómo prepara hotfixes para nuestro código en producción.