xand.es

Git: haciendo releases

Introducción

Esto es una forma de preparar las releases de software cuando el equipo de desarrollo sigue la metodología Gitflow (o alguna de sus variantes). Llevo utilizando esta forma de preparar las releases desde hace algunos años y los resultados son bastante positivos.

El método cuenta con 6 pasos. Para el propósito de este manual vamos a suponer que la versión que se prentende generar es la 1.7. Al mismo tiempo se entiende que ya se tiene la versión 1.6 generada anteriormente.

Rama: integración

Nuestro punto de partida para la generación de la release tiene que ser justo la release anterior, es decir, el commit marcado con el tag v.1.6. Para saber cuál es el commit utilizaremos el siguiente comando:


$ git log v.1.6

En la salida de dicho comando vamos a ver el historial de los commits, el que nos interesa estará como el primero, en este caso:


commit 01758f6172503abaf8abd91838a849b8080604e5 (tag: v.1.6)
Merge: 9d47987f d0189b7b
Author: Alex Vavilin <xand@xand.es>
Date:   Wed Dec 11 13:57:50 2016 +0000

    Merge branch 'integration/v.1.6' into 'master'
    
    Integration/v.1.6

commit d0189b7b29a0c836ee53193f5b15d6c2cff4fc1c
Author: Alex Vavilin <xand@xand.es>
Date:   Wed Dec 11 13:57:49 2016 +0000

    [FEAT#790] Descripción de la feature

En este caso el commit que nos interesa es el 01758f61, es decir, el primero que aparece. Para crear la rama para la integración se tiene que crear una rama con el nombre integration/v.1.7 a partir de este commit. Se hace con el siguiente comando:


$ git checkout -b integration/v.1.7 01758f61

Con esto ya tenemos la rama donde prepararemos la release.

Elección de los commits y su mergeo

El siguiente paso consiste en determinar cuáles son los commits que se quieren incluir en la release.


$ git log integration/v.1.7..develop --oneline --merges --first-parent

Con este comando vamos a obtener una lista de commits que han sido mergeados en la rama develop y no han sido llevados a la release anterior, esto es, no están presentes en el tag v.1.6. Podemos exportar la lista y escoger únicamente aquellos commits que nos interesan para la release.

Es importante tener en cuenta que cada commit posterior lleva integrado también el anterior, con lo cual, escoger el primer commit de la lista (viendo desde arriba) equivale a escoger todos.

Despliegue en el entorno de pruebas

Fixes para la corrección de fallos

Merge a master

Merge a develop

  1. Se crea la rama integration/v.X.Y a partir del master o bien a partir de un commit (el último).
  2. Se cogen todos los commits del develop a la rama en cuestión.
  3. Se realiza el despliegue de la rama en entorno staging.
  4. Se realizan los FIX# para la corrección de fallos.
  5. Se hace merge integration/v.X.Y -> master y se genera el tag v.X.Y. (A partir de aquí se puede generar una nueva versión).
  6. Se hace merge develop -> integration/v.X.Y
  7. Se hace merge integration/v.X.Y -> develop.
  8. Se elimina la rama integration/v.X.Y.