Git-Flow: Práctica Obsoleta
Anecdóticamente en México hemos notado una cierta adherencia y sobre-dependencia de equipos de ingeniería mexicanos a usar git-flow. En Valoreo creemos que esa es una práctica buena cuando se creó, sin embargo creemos que hay mejores formas de trabajar con git y CI/CD releases.
Git-Flow
Git-Flow es una estrategia creada para mejorar la organización de Branches (ramificaciones) dentro del repositorio y, de esta forma, dar más fluidez al proceso de nuevos Features y Releases.
El término, todavía, es reciente. Fue divulgado a través de una publicación del ingeniero de software holandés Vincent Driessen, en 2010. En esta, explicó con detalles cuál fue su idea al crear ese modelo para el uso de las Branches.
Git-flow predica el uso de la rama main como rama productiva, y el uso de varias más ramas como conductos de features para llegar a producción.
Como se puede ver en el diagrama, la idea es trabajar nuevos features en sus propias ramas y hacer merge de estos a develop. Siguiendo una cierta cadencia (cada dos semanas, al final del sprint etc) se crea un commit de Develop a Release y de Release ya se pasa Main (o Master).
El gran problema con Git-Flow
Git-Flow funciona, sin embargo ralentiza el proceso de integración y despliegue continuos (CI/CD). Tener Git-Flow es en realidad un obstáculo a tener realmente integración continua.
Veamos un ejemplo: Yo codifico y desarrollo el Feature A. Siguiendo los lineamientos de Git-Flow, este código estaría en una rama que se creó a partir de Develop y que haría merge de nuevo a Develop.
Una vez que mi código es aprobado e insertado en Develop entonces aún no hay integración continua ya que tiene que pasar por una serie de procesos manuales para llegar a producción. Lo cual básicamente previene de tener realmente integración continua.
El otro gran problema con Git-Flow es la falta de una única fuente de la verdad. Todos los nuevos Features se trabajan contra el código de Develop pero no el de producción. Esto causa que el código nuevo pueda funcionar bien en Develop, pero falle en producción.
Y bueno cabe notar que el propio Atlassian no recomienda más usar Git-Flow como sistema de organización de ramas para Git
La Alternativa “trunk-based workflows”
La alternativa recomendada ahora es trabajar directo sobre la base. En nuestro caso trabajar sobre la rama Main. Hablando de Github en específico, se plantea abrir ramas locales para nuevos desarrollos, crear el PR a Main para trabajar con revisión de código y luego ya meter el código nuevo a Main borrando la rama recién creada.
Para la gente que viene de Git-Flow puede causar algunas preguntas:
¿Si todo pasa directo a Main, dónde se realizan las pruebas?
¿Qué pasa con ambientes de pruebas, sandboxes o pre-productivos?
¿Cómo se manejan los hot-fixes o arreglos rápidos de código?
Primero para las pruebas, un sistema bien hecho de CI/CD contempla la integración y despliegue continuo en ambientes de pruebas. Si bien el despliegue a producción también es continuo, no significa que se haga inmediatamente. Finalmente los hot-fixes se simplifican considerablemente ya que todo esta integrado continuamente entonces se pueden desplegar estos arreglos rápidos forzando el despliegue inmediato a producción.
Lo que antes era separación de ambientes por ramas, se traduce en separación de ambientes por versiones. Un muy buen ejemplo de un verdadero sistema de CI/CD es el sistema que maneja Google para el despliegue de su código.
Google maneja todo el código en un mismo repositorio con un control de versiones desarrollado in-house llamado Piper. Piper tiene una sola versión de todo el código de Google en un dado momento. Esto garantiza que todo mundo esté trabajando contra la única versión de la verdad que es el CL (Change List o lo que sería equivalente a un PR en Github) más reciente. Claro que en Google se añaden múltiples CLs por segundo y solo Piper funciona de esa manera. No creo que un sólo repositorio de Git podría funcionar de la misma manera.
Usando Piper, Google Search desata toda la integración y despliegue automatizado en sus varios ambientes de pruebas. Algunos ambientes se actualizan en tiempo real. Otros se hacen en de forma calendarizada y se van desplegando en cada ambiente conforme a una cierta cadencia. De manera que el código que se integra a Piper no entra a producción si no hasta que pasa cierta ventana de tiempo.
