GitFlow esta roto... Entonces que uso? Pt2 Ahora es personal

Para los lectores que ya hayan leido la primera parte comento como GitFlow tal y como lo vemos no es lo que parece y genera muchos problemas a nivel del ciclo de vida del codigo. Ahora bien para no volverme un hater indiscriminado de todo lo que usan las startup o los Silicon Valley unicorns jejeje, les comento para lo que a mi me funciona y yo desde mi punto de vista mas pragmatico impulso.

TDB, Con que se come?

Esta es la tipica metodologia de trabajo que usabas antes de que existiera y es la mas comun ironicamente en nuestros proyectos personales pese a que sea mucho menos tedioso de trabajar en organizaciones (y con justas razones). TDB o Trunk Based Development es un formato de desarrollo pasandolo al criollo donde todo lo tiras a main puesto que todo tu codigo desarrollado debe ser ideado con vistas a correr directamente en produccion.

El entrenamiento debe ser tan fuerte que la guerra parezca un descanso
- Douglas MacArthur

Esto aunque a algun PM o Gerente pueda verse como algo descabellado en verdad esto te puede facilitar mucho la vida en concepto de detalles como:

Solo un MR por proyecto: ya no hay que pelear con 70 ramas a la cual se debe hacer MR de una sola para todo el proyecto y para todos los usuarios Devs, QA, Cliente, entre otros.
Congruencia entre entornos: como todos salimos desde main y vamos hacia main, no hay un mayor problema por temer a que QA tenga las dependencias distintas de Dev o Prod, o que las funcionalidades de otro Dev esten en un entorno pero otro no.

💡

Claramente esto no quita el drift si en tiempo de desarrollo una persona es distinta a otra pero mitiga con creces estos problemas respecto a GitFlow.

Todo con mente a produccion: como lo mencione brevemente con anterioridad esto obliga a los desarrolladores a que todas las soluciones que se planteen se hagan con cara a tener una solucion lista para produccion con su cache, optimizacion y demas. Si me dieran una moneda por cada vez que escucho "no mano, lo dejo asi mientras se presenta a cliente o para que QA me deje de joder" no seria rico (la verdad jaja) pero me daria lo suficiente para pagarme un buen almuercito.
Menos ramas menos gasto: como mecione en la entrada anterior uno de los tax ocultos que muchos no nos damos cuenta que es la cantidad de ambientes a pagar, trabajando con una unica rama esto nos facilita muchisimo mas los costos y el drift entre entornos ademas de que ya no pelearemos con el tipico solo funciona en Dev pero no en QA o Prod, si no que solo un entorno listo para trabajar.

Mi humilde opinion

Ahora bien como soy consciente que hay Scrum Masters y PM que les dara un paro cardiaco si el dev le dice que se trabajara directo en produccion. Hago mi pequeño aporte dando mis piscas de sal al bife del TDB para que para mis queridos PM y Scrum Master sea mas digerible jejeje:

Tagea main, dale checkpoints a tu partida

Obviamente pasar todo a main genera una logica muy marcada de desarrollo usando rolling-release el cual puede ser una espada de doble filo, denotando primeramente lo bueno permitiendo una logica de desarrollo mucho mas preparada para produccion. Ahora bien igual nunca esta demas tener puntos de "descanso" entre cambios para poder tener un plan de respaldo si algun despliegue llega a tener un error por incorporar cambios disruptivos en la aplicacion.

Feature Flags, desplegar y lanzar caracteristicas no es lo mismo.

Muchos PM y Scrum Master asocian la palabra desplegar con la palabra lanzar o publicar cosa la cual no es necesariamente cierta. Una de las feature flags mas comunes son las publicaciones basadas en tiempo dejas toda la informacion lista para ejecutar, pero esta no se disponibiliza hasta que dicha fecha especifica que esta en la DB o inclusive harcodeada en codigo sea disponible. Aunque existe una forma mucho mas sofisticada y reutilizable para aplicar dichas publicaciones o lanzamientos de caracteristicas las cuales son las feature flags una Api Externa o serie de variable de entorno la cual te permite mutar el comportamiento de una aplicacion en tiempo de ejecucion, esto te permite subir todo el codigo que requieras y dejar dicha caracteristica deshabilitada hasta que la Feature Flag sea activada, esto te da la posibilidad de activar y desactivar caracteristicas completas o flujos completos inclusive todo al alcance de un dedo.

Entornos efimeros y Review Apps, haz QA inteligente sin pagar un entorno completo

Como denotamos en el post anterior uno de los grandes taxes ocultos de GitFlow son los entornos long-lived ahora bien de igual manera requerimos una forma de hacer testing, desarrollo y QA sin la necesidad de pasar las cosas a produccion a ciegas. Para esto existen las Review Apps y los entornos efimeros, desde infraestructura hay muchisimas formas de obtenerlas de las sencillas y mejor planteadas es el uso de ArgoCD por medio de los ApplicationSet (pero bueno esto es arena de otro blog), esto alimenta varias buenas practicas:

Permite un entorno de trabajo limpio donde solo las personas (QA, Devs otros) que requieran tener acceso a estas caracteristicas en desarrollo puedan tenerlo sin tener problemas con otros haciendo otros trabajos que te pueda pisar las mangueras.
Te permite ser el owner dentro de tu MR, es decir ya no tenemos los tipicos problemas que requiermos otra persona para tener acceso a la DB de QA en la nube o de Dev por que como to como autor del MR eres tambien dueño y responsable del entorno en el que se trabaja.
El consumo de recursos es el justo. Claramente uno de los contras que se denotan ante las Review Apps es que se puede disparar la Bill justamente por que pasamos de tener 3 o 4 entornos grandes a tener cerca de 8 a 10 MR y cada una con su respectiva app, en entornos como lo es Kubernetes esto se amortiza haciendo una metodologia de Instancias SPOT para que el costo de computo sea mas barato junto con la deshabilitacion de features en infra tales como las HPA o bajar los request te permite tener un entorno production-ready sin la necesidad de desangrar tu billetera.
Forzar a hacer el entorno reproducible siempre, como en vez de tener un engine gordo que este vivo desde antes que estubieras en la empresa siempre son entornos que se construyen y destruyen constantemente fuerzas a los devs a desarrollar tieniendo en cuenta que el estado puede cambiar o que no apuntaras a una IP hardcodeada si no que siempre el entorno sera cambiante dependiendo donde se este ejecutando o que variables de entorno tenga a la mano.

Centraliza las docs y los contratos entre micros

Claramente hoy en dia el mayor problema o por lo menos el mas comun en el desarrollo de micro servicios no es tanto desarrollar o alinear la logica de negocios enter micros si no tener una via de comunicacion resiliente sea por HTTP P2P, gRPC o inclusive por medio de Request-Reply usando un Broker como lo es RabbitMQ, el tema es que todos estos (menos gRPC) son solamente metodos de comunicacion y no garantizan que la info que se envia desde el Micro A sea la que espera el Micro B, a lo cual es necesario centralizar todos los contratos de una API inclusive si se puede de forma fuertemente tipada como lo es el propio gRPC mejor aun a lo cual esto te quita el problema mas comun el cual es que ayer funcionaba pero hoy no y esto va relacionado con el siguiente punto el cual es:

Versiona tus APIs

Muchas veces usamos los versionamientos como excusa para hacer incompatibles endpoints entre si pero eso no quita de que muchas veces los clientes o inclusive los otros dev de otros modulos o productos que se integren con el que se esta desarrollando requieran seguir teniendo interoperabilidad lo cual se permito con algo tan sencillo como prefijar tus APIs con un /v1 /v2 y asi lo cual le permite que si el frontend no se despliega a la par que el back o que si hay clientes que aun no actualizan la app movil aun puedan seguir disfrutando del servicio sin necesidad de que se les rompa al segundo de abrir la aplicacion.

Extra: Por que descubri esto.

Bueno obviamente y como todos los blogs que redacto aca tienen una razon de ser y en este caso fueron dos experiencias y una charla la que me hizo dar cuenta de las cosas:

Cuando fui Dev para una empresa pequeña hablamos de 4 a 6 desarrolladores trabajabamos con 4! ambientes preproductivos los cuales eran dev, qa, uat y shadow (solo para front) esto se convertia en un lio de merge requests hubo un punto de catarsis cuando hicimos un gran trabajo para presentar a cliente en uat y quedo desplegado los MR en todos los entornos menos justamente en dicho entorno en un solo repo (teniamos 5 micro servicios y 2 frontends). Para ponerlo corto la reu fue un asco jajajaja.
Esta segunda experiencia mucho mas reciente fue cuando estoy recien integrado como DevOps Specialist y me piden que haga unos cambios en terraform de un proyecto para agregar unos micros, 3 entornos + 1 inactivo y fuera de eso todo por medio de PR y por medio de atlantis (estaba prohibido por politica el tofu apply local) a lo cual pos un trabajo bastante incomodo de gestion solo para agregar un micro.

Teniendo dichas experiencias en la mente fresca hace poco en el DevOps Days Medellin 2026 (parece promo paga jajaja) en una charla de la empresa Fluid Attacks habla de como es su proceso de desarrollo full por TDB y entre anotar la forma de trabajo, lo que explican y lo que ya conocia, fue amor a primera vista jajaja.