Entender que es trunk based development: guía práctica
Resumen
El trunk based development es un modelo donde todos los desarrolladores hacen commit a una única rama compartida, llamada trunk o main, al menos una vez al día. No hay ramas de larga duración ni proyectos de fusión interminables. El código siempre está listo para desplegar. Google opera así con 35.000 desarrolladores. El informe DORA 2021 muestra que los equipos de élite tienen 2,3 veces más probabilidades de usarlo que los equipos de bajo rendimiento.
¿Qué es trunk based development? Todos los desarrolladores del equipo hacen commit a una única rama compartida, llamada trunk o main, al menos una vez al día. Sin ramas de larga duración. Sin ese "hotfix-v2-backup-final" olvidado durante semanas. Si buscas entender que es trunk based development antes de adoptarlo, esta guía te da la respuesta directa. Las ramas cortas viven pocas horas, se fusionan rápido y se eliminan. El código siempre está listo para desplegarse. Google opera así con 35.000 desarrolladores. Aquí te explicamos cómo funciona, cuándo tiene sentido y cuándo no.
El problema del "informe_v2_FINAL_usa_este.xlsx" pero con código
¿Alguna vez has abierto una carpeta compartida y encontrado informe_v1.xlsx, informe_v2_FINAL.xlsx e informe_USA_ESTE_ediciones_greg.xlsx uno al lado del otro? Ya entiendes exactamente el dolor que el trunk based development intenta resolver.
Eso mismo ocurre en los repositorios cuando los equipos usan ramas de larga duración. Alguien abre una rama de funcionalidad en la semana uno. El resto del equipo sigue desplegando. En la semana tres, esa rama está decenas de commits por detrás de main. Fusionarla se convierte en un proyecto de fin de semana que nadie quiere gestionar. Los conflictos se acumulan. El desarrollador que escribió el código ya no recuerda por qué existe la mitad. Eso es el infierno de las fusiones.
Gitflow, la alternativa más enseñada, intenta solucionar esto con estructura formal: ramas separadas para funcionalidades, lanzamientos y hotfixes, cada una con una vida útil definida. La estructura parece ordenada sobre el papel. En la práctica, las ramas se acumulan como versiones de una hoja de cálculo en una carpeta compartida, y el "día de integración" se convierte en la "semana de integración".
El trunk based development toma la postura contraria: deja de acumular deuda de integración. Haz commit a main. Hoy.
Todos hacen commit al trunk. Todos los días. Así funciona el modelo.
La regla central es clara: todos los desarrolladores suben cambios al trunk compartido al menos una vez cada 24 horas. Sin excepciones por "todavía no he terminado". Haces commit de lo que tienes, y te aseguras de que lo que tienes no rompe la compilación.
Esto parece alarmante hasta que entiendes los mecanismos que lo hacen seguro:
Ramas de corta duración: puedes usar ramas, pero viven pocas horas. Una rama que dura más de dos días es una señal de alerta que merece atención.
Pruebas automatizadas en cada commit: el pipeline de CI ejecuta la batería de tests inmediatamente. Si algo se rompe, lo sabes en minutos, no al final del sprint.
Feature flags: las funcionalidades a medio construir permanecen ocultas detrás de un interruptor hasta que estén listas. Los usuarios nunca ven trabajo incompleto, aunque ya esté en el código de producción.
El resultado es un código base que siempre está listo para desplegarse. No "listo después de que fusionemos la rama y hagamos QA durante una semana", sino listo ahora mismo si hace falta. Esa es la promesa fundamental del modelo.
Las ramas de corta vida: se miden en horas, no en semanas
En el trunk based development no están prohibidas las ramas. Lo que está prohibido son las ramas largas.
Una rama que abres a las 9 de la mañana, trabajas durante la mañana, recibes revisión de código después de comer y fusionas a main antes de las 5 de la tarde es exactamente el tipo correcto. Es lo suficientemente pequeña para entenderse de una sola lectura. Tus compañeros de equipo tienen contexto fresco cuando la revisan. Los conflictos, si los hay, se resuelven en minutos.
Una rama que vive tres semanas mientras un desarrollador construye todo un sistema de autenticación en solitario es el problema. Cuando llega el momento de fusionar, el equipo pasa más tiempo resolviendo conflictos que el que dedicó a construir la funcionalidad entera. El desarrollador original ya no recuerda la mitad de las decisiones que tomó.
El umbral práctico que usan la mayoría de los equipos con trunk based development: si una rama no se ha fusionado en dos días, algo necesita cambiar. O la funcionalidad es demasiado grande y hay que dividirla en piezas más pequeñas, o necesita un feature flag para que el trabajo parcial llegue de forma segura al trunk.
Dividir el trabajo en piezas más pequeñas es la disciplina central que desarrolla el trunk based development. En lugar de "construir el dashboard completo", despliegas "añadir la capa de datos", luego "añadir el primer gráfico", luego "conectar los filtros". Cada pieza se fusiona al trunk, se prueba y se despliega de forma independiente. La funcionalidad completa emerge de forma incremental a lo largo de varios commits.
Esto parece más lento. En la práctica es más rápido, porque encuentras los problemas cuando el contexto todavía está fresco y la superficie todavía es pequeña.
Feature flags: cómo despliegas trabajo incompleto sin romper nada
Los feature flags (también llamados feature toggles) son el mecanismo que hace que el trunk based development sea práctico cuando una funcionalidad no puede terminarse en una única rama de corta duración.
La idea es sencilla: envuelves la nueva funcionalidad en una condición que solo se activa cuando un indicador específico está encendido.
if (featureFlags.nuevoDashboardInformes) {
renderizarNuevoDashboard();
} else {
renderizarDashboardAntiguo();
}El nuevo código se despliega a producción. Simplemente no se ejecuta para los usuarios hasta que activas el interruptor. Esto significa varias cosas concretas:
Los desarrolladores pueden hacer commit de trabajo en progreso al trunk sin afectar a nadie
El equipo de QA puede probar la funcionalidad en producción activando el flag para un usuario o entorno específico
Un lanzamiento se convierte en un cambio de configuración, no en un evento de despliegue
Si algo se rompe, apagas el flag sin necesidad de rollback ni rama de hotfix
La infraestructura de feature flags va desde una simple variable de entorno comprobada al inicio hasta plataformas especializadas. Para un equipo que empieza, un archivo de configuración o una variable por entorno es suficiente. Lo importante es tener la capacidad, no la complejidad del tooling.
Cuándo el trunk based development no es la mejor opción
Vale la pena decirlo sin rodeos: el trunk based development no es universalmente mejor. Se adapta a contextos específicos.
Evítalo si:
Tu pipeline de CI/CD no está listo. El trunk based development sin pruebas automatizadas en cada commit no es una estrategia de ramas: es un código base que acumula errores a toda velocidad. La infraestructura de pruebas tiene que estar en su lugar antes de que el modelo de ramas pueda funcionar.
El equipo no puede hacer commits frecuentes por su naturaleza. Los equipos distribuidos donde los contribuyentes trabajan de forma asíncrona en distintas zonas horarias, o los proyectos de código abierto donde los colaboradores envían lotes poco frecuentes, tendrán dificultades con la cadencia diaria de commits.
Estás en un entorno regulado con ventanas de lanzamiento obligatorias. Algunas industrias requieren aprobación externa, largos ciclos de QA y registros de auditoría formales por rama de lanzamiento. Las ramas de lanzamiento estructuradas de Gitflow se adaptan mejor a ese tipo de flujo de trabajo.
La disciplina del equipo todavía no está a ese nivel. El trunk based development requiere que cada commit a main supere todas las pruebas o se corrija de inmediato. Si tu equipo tolera compilaciones rotas, el trunk compartido se convierte en el problema compartido de todos.
Gitflow es una opción razonable para equipos con calendarios de lanzamiento trimestrales, múltiples funcionalidades simultáneas desarrolladas por squads separados, o requisitos de cumplimiento que exigen aislamiento a nivel de rama. La pregunta es qué encaja de verdad, no qué enfoque gana sobre el papel.
Cómo migrar de Gitflow a trunk based development sin una crisis
Si tu equipo está en Gitflow y quiere probar el trunk based development, la migración no tiene que ser un cambio brusco ni doloroso.
Empieza dejando de crear nuevas ramas de larga duración. Las funcionalidades que se inicien después de la decisión usan ramas de corta duración. Las que ya están en progreso en ramas largas terminan bajo el modelo antiguo. Los dos enfoques coexisten temporalmente, sin que nadie tenga que tirar trabajo a la basura.
Antes de hacer commit de trabajo inacabado al trunk, necesitas feature flags. Configurar aunque sea un sistema básico es el requisito previo para todo lo demás. Sin él, el trunk based development significa desplegar una interfaz incompleta a los usuarios de producción, que verán ruinas de funcionalidades a medio construir.
Luego establece CI en la rama principal: las pruebas automatizadas se ejecutan en cada push, los tests fallidos bloquean la fusión y nadie fusiona sin una compilación exitosa. Esta es la parte no negociable. Sin CI, no hay trunk based development, solo hay caos compartido.
Por último, define la regla de los dos días de forma explícita: cualquier rama de más de dos días genera una conversación sobre qué hacer con ella. Divide la funcionalidad en partes más pequeñas, añade un flag o despliega lo que ya está listo. Hazlo visible en tu proceso de pull request para que no dependa de la memoria de nadie.
El ajuste incómodo al que se enfrenta la mayoría de los equipos: aceptar que "parcialmente completo" es algo válido para hacer commit, siempre que esté oculto detrás de un flag y no rompa las pruebas existentes.
Lo que dicen los datos del informe DORA sobre velocidad de entrega
Los informes DevOps Research and Assessment (DORA) son lo más parecido que tiene el desarrollo de software a una investigación empírica a gran escala sobre prácticas de equipo. El informe DORA 2021 encontró que los equipos de élite tienen 2,3 veces más probabilidades de usar trunk based development en comparación con los equipos de bajo rendimiento.
Los equipos de élite en el marco DORA despliegan múltiples veces al día, con tiempos de entrega desde el commit hasta producción medidos en horas en lugar de semanas. El trunk based development se correlaciona de forma consistente con esos resultados.
El matiz importante: correlación no es causalidad. Los equipos de alto rendimiento adoptan el trunk based development porque ya han invertido en la disciplina subyacente: pruebas automatizadas, infraestructura sólida de CI/CD, ingenieros que escriben cambios pequeños y concretos. Esas bases vienen primero. El trunk based development es el modelo de ramas que encaja en ese contexto, no el factor que lo crea.
Biscuit lo entiende enseguida: un buen retriever no intenta traer tres pelotas a la vez. Un commit, una revisión, una fusión. Buen chico.
¿Vale la pena cambiar a trunk based development?
Si tu equipo pasa tiempo significativo en cada sprint resolviendo conflictos de fusión, retrasa lanzamientos porque "la rama de funcionalidad no está lista", o tiene ramas abiertas durante tanto tiempo que nadie recuerda para qué servían, el trunk based development merece una evaluación seria.
La cadencia diaria de commits es exigente. La infraestructura de feature flags requiere configuración. El cambio cultural lleva algunas semanas, hasta que el equipo interioriza que "parcialmente completo detrás de un flag" es mejor que "completo pero bloqueado en una rama". Pero el resultado es una mejora real en la forma de trabajar del equipo: un código base siempre listo para desplegar, conflictos de fusión que se miden en líneas y no en archivos, y lanzamientos que son rutina en lugar de eventos de crisis.
Empieza en pequeño: un equipo, un sprint, CI ejecutándose en cada push, feature flags preparados. Observa qué cambia en cuatro semanas.