Desarrollo

Gitflow: flujos de trabajo en GIT

Un correcto flujo de trabajo en GIT permite trabajar con clientes grandes de forma más sencilla. En el siguiente artículo explicamos cómo diseñamos un workflow adaptado a nuestras propias necesidades.

Gitflow flujos de trabajo en GIT

En nuestro artículo “Por qué incorporamos GIT a nuestra lógica de trabajo” señalamos que las razones fundamentales son la seguridad y el orden. En palabras simples, todo se reduce a la confianza que otorga trabajar con un workflow ordenado, adaptado al equipo de desarrolladores y bajo el alero de una herramienta como GIT.

Trabajar con clientes grandes es sinónimo de tener que enfrentarse al desarrollo de procesos de mediana o alta complejidad para intentar resolver una amplia gama de requerimientos. Por ejemplo, en IDA mantenemos algunos ecosistemas de sitios construidos con WordPress Multiusuario. La más grande estas redes cuenta con 26 sitios. Si bien, existe una contraparte que centraliza gran parte de los requerimientos, cada sitio puede tener solicitudes y modificaciones que se realizan con distintas urgencias y tiempos. Cada solicitud puede ser atendida por distintas personas dentro del equipo, pero también es común que un mismo desarrollador lleve más de un trabajo con diversos estados de avance.

Normalmente hay modificaciones pequeñas, cuyos tiempos de ejecución van desde cuestión de minutos hasta un par de horas, y donde su paso por QA es bastante rutinario y rápido; se testea por las distintas partes involucradas y pasa a producción prácticamente durante el día. No obstante, hay modificaciones que pueden demorar desde un par de días hasta semanas, todo mediado por revisiones, correcciones e iteraciones de mayor profundidad por parte de cliente.

Si estos procesos se hicieran en orden, uno detrás de otro, no sería mayor problema. Sin embargo, no ocurre así y los procesos de más largo alcance no pueden detener los cambios pequeños y simples que son requeridos prácticamente en paralelo. Es ahí donde un flujo de trabajo se vuelve indispensable.

Gitflow pensado en el equipo

Como también señalamos en el artículo anterior, es importante que el diseño de un workflow se haga pensando en el equipo de trabajo, en sus exigencias y requerimientos diarios, así como en los problemas que se enfrentará con cierta recurrencia. En nuestro caso ya está dicho: los requerimientos de distinto alcance, urgencias y tiempos para proyectos que se constituyen como ecosistemas son aquellos que nos plantean procesos de mayor complejidad.

Las situaciones más comunes y simples que pretendemos evitar son:

  1. Sobre escribir o borrar código de otro desarrollador y no tener como recuperarlo.
  2. Pasar tanto a QA como a producción código incompleto en proceso de desarrollo.
  3. Pasar al sitio productivo cambios aún no aprobados en QA por el cliente.
  4. No poder determinar cuál es la última versión estable de producción, teniendo clones locales del código fuente que no están disponibles para el resto del equipo.
  5. No contar con un respaldo diario del código fuente disponible para cualquier miembro del equipo.

Pero debemos contemplar situaciones más complejas y no tan frecuentes:

  1. Conflictos por modificaciones idénticas en un mismo archivo.
  2. Mezclas incorrectas o con resolución de conflictos erróneas.
  3. Modificaciones directas en el sitio productivo que se saltan el gitflow.
  4. Errores derivados de no aplicar correctamente el gitflow.

Diseñando nuestro flujo

Nuestro equipo normalmente fluctúa entre tres y cinco desarrolladores; y como está dicho, puede ser requerida la colaboración de cualquiera de ellos en un proyecto cada vez que se considere necesario. Con las situaciones ya descritas en mente, nuestro workflow es bastante estándar y simple. Todos los proyectos cuentan con tres ramas: Develop, QA y Master, además de ramas features que son de carácter temporal, puesto que se van creando y eliminando a la par de los requerimientos.

La rama master es lo que se libera para su publicación en el sitio de producción, una vez aprobado en el sitio de QA, cuya rama asociada obviamente es QA. La rama develop sirve como la rama pivote de integración de las ramas features.

Gitflow

En ese sentido, cuando se realiza una nueva solicitud de modificación se hace un nuevo branch temporal a partir de Develop, esta modificación puede estar un minuto o un mes en proceso de desarrollo sin afectar la rama de inicio Develop. En el caso de ser requerida una nueva modificación, el proceso se repite partiendo siempre desde la rama Develop. Sólo cuando una rama feature se cierra, es decir, cuando finaliza toda modificación y desarrollo, se mezcla automáticamente con Develop y se elimina.

Testeo instantáneo

Es necesario explicar en este punto, que toda modificación de código se va testeando de manera prácticamente instantánea en un ambiente de desarrollo en AWS. En la práctica, hecha cualquier modificación en el código fuente local, ésta se sube inmediatamente por ssh a nuestro servidor web de pruebas, donde se testea en el momento. En paralelo, dependiendo de la extensión en el tiempo o de la cantidad y tipo de tareas asociadas a un requerimiento, el desarrollador hará uno o varios commit durante el día. Lo importante es que cuando la rama feature se cierre todo debe funcionar de manera óptima para pasar ese conjunto de modificaciones a la rama QA y al ambiente homónimo en el servidor, donde se realizarán las  pruebas del cliente. Si el cliente pide nuevas modificaciones se itera el proceso anterior, pero si el cliente da su aprobación, el conjunto de cambios pasan a la rama Master y al ambiente productivo en el servidor.

Todo el proceso de deploy a los ambientes de QA y Productivo se realiza íntegramente con GIT. Nada se sube a estos ambientes mediante FTP o SSH, pero es importante considerar que hay elementos que deben ser ignorados por el flujo como todos los archivos y carpetas de caché, las imágenes y archivos multimedia que se subirán a través del CMS en la carpeta uploads y el archivo de configuración wp-config.php.

Herramientas de ayuda

Finalmente, existen partes del proceso que se pueden automatizar o simplificar haciendo uso de herramientas o interfaces. Por ejemplo, para subir una modificación al ambiente de desarrollo lo hacemos mediante plugins de nuestros entornos de desarrollo. En IDA usamos mayoritariamente Atom y el paquete SFTP-Deployment for Atom.io, también nos valemos de algunas tareas automatizadas en GULP para subir archivos CSS compilados desde SASS o JavaScript unificado y minificado. En wordpress, a la vez, usamos el plugin Revisr que ayuda en muchos casos para hacer tanto los pull como push y los commits que sean necesarios. Bitbucket ofrece una serie de alternativas para automatizar procesos de deploy en AWS y también cuenta con webhooks, una funcionalidad que permite realizar integraciones y automatizaciones de manera mucho más personalizada. Es tema de unir necesidad e imaginación.

Director de Desarrollo
Investigo lo último en tecnología web, para ofrecer soluciones innovadoras en los proyectos. Encargado de resolver problemas de integración en diversas API's, servicios y plataformas que operamos. Me gustan los proyectos perfectamente terminados, con código bien estructurado, simple y legible.

Comentarios