Es algo indiscutible que las herramientas de control de versiones, como GIT o Subversion, son herramientas necesarios y de uso diario en el trabajo de un desarrollador. Entre las diferentes ventajas que nos ofrece, está la de facilitar el trabajo en equipo sobre un mismo proyecto. Permite que cada uno trabaje sobre una copia del proyecto en sus respectivas máquinas locales, y posteriormente unificarlo de forma automática y que los demás lo tengan disponible al momento.

Sin embargo, esta ventaja puede convertirse en un dolor de cabeza si no se ponen en práctica buenas prácticas en referente al uso de estas herramientas. Esto puede suponer muchos conflictos entre ficheros, subir código que no funciona ya que lo realizado por una persona afecta negativamente a la otra. Al final, en vez de facilitarnos el trabajo nos lo está complicando mucho más porque tenemos que dedicarle bastante tiempo a solucionar todas estas incidencias. Es por ello que es necesario definir procedimiento y buenas prácticas a la hora de trabajar, y cuanto mayor es el número de personas trabajando en un mismo proyecto más importante es.

Antes de continuar vamos a dar por hecho de que el lector tiene conocimientos de como funcionan estas herramientas. El artículo de hoy ira más allá de una herramienta en concreta, de si esta es distribuida o centralizada, o que comandos existen en cada una de ellas. Entendemos que el lector a trabajado con ellas en el algún momento o tiene un conocimiento básico sobre ellos: que es una rama, como clonar, como subir código al repositorio, como obtener código, hacer un merge,… Lo que aquí se pretende es dar unas pautas, definir un flujo de trabajo para que sea más sencillo gestionar un proyecto entre los diferentes miembros de un equipo sea cual sea su herramienta de control de versiones.

¿Qué es el Workflow o flujo de trabajo?

El flujo de trabajo o workflow no es más que el estudio de los aspectos operacionales de una actividad de trabajo con el fin de diseñar un proceso operativo eficiente que permita mejorar el proceso. En este caso el proceso de desarrollo de software utilizando herramientas de control de versiones.

¿En que consiste el workflow respecto al uso de herramientas de control de versiones?

El objetivo de este es evitar tener tantos conflictos al momento de realizar tareas de pull y push ya que está basado en crear ramas que parten de master llamadas “feature branch” o “topic branch” donde las mismas no interrumpen el trabajo de los demás. Dichas ramas tienen un único propósito, es decir, son creadas para agregar una funcionalidad específica, corregir un error (bug), borrar funcionalidad deprecada etc… Una vez finalizada su función dicha funcionalidad debe de ser unida a master nuevamente y así sucesivamente a lo largo del desarrollo del proyecto. Además de lo comentado, debemos asumir que dicha rama está “libre” de errores de compilación o ejecución para que la rama master pueda ser desplegada en producción sin preocupaciones.

Propuesta del workflow

  1. Rama master.
    Es la rama que se crea cuando se genera un nuevo repositorio. El código que se encuentra en esta rama debe de estar testeado y libre de errores (obviamente siempre puede surgir algún bug).
    Cuando se considere que en un momento dato el software que está en la rama master está para desplegar a producción, es conveniente crear un tag o etiqueta, y ser el código que se encuentre en esos tag concretos los que se desplieguen en producción. De esta manera es mucho más fácil realizar un seguimiento de lo que está en producción, y de gestionar las diferentes versiones del software y las funcionalidades que incorpora cada una de ellas.
  2. Rama developer
    Una rama que parte del master. En esta rama estará el código de las nuevas funcionalidades desarrollas mezcladas con el resto del código del software a la espera de ser testeado. Utilizamos esto para realizar los test definitivos del software para ver si puede pasar al estado estable, con lo que lo pasaremos a la rama master, o si se han encontrado bug habrá que solucionarlos.
  3. Feature branch o topic branch.
    Son las ramas que parten de la rama developer. Su objetivo es desarrollar una nueva funcionalidad, corregir algún bug, eliminar alguna funcionalidad… Una vez ha concluido el desarrollo de esa tarea y funciona correctamente y se mezcla con la rama developer.

En resumen, el proceso sería el siguiente. Se parte de la última versión estable etiquetada en la rama master y esa se lleva a la rama developer. Una vez la última versión está en la rama developer se genera una nueva rama por cada tarea a realizar (nueva funcionalidad, corrección de bug, eliminar funcionalidad,…).

Según se van finalizando las tareas, estas son llevadas a la rama developer de vuelta. Aquí se realiza un test en los que interactuará el software con todas las nuevas tareas realizadas. Se ve que todo funciona correctamente. En este caso todo esto se llevará a la rama master y se creará un tag como nueva versión estable. En caso de que se hayan encontrado errores, se definirán nuevas tareas para su corrección con lo que ello implica: crear nuevas feature branches, volver a pasarlo a developer y su consiguiente test antes de etiquetarlo como estable.

Esto no deja de sor otra propuesta, existen varias. Lo importante es identificar el proceso de trabajo de cada uno, y diseñar un flujo de trabajo que se adecue a la forma de trabajar del equipo.