Volviste de una feature branch que vivió tres semanas separada de main. El diff tiene 47 archivos. Dos compañeros tocaron los mismos módulos que tú, cada uno con su propia interpretación de cómo debía quedar esa parte del sistema. Pasas la tarde entera resolviendo conflictos que no son técnicos, sino de diseño: ustedes tres construyeron soluciones distintas para el mismo problema porque nadie vio el código del otro hasta ahora.
Ese dolor es real y común. Y es la razón por la que trunk-based development suena tan atractivo cuando lo describen en una charla o un blog post: todo el equipo integra a main constantemente, las branches viven horas y no semanas, los conflictos gigantes desaparecen porque nunca se acumulan.
El problema es que trunk-based development no es una política que se activa. Es una consecuencia de contar con una infraestructura que ya soporta una integración constante. Si tu equipo no tiene esa infraestructura y migra igual, no vas a tener menos conflictos. Vas a tener los mismos conflictos, además de un main roto la mitad del tiempo.
Qué es trunk-based development, en una frase que sí importa
Trunk-based development significa que todos los desarrolladores integran su código en una rama principal (trunk, generalmente main) al menos una vez al día, en vez de mantener ramas de feature que viven durante días o semanas antes de que se mergeen. El código incompleto se esconde detrás de feature flags, no detrás de branches.
Eso es todo. No hay ceremonia extra, no hay proceso nuevo que aprender. Pero esa simplicidad es engañosa: para que “integrar todos los días” no sea un desastre, cada integración debe ser segura. Y ahí es cuando la mayoría de los equipos que lo intentan se dan cuenta de que no estaban listos.
El CI que tienes no es el CI que necesitas
Todo equipo dice que tiene CI. Pocos tienen el CI que trunk-based development exige. La diferencia no es filosófica, es de velocidad y de confianza.
Si tu suite de tests tarda 25 minutos en ejecutarse y varios developers están mergeando a main varias veces al día, vas a tener una cola de builds esperando turno mientras el equipo sigue trabajando sobre un main que nadie sabe si está sano. Con feature branches largas ese problema no se nota, porque cada branch se testea sola, en su propio tiempo, sin competir con nadie.
Peor todavía: si tu CI tiene tests flaky (esos que fallan al azar sin que el código haya cambiado), en un modelo de branches largas se ignoran, se reintenta, y se sigue. En trunk-based development, un test flaky en main bloquea a todo el equipo o, peor aún, la gente aprende a ignorar los fallos de CI porque “siempre falla algo”. Ese día, la red de seguridad deja de existir y nadie avisa.
Lo que hace falta antes de migrar no es "tener CI". Es tener un pipeline que corra en minutos, no en decenas de minutos, con una tasa de falsos positivos cercana a cero, y con la disciplina de equipo de que un main roto se arregla en el momento, no al final del día.
Feature flags: la parte que todos subestiman
Sin branches largas, ¿dónde vive el código de una feature que todavía no está lista para producción? La respuesta correcta es: detrás de un feature flag. La respuesta real en equipos que migran sin pensarlo es: a medio hacer, en main, comentado, o protegido por un if (false) que alguien va a olvidar sacar.
Un sistema de feature flags serio no es una librería que se agrega en una tarde. Implica pensar en:
- Cómo se evalúan los flags en runtime sin degradar performance, porque ahora cada request potencialmente consulta el estado de decenas de flags activos al mismo tiempo.
- Quién es dueño del ciclo de vida de un flag: quién lo crea, quién decide cuándo el código viejo se borra. Los flags que nadie limpia se acumulan durante meses y el código termina lleno de ramas condicionales que nadie entiende, lo cual es exactamente el tipo de deuda técnica que trunk-based development prometía evitar.
- Cómo se testea código con múltiples flags combinados. Si hay cinco flags independientes, técnicamente hay 32 combinaciones posibles de estado. La suite de tests no corre las 32, así que el equipo está decidiendo, aunque no lo haya discutido, cuáles combinaciones son aceptables de no cubrir.
Si tu equipo no tiene ya un sistema de flags maduro, migrar a trunk-based development no elimina el problema de "cómo se esconde código incompleto". Solo cambia dónde se esconde: de una branch aislada a producción, mezclado con todo lo demás.
Testing automatizado: la parte que decide si esto funciona o explota
Con feature branches largas, un test suite mediocre es un problema tolerable. Hay tiempo: la branch vive semanas, hay code review extenso, hay QA manual antes del merge. Con trunk-based development, ese tiempo no existe. El código que se sube hoy puede estar en producción, o cerca, en horas.
Esto significa que la cobertura de tests no puede ser aspiracional. Necesita cubrir de verdad los flujos críticos, correr rápido, y sobre todo, ser confiable: un test que falla porque el código está mal debe fallar siempre, y uno que pasa debe significar que ese camino realmente funciona.
Acá aparece una tensión que pocos anticipan: trunk-based development empuja a los equipos hacia tests más pequeños y aislados (unitarios, de integración rápida) y aleja de los end-to-end pesados que tardan media hora en correr contra un ambiente completo. Si la estrategia de testing depende en gran parte de e2e lentos, hay que rediseñarla antes de migrar, no durante la migración.
Y si tu equipo directamente no tiene cultura de testing (algunos PRs con tests, otros sin, cobertura desigual entre módulos), trunk-based development no va a mejorar eso. Va a exponerlo, rápido, en producción.
La parte cultural que nadie pone en el diagrama de arquitectura
Todo lo anterior es infraestructura. Hay una parte que es puramente de equipo, y es la que más se subestima.
Trunk-based development requiere que el code review sea rápido. Si la norma actual es que un PR espera dos días para su primera revisión, y trunk-based development pide integrar en horas, esos dos números no cierran. O el review se vuelve superficial (lo cual erosiona la calidad), o los developers evitan pedir review y mergean directo (lo cual erosiona la confianza), o simplemente el modelo colapsa y todos vuelven, en silencio, a mantener sus cambios sin mergear por más tiempo del que el proceso "oficial" permite.
También requiere que el equipo tolere ver código incompleto en main todo el tiempo, protegido por flags, y que confíe en que ese código no se va a activar por accidente. Eso es un salto de confianza que en equipos con historial de incidentes de producción, alta rotación o seniority mixta no se da de un día para otro. Se construye, o no se tiene.
Y requiere una definición compartida de qué significa "listo para mergear". En un modelo de branches largas, esa definición puede ser laxa porque hay tiempo de sobra para corregir después. En trunk-based development, “laxo" significa “roto” para todos, de inmediato.
Cuándo simplemente no conviene todavía
Hay situaciones en las que la respuesta honesta es esperar. Si tu CI tarda más de diez minutos y nadie en el equipo tiene el mandato ni el tiempo asignado para arreglarlo, migrar solo va a mover el dolor de las branches al pipeline. Si tu producto no tiene, o no puede tener por razones regulatorias o de arquitectura, un sistema de feature flags viable, vas a estar escondiendo trabajo incompleto en producción sin ninguna red de seguridad. Si tu cobertura de pruebas es baja y nadie está dispuesto a invertir en aumentarla primero, cada integración diaria es una apuesta, no una práctica de ingeniería.
Y si el equipo es nuevo, distribuido en zonas horarias muy distintas sin solapamiento real, o todavía no tiene acuerdos claros sobre qué es código mergeable, agregar la presión de integrar constantemente no resuelve la falta de coordinación. La amplifica.
Nada de esto es un rechazo a trunk-based development como idea. Es reconocer que es la consecuencia de otras cosas bien hechas, no un atajo para conseguirlas. Los equipos que lo adoptan con éxito no lo hacen para arreglar su CI, su testing o su cultura de review: lo adoptan porque esas cosas ya estaban resueltas, y trunk-based development fue el paso lógico que vino después. Si tu equipo todavía está resolviendo esas cosas, ese es el trabajo real. Trunk-based development puede esperar.
