GitFlow esta roto... Entonces que uso?

Empiezo redactando este blog desde una habitacion de hotel en alguna parte de mi pais natal, puesto que siento que para hablar de este tema requiero empezar en un entorno seguro jeje. Ya que principalmente y muchos lugares nos han recomendado GitFlow como la forma correcta para trabajar de forma colaborativa dentro de equipos de desarrollo, ahora bien antes de que me linchen como una barra brava de futbol en plena liga BetPlay quiero dar mi punto de vista.

El O(n) en los equipos de desarrollo.

GitFlow per se no es una herramienta mala y porsupuesto que hay empresas que hacen uso de dicha metodologia y tienen un gran rendimiento el tema es que como digo en mi trabajo:

No es un problema de organizacion si no de escala.
- Su servilleta

Ya que si tienes en una plantilla de desarrollo de 3 a 5 desarrolladores para un aplicativo con backend y frontend, por metrica general frameworks y metodologias como Scrum (otro a que le debo un blog jeje) o GitFlow te funcionaran con mucho dinamismo. Puesto que aplicar dichas politicas y reglas que se define en la metodologia y darle seguimiento a las mismas es mucho mas sencillo ya que se puede llevar este "micro-management" con mucha sencillez ademas de ser facilmente detectable el prospecto quien no siga lo anteriormente mencionado.

Para ponerlo en terminos mas generales llevemolos a una alegoria:

Por ejemplo si lo llevamos a un salon de colegio dar un trato personalizado y llevar seguimiento de un salon de a lo sumo 10-11 personas es facilmente llevable para un profesor puesto que puede tener retentiva del avance y gestionar como es el proceso con cada alumno de forma individual. Ahora bien si aplicamos algo similar a un salon de entre 40 a 50 personas, al profesor se le hara mucho mas dificil la gestion ya que esto se vuelve una tarea de supervision constante y alerta temprana o en una tarea de gestion operativa y mitigacion de daños constantes, para que todo el curso pueda estar medianamente a mismo nivel. Esto genera que el alumnado no avance a favor de darle seguimiento a dichas personas que se quedan o no pueden llevar a cabo las tareas de forma constante. o por su contrario que las personas que no puedan avanzar quedan tan atras del pensum academico generando que sean expulsadas o decerten del colegio.

Dejando de lado mi critica al sistema de educacion actual algo similar ocurre en los equipos de trabajo puesto que esta metodologia lleva a ser mas pesada a medida que sube el numero de prospectos dentro del equipo.

git merge .... (conflict)

Para las personas que no conozcan GitFlow o por lo menos lo que la gran mayoria de empresas en LATAM comprendemos por eso... GitFlow es una metodologia de gestion de git para equipos colaborativos el cual se autodefine como escalable. El cual se gestiona una rama por entorno donde generalmente se encuentran tres ramas truncales:

dev o develop es la rama donde el grueso de los desarrolladores interactua como rama base la cual sostiene la mayoria de features y por ende parches de bugs, seguridad entre otros y por media general si ves el arbol global de un repositorio por media general es la rama con mas cambios frente a la rama main
qa o testing por su puesto como a los tester y QA les molesta tanto que su entorno cambie constantemente generando que los flujos de testing puedan verse interrumpidos, hace que se genere esta rama para mitigar dichos problemas por media general haciendo un merge truncal desde dev hacia dicha rama.
main o master tristemente la rama mas olvidada por metrica general puesto que al grueso de los devs y mas aun cuando el aplicativo o modulo ya es productivo, generando que el drift entre esta rama y las anteriores sea mas amplia aun.

Listo ya entendiendo esto creo que ya podemos entender un poco lo que genera tener varias ramas paralelas, las cuales mantener genera una mayor friccion con los equipos de desarrollo, puesto que ya de por si tener el estres de la gestion de uno o varios Merge Request (que no se note que uso GitLab) tambien debes replicarlo a las demas ramas muchas veces de forma paralela no escalonada como se espera en un flujo normal de GitFlow en su gran mayoria por presion de cargos comerciales u administrativos.

Facilitando un ejemplo mas tangible lo que pasa es que muchas veces ramas como la dev o la qa se usan para acumular todo el avance del equipo de desarrollo para posteriormente pasar un gran MR desde dicha rama hacia main el cual generalmente lo hace el senior o el lider tecnico acumulando dias o meses inclusive de desarrollo en un solo commit lo cual implica muchas cosas pueden salir mal, empezando por lo sencillo como los conflictos los cuales no lo asume la persona la cual desarrollo el modulo con el conflicto si no una persona distinta la cual no necesariamente posee el contexto completo de dicho sector del codigo, teniendo que llamar al desarrollador muchas veces en ventana de despliegue y ahi cuando salen los errores postoriormente generando los hotfix. Una pequeña y hermosa herramienta la cual hace by-pass a todo el flujo de desarrollo generalmente en un momento de desesperacion y que posteriormente vaya a otra cadena de hotfix para parchar los huecos que dejaron los parches anteriores ademas de posteriormente hacer backfill de dichos parches a todas las ramas anteriores.

La ametralladora de cherry-picks, la cura que acabo siendo peor que la enfermedad.

Visto lo que puede llegar a pasar y mas aun en sistemas grandes con el punto anterior mucha gente comenzo a ver como alternativa empezar a implementar sus soluciones en las distintas ramas usando la caracteristica de git llamada cherry-pick una caracteristica muy poderosa pero a su ves muy delicada.

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility
- Mensaje default de sudo en terminales Linux

Esto puede llevar a situaciones incomodas, planteandolo de otra manera en vez de llevarte todo tu working tree el cual ya sabes que funciona y tiene todo parchado tal y en el orden que se requiere usar los cherry picks es llevar commit por commit (cereza por cereza en una pinza) desde tu rama fuente hasta tu rama objetivo lo cual puede generar dos problemas principales:

Drift entre ramas

Al trabajar como base la rama dev con regularidad es la mas actualizada y posee los cambios mas recientes encima se hara mucho mas facil de manipular justamente por que ya lleva toda la carga de codigo que tu anteriormente y que otras personas dentro de tu grupo de trabajo, lo cual ayuda a acortar el tiempo de desarrollo pero a la hora de llevarlo a una rama con mas drift como qa o propiamente main/master esto genera que si el archivo es diferente entre rama y rama pum apply conflict.
Esto genera lo que ya hablamos en puntos anteriores o en segunda instancia no genera conflictos pero tu amigo que trabaja en otra feature y que tu incluiste dentro de tu flujo en un endpoint o como importacion de una libreria o algo tan sencillo como el drift entre composer.json, package.json o pyproject.toml genera que funcionalidades que das por sentadas que son funcionales al pasarlas a otra rama ya no lo sean.

Archivos huerfanos o fantasmas

Este es un poco menos comun pero igual si no mas peligroso que otros un cherry pick no deja de ser un archivo .diff que se aplica entre los overlays de una rama u otra lo cual genera que el sistema de git al intentar conciliar dichos cambios procure llenar la info que el pueda con lo que tenga a la mano y si por ejemplo un archivo de otra version ya no existe pero un cherry pick en un commit ve que se ejecuto el sistema procura reconstruir dicho archivo pese que a nivel sintactico del lenguaje no tenga sentido ya que git no tiene en cuenta (y no debe el simplemente compara bytes) lo cual genera huerfanos con codigo sin sentido o que un commit posterior elimine un archivo que otro desarrollador usa pisandose la manguera entre las distintas personas.

Obviamente esto no procura satanizar el uso de esta herramienta que como ya comente es muy poderosa pero es de admitir que es peligroso su uso indiscriminado ya que esto va fusilando commit a commit la historia y el working tree de las distintas ramas haciendo que estas no tengan una "linea argumental" logica haciendo imposible su fusion en el medio o largo plazo lo cual te genera entornos dispares.

Los long-lived environment el tax oculto de GitFlow.

Ahora bien para acabar de asustarte en los equipos de infra y DevOps un sintoma que generalmente vemos y con el cual lidiamos dia tras dia; una hermosa palabra que los gerentes y PM les da miedo hablar que es el budget. El budget o presupuesto en infraestructura es basicamente cuanto es el acumulado disponible a gastar en un rango de tiempo (generalmente mensual), ahora bien este numerito se ve alterado cuando se trabaja con GitFlow puesto que entran en la mesa que son los entornos Dev y QA los cuales son entornos de alto tiempo de vida puesto que es un entorno el cual estara siempre para los usuarios internos en este caso desarrolladores y testers. Estos entornos no nos vamos a dar la auto-mentirita simple y llanamente acaba multiplicando la bill de AWS o el proveedor de turno y obviamente para los cargos administrativos y financiera nuestro objetivo es gastar lo menos en medida de lo posible o estar dentro de budget dandonos soluciones interesante o un tanto divertidas como las siguientes:

El apago de entornos por franjas horarias: este es un clasico y el mas comun dentro de los equipos de infra para ir escarbando centavos dentro de la bill para que administracion no nos mate, esto para quien no conozca es simplemente hacer un apagado y encendido programado una hora despues y antes de terminar e iniciar jornada para no gastar recursos durante el tiempo que el equipo no este dentro de tiempo laboral, esto logicmente lo acabamos ignorando o pausando esta policy por que una o dos personas deben quedarse trabajando por la noche para poder entregar una feature al dia siguiente y hasta ahi llego el ahorro.
Entornos serverless: a este le debo un blog completo, pero para hacerlo corto es cuando para hacer mas barato tu aplicacion prefieres hacer un cambio de "raiz" y hacer que todo se ejecute de raiz en un formato serverless, respuesta corta es mas caro!
Entornos dispares: en pro de hacer mas barato los otros entornos se ejecutan en runtimes distintos por ejemplo usando el entorno de UAT y Prod en EKS con todas las de la ley y Dev y QA refundidos en una pequeña EC2 con Graviton donde todo esta apeñuscado con un K3s o Docker Compose.

La verdad como veo que esto esta quedando muy largo en un futuro no muy lejano les dejare la parte 2 de este blog, por que me emocione redactando jejeje.

Bye los quiero.