Seguimos hablando de git-flow. En la entrada anterior vimos cómo utilizar un release branch para poner a punto nuestra aplicación antes de llevarla a producción. En esta última entrega de la serie veremos cómo utilizar git-flow para gestionar la resolución de bugs urgentes y, en general, cualquier tipo de modificación que requiera un rápido despliegue en producción.

¿Qué son las hotfix branches de git-flow?

Recordemos cómo había quedado nuestro repositorio tras la puesta en producción:

• La rama master, que actualmente contiene la versión 1.0, ya ha sido desplegada en producción
• La rama develop, que ya incorpora todos los cambios y ajustes que hicimos durante la puesta a punto de la versión 1.0, está lista para avanzar en el desarrollo de la versión 1.1

Recordemos cómo dejamos el repositorio en la entrega anterior:

Estamos listos para empezar un nuevo sprint. Tenemos una reunión de planificación, ponemos en el backlog las historias de usuario que vamos a desarrollar para la versión 1.1, y empezamos a trabajar.

A los pocos días, recibimos un aviso de nuestros compañeros del departamento de atención al cliente: ¡hay un bug de la aplicación en producción! Git-flow utiliza hotfix branches para implementar un flujo de trabajo que permite:

• Interrumpir el trabajo que estamos haciendo en la rama develop para la versión 1.1
• Resolver el bug
• Incorporar la corrección del bug en la rama master para desplegarlo en producción lo más rápido posible
• Incorporar la corrección del bug en la rama develop (si procede)
• Retomar el trabajo que estábamos haciendo en la rama develop

Para los que estáis familiarizados con la administración de sistemas, a mí cada vez que me pasa esto me siento como el kernel de Linux haciendo context switching. Cada vez que tenemos que dejar cambiar de rama tenemos que cambiar de contexto. Eso implica recordar qué estábamos haciendo, qué teníamos en la nueva rama y en qué estado estábamos. Sin una herramienta como git, que permite hacer este cambio de forma rápida y viendo la historia de las dos ramas, el tiempo necesario para hacer el cambio de contexto nos hace menos productivos. Las ramas hotfix nos ayudan a hacer estos cambios de contexto de forma más eficiente y a corregir el problema con el mínimo impacto sobre el resto del trabajo que estamos haciendo.

Creando la rama hotfix/bug-14

Como hemos comentado antes, supongamos que ya llevamos unos cuantos días trabajando en el sprint. Habremos creado una (o varias) feature branches y el estado de nuestro repositorio puede ser algo parecido a esto:

Estado de la rama develop antes del aviso de bug

Nos encontramos trabajando en la historia de usuario H5 cuando recibimos la llamada de nuestros compañeros avisándonos del bug.

Lo primero que haremos será almacenar el trabajo que estamos haciendo y que vamos a tener que interrumpir porque tenemos que cambiar de contexto. El objetivo es guardar este trabajo a medias y recuperarlo cuando hayamos terminado de corregir el bug. Hay varias formas de hacer esto, nosotros lo guardaremos en el stash ya que prevemos que la corrección del bug no nos llevará mucho tiempo:

$ git stash save 'Antes de empezar a corregir el bug #14'
Saved working directory and index state On feature/h5: Antes de empezar a corregir el bug #14
HEAD is now at f6609a9 Primera implementación de las páginas estáticas

Podemos ver el contenido del stash con el comando git stash list

$ git stash list
stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14

El objetivo de esta entrada no es hablar del stash, así que entraremos en detalle en otra ocasión. Si no sabes lo que es, puedes consultar este enlace. Seguimos.

Una vez tenemos nuestro trabajo almacenado y listo para cambiar de contexto, creamos la rama hotfix/bug14:

$ git flow hotfix start bug14
Switched to a new branch 'hotfix/bug14'

Follow-up actions:
- Bump the version number now!
- Start committing your hot fixes
- When done, run:

git flow hotfix finish 'bug14'

Estado del repositorio tras crear la rama hotfix/bug14

Los comandos que git-flow ha ejecutado por nosotros son en este caso bastante sencillos:

$ git checkout master
$ git checkout -b hotfix/bug14

Con la rama creada, empezamos a trabajar en la corrección del bug. Pasadas unas horas y unos cuantos commits después, tenemos el bug corregido y listo para subir a producción. Este es el estado del repositorio:

Estado del repositorio después de haber localizado y corregido el bug.

Cerrando la rama hotfix/bug14

Nos acercamos al final. Una vez corregido el bug, procedemos a cerrar la rama hotfix:

$ git flow hotfix finish bug14

Cuando ejecutamos este comando, git-flow nos pide que introduzcamos tres mensajes:

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

Se abre el editor predeterminado para introducir el mensaje del merge commit

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

Mensaje para la etiqueta de versión

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

Se abre el editor predeterminado para introducir el mensaje del merge commit con la rama develop

Al igual que cuando cerramos la rama release/1.0, al finalizar la ejecución del comando se 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 hotfix/bug14 --no-ff
git tag vbug14
git checkout develop
git merge hotfix/bug14 --no-ff
git branch -d hotfix/bug14

El nombre que git-flow ha puesto a la etiqueta no es precisamente el más adecuado, así que borramos esa etiqueta y creamos una nueva que se llama v1.0.1. El repositorio queda de la siguiente manera:

Y ya está, casi hemos terminado… Sólo nos falta volver a cambiar de contexto y recuperar el repositorio como lo teníamos antes de empezar a corregir el bug.

Volviendo a la rama feature/h5

Este paso es el más sencillo, basta ejecutar el comando

$ git checkout feature/h5

Ahora bien: ¿cómo recuperamos ese trabajo a medias que habíamos tenido que interrumpir y que almacenamos en el stash?

$ git stash list
stash@{0}: On feature/h5: Antes de empezar a corregir el bug #14

$ git stash pop stash@{0}
Auto-merging index.html

(Nota: dado que sólo tenemos una cosa guardada en el stash, podríamos ejecutar sencillamente git stash pop).

Y con esto hemos terminado, ya tenemos todo listo para seguir trabajando en la historia de usuario H5.

Conclusión

En esta entrega hemos visto cómo git-flow nos ayuda a gestionar la corrección de bugs del sistema en producción a través de hotfix branches. Creando una rama específica para corregir el bug, conseguimos que mientras una parte del equipo está trabajando en la rama develop, otra parte pueda corregir el bug. Si es una misma persona la que tiene que hacer este trabajo, la creación de estas ramas auxiliares facilita el cambio de contexto al desarrollador.

Este tipo de ramas no tienen mucho sentido en las ramas develop ya que la detección y corrección de bugs forma parte del proceso de desarrollo de nueva funcionalidad

En la siguiente entrega haremos un pequeño resumen de lo que hemos visto en esta serie de artículos y daremos por terminada la serie.