Que es el desarrollo basado en trunk y cómo usarlo
Resumen
El desarrollo basado en trunk concentra todo el trabajo en una sola rama, main, con integraciones diarias. Sin ramas de larga duración, los equipos evitan los conflictos masivos de fusión. Los feature flags ocultan el código incompleto. Las métricas DORA lo identifican como predictor clave del rendimiento élite en la entrega de software. Migrar requiere un pipeline de CI por debajo de 15 minutos, un servicio de feature flags y sprints con historias de alcance diario.
Que es el desarrollo basado en trunk, y por qué lo priorizan los equipos de ingeniería de mayor rendimiento. La respuesta corta: es una estrategia de ramificación donde cada desarrollador integra sus cambios en una única rama compartida, main o trunk, al menos una vez al día. Sin ramas de funcionalidad de larga duración. El código vive en estado listo para producción en todo momento.
Si una funcionalidad no está terminada, un feature flag la oculta a los usuarios. No una rama que la aísle del resto del equipo.
Eso es la versión corta. La versión larga explica por qué tu flujo de trabajo actual puede estar generando más riesgo del que percibes.
Por qué las ramas de larga duración se convierten en un lastre
La mayoría de los equipos aprenden control de versiones a través de ramas de funcionalidad: una rama por ticket, fusionada tras la revisión. Parece organizado.
Cuando una rama vive más de 24 horas, cada commit que tus compañeros hacen a main es un conflicto futuro que todavía no has visto. En un equipo de ocho ingenieros con ramas de dos semanas cada uno, no estás gestionando una integración. Estás administrando ocho universos paralelos que divergen un poco más cada día. El merge day no es una tarea: es una negociación.
La investigación DORA, el mayor estudio longitudinal sobre rendimiento en la entrega de software realizado en miles de equipos, traza una línea clara: las ramas que viven más de 24 horas son una señal predictiva de menor frecuencia de despliegues y tasas más altas de fallos en los cambios. Los equipos de alto rendimiento integran varias veces al día. El resto fusiona cuando la funcionalidad está "terminada", lo que a menudo significa que nunca se hace de forma limpia.
El coste oculto no es el conflicto de fusión en sí. Es el cambio de contexto necesario para resolverlo tres semanas después de haber escrito el código. Nadie recuerda cuál era la intención original.
Cómo funciona realmente el desarrollo basado en trunk
El mecanismo es sencillo. Sacas la última versión de main. Haces un cambio pequeño y coherente. Ejecutas los tests. Subes a main. Todo esto antes de la hora del almuerzo.
Para un contribuidor individual en un repositorio pequeño, ya es así como funciona. Para un equipo de veinte personas en un monorepo de 300K líneas de código, requiere tres prácticas trabajando juntas:
Ramas de corta duración (opcional pero habitual): Algunos equipos permiten ramas de hasta dos días antes de forzar una fusión. Esto preserva la cultura de revisión de código sin crear divergencias de varias semanas. La rama es un vehículo de revisión, no un mecanismo de aislamiento.
Integración continua en cada push: Cada commit a main dispara una compilación completa y la suite de tests. Si algo falla, falla en minutos, no después de que una rama de dos semanas aterrice el viernes a las 4 de la tarde.
Feature flags para trabajo incompleto: Las funcionalidades sin terminar se despliegan a producción detrás de un flag. Los usuarios no ven nada. El equipo integra todo. Esta es la parte que la mayoría de los equipos omite, y es por eso que su primer experimento con TBD fracasa.
Ninguna de estas prácticas es exclusiva del desarrollo basado en trunk. La diferencia es que TBD las convierte en obligatorias, no opcionales.
Feature flags: el mecanismo que hace funcionar el TBD
Un feature flag es una condición en tu código que se evalúa en tiempo de ejecución. Cuando el flag está desactivado, el nuevo flujo de código no se ejecuta. Cuando está activado, para un usuario específico, un porcentaje del tráfico o toda la base de usuarios, sí lo hace.
Suena trivial. Las implicaciones no lo son: puedes separar el despliegue del lanzamiento. El código llega a producción de forma continua. Las funcionalidades se lanzan cuando están listas, o no se lanzan en absoluto si el rollout sale mal y necesitas desactivarlo en diez segundos en lugar de revertir tres semanas de commits.
La configuración mínima viable requiere tres cosas: una forma de definir los flags, evaluarlos en tiempo de ejecución y cambiarlos sin redesplegar. Un archivo JSON plano funciona para un equipo de tres. Un servicio dedicado de gestión de features justifica su complejidad en torno a los diez ingenieros, o cuando los flags necesitan reglas de segmentación como "habilitado para usuarios en el cohorte beta en España".
Algo que debes rastrear: la deuda de flags. Los flags que nunca se eliminan después de que la funcionalidad se despliega se convierten en spaghetti de condicionales. Un equipo que hace TBD correctamente retira cada flag en un sprint tras el despliegue completo. Trata los flags como andamiaje temporal, no como configuración permanente.
TBD vs Gitflow: comparativa directa para 2026
Gitflow fue diseñado en 2010 para software en caja entregado en ciclos trimestrales. Modela los lanzamientos como ramas de larga duración. Para equipos que despliegan cada día o cada hora, ese modelo ya no encaja.
Así queda la comparativa para un equipo que ejecuta CI/CD:
Duración de las ramas: Gitflow trabaja con días o semanas. TBD trabaja con horas, con un máximo de 1-2 días.
Conflictos de fusión: Gitflow genera conflictos frecuentes y de alta gravedad. TBD genera conflictos raros y de baja gravedad porque los intervalos de integración son horas, no semanas.
Frecuencia de despliegue: Gitflow vincula el despliegue a una rama de release. TBD desacopla completamente el despliegue del lanzamiento.
Mecanismo de rollback: Gitflow revierte una fusión de rama. TBD desactiva un feature flag.
Complejidad de incorporación: Gitflow requiere entender las convenciones de develop/main/hotfix. TBD tiene una sola rama: main.
Inversión en CI necesaria: Gitflow es baja, las ramas absorben el riesgo. TBD es alta, main debe estar verde en todo momento.
Gitflow no está equivocado en todos los contextos. Si publicas una app móvil en una App Store y no puedes enviar hotfixes en minutos, un modelo de rama de release tiene sentido. Si gestionas un SaaS donde controlas los despliegues, la estructura adicional de ramificación es una sobrecarga que añade coste de coordinación sin añadir seguridad.
Qué dicen las métricas DORA sobre las estrategias de ramificación
La investigación State of DevOps de DORA rastrea el rendimiento en la entrega de software desde 2014. Dos hallazgos son directamente relevantes aquí.
Primero, el desarrollo basado en trunk es una de las 24 capacidades que predicen el rendimiento en el modelo DORA. Se sitúa en el clúster de "entrega continua", lo que significa que DORA lo trata como práctica de infraestructura, no como preferencia del equipo.
Segundo, los equipos de alto rendimiento despliegan varias veces al día. Los de bajo rendimiento despliegan una vez a la semana o al mes. Las ramas de larga duración y la integración infrecuente aparecen en el extremo más lento de esa distribución, año tras año.
Lo que la investigación no afirma: que TBD cause el alto rendimiento. Los equipos que adoptan TBD con éxito tienden a tener ya pruebas automatizadas, un pipeline de CI funcionando y el hábito de commits pequeños. El desarrollo basado en trunk pone al descubierto esas carencias inmediatamente si faltan. Un equipo sin CI y con un 40% de inestabilidad en los tests no se beneficiará de cambiar a TBD. Simplemente romperá main con más frecuencia.
Cuándo el TBD deja de tener sentido
Tres escenarios donde el desarrollo basado en trunk crea más problemas de los que resuelve:
Entornos muy regulados con puertas de aprobación obligatorias: Si cada release necesita una validación de cumplimiento antes de desplegarse, el despliegue continuo está bloqueado de todas formas. El modelo de ramificación pasa a un segundo plano.
Suites de tests insuficientes: TBD requiere un pipeline de CI rápido y fiable. Si las compilaciones tardan 45 minutos y tienen un 20% de inestabilidad, los desarrolladores agruparán commits para evitar esperar. Eso invalida el modelo. El cuello de botella es la infraestructura de tests, no la convención de ramificación.
Equipos muy grandes con propiedad del código inconsistente: En equipos de 50 o más personas donde cada squad tiene un servicio diferenciado, TBD funciona bien a nivel de servicio. Aplicarlo en un monorepo compartido donde todos tocan todo requiere convenciones estrictas de linting y reglas de propiedad de CI para mantener main limpio.
En los tres casos, la solución no es una estrategia de ramificación diferente. La solución es el problema de infraestructura subyacente. TBD simplemente hace visible ese problema más rápido.
Cómo migrar sin detener las entregas
La migración que la mayoría de los equipos hace mal: anuncian TBD, eliminan la convención de ramas de funcionalidad y ven cómo main se rompe en la primera semana.
Un camino más seguro:
Mantén las ramas existentes, añade una regla de duración: Ninguna rama vive más de 3 días. Esto fuerza la integración frecuente sin apagar las luces.
Instrumenta tu CI primero: Antes de que las fusiones vayan rápido, deben ser seguras. Suite de tests verde, ejecución en menos de 15 minutos, bloqueo de main en caso de fallo.
Elige una funcionalidad para proteger con un flag: Desarrolla el músculo de gestión de flags antes de necesitarlo para cada funcionalidad incompleta.
Reduce la duración de las ramas semana a semana: De 3 días a 2 días a 1 día en seis semanas. Rastrea la frecuencia de conflictos de fusión como indicador adelantado. Cuando baje, el modelo funciona.
Retira la convención antigua solo cuando la nueva funcione: Las convenciones de Gitflow permanecen para todo lo que está fuera del piloto. Ejecutar ambos modelos durante 6-8 semanas está bien.
El hábito que predice si el TBD se consolidará
El desarrollo basado en trunk no fracasa porque los equipos no puedan fusionar a main. Fracasa porque los desarrolladores no tienen el hábito de definir el trabajo con un alcance lo suficientemente pequeño para entregarlo en un día.
El cambio de fondo no es técnico. Es cómo se define el trabajo en la planificación. Una historia que dice "implementar el nuevo flujo de pago" es una rama de dos semanas esperando suceder. Una historia que dice "añadir el manejador de rutas y devolver un 501 detrás del flag payment-v2" es un commit de medio día.
Esto requiere la participación del PM y una higiene del backlog que la mayoría de los equipos no ha construido. El cambio de estrategia de ramificación lleva un día anunciarlo. La disciplina de alcance lleva seis meses construirla.
Si tu equipo ya entrega software funcionando a producción cada día, TBD formaliza lo que ya hacéis. Si tu equipo entrega cada dos semanas con una fusión masiva al final, TBD no será cómodo hasta que cambien los hábitos de entrega que hay debajo.
Los equipos que se consolidan con TBD invirtieron en tres cosas antes de cambiar: un pipeline de CI por debajo de 15 minutos, un servicio de feature flags funcionando y sprints que producen historias pequeñas de alcance diario. Sin esas tres, la convención de ramificación es la palanca equivocada.
Herramientas para equipos que trabajan con TBD
Ejecutar el desarrollo basado en trunk a nivel de equipo exige más sincronización: standups rápidos para detectar la divergencia en la integración, convenciones documentadas para flags y reglas de CI, y revisiones en pareja para los flujos críticos.