Git workflow

Ligado con el proyecto de infraestructura es necesario tener un plan de trabajo que nos permita trabajar de forma cómoda a la vez que resolver nuestros problemas con la mayor brevedad y menor incidencia.

En un ciclo normal de desarrollo, el equipo nos reunimos con el cliente, revisamos el estado del proyecto y definimos una serie de historias de usuario / funcionalidades / necesidades que creemos podemos desarrollar en un tiempo corto (idealmente para la siguiente itreación), una vez terminadas o alcanzado el plazo pactado, pasamos nuestras funcionalidades nuevas a release (no tiene porqué ser al final, puede ser progresivo), las validamos con el cliente y si todo va bien las ponemos en producción.

¿Que sucede si no se aprueba la release? Tenemos dos escenarios:

Idealmente tendríamos que corregirlo en develop y luego volver a actualizar release, con lo que si algun otro programador está trabajando en develop, podremos no solo corregir el problema sino también añadir nuevo valor al cliente (siguiendo el flujo de mejora continuada).

Si por alguna razón develop no está estable (se ha perdido funcionalidad, se ha dejado algo que antes funcionaba a medias, etc, ...) tenemos un problema serio. No obstante podemos hacer una copia de la branca release, corregir el problema, hacer merge en release, validarlo con el usuario y hacer merge en develop.

Como vemos a la práctica es más costoso, requiere de más merges, tenemos cosas nuevas que el usuario final aun no puede ver.

¿Que sucede si aparece un error en producción?

Primero de todo analizar el nivel de criticidad, es realmente un error, cumple nuestro requisito de hotfix, si es que sí hacemos lo siguiente:

1. Copia de master en local 
2. Realizamos un test que reproduzca el problema
3. Corregimos, merge a master, validamos con el usuario.
4. Merge a develop

El segundo merge lo hacemos en develop, para tener nuestra branca "principal" de desarrollo actualizada, no obstante tenemos un escenario donde podemos valorarlo:

• Tenemos entorno de pre-producción y no podemos / queremos que el error se pueda reproduzir allí.

Típicamente en este punto queda la duda si se puede perder un hotfix con algún merge, por ejemplo con uno de release (sin hotfix) a master (con hotfix), en este caso si el merge funciona bien (que es lo normal) se mantiene el hotfix en master.

Un pequeño resumen de las brancas que tenemos:

Origin / Master (M):

• Branca estable (en producción)
• Solo HOTFIX (error grave, requerimiento legal, ..), con copia a develop.

Origin / Release (R):

• Futura versión a desplegar
• Funcionalidades completas y terminadas
• Solo correcciones menores que no se pueden hacer en develop, con copia a develop.

Origin / Develop (D):

• Las nuevas funcionalidades van aquí
• Branca compartida entre programadores
• Si no está aquí no existe (no se mantiene, prueba, etc..)
• No hay funcionalidades a medias, subimos cuando está listo para validar (por otros programadores, el cliente, …) [idealmente]

Un árbol resumen de que atacar y en que orden:

Y como siempre el resumen final (click para ampliar):

Agradecer el articulo de Vincent Driessen en http://nvie.com/posts/a-successful-git-branching-model/ que en su día nos ayudo a tener una idea clara de como trabajar con GIT.