# Que es el desarrollo basado en trunk y cómo usarlo URL: https://codebasechat.com/es/journal/que-es-el-desarrollo-basado-en-trunk Type: blog Locale: es Published: 2026-09-22 Updated: 2026-09-22 --- > El desarrollo basado en trunk elimina las ramas de larga duración. Todos los devs integran a main al menos una vez al día, usando feature flags para ocultar el trabajo incompleto. 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 ![Manos de desarrollador en un teclado con un panel de feature flags visible en pantalla](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/283060-inline1.webp) 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 ![Dos ingenieros haciendo revisión de código en pareja frente a una pantalla compartida](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/7ec1d3-inline2.webp) La [investigación State of DevOps de DORA](https://dora.dev/research/) 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á ![Ingeniero monitorizando paneles de pipeline CI/CD con indicadores de estado de despliegue en verde](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-09/0e3fc0-inline3.webp) 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. ## FAQ ### ¿Qué diferencia hay entre el desarrollo basado en trunk y Gitflow? En el desarrollo basado en trunk todos los devs integran a main cada día, usando feature flags para el código incompleto. Gitflow usa ramas de larga duración y reserva main para versiones estables. TBD prioriza la frecuencia de integración; Gitflow prioriza el aislamiento de releases. ### ¿Por qué son necesarios los feature flags en TBD? Los feature flags permiten que el código llegue a producción sin que la funcionalidad sea visible para los usuarios. Esto desacopla el despliegue del lanzamiento: el equipo integra continuamente sin esperar a que cada feature esté 100% terminada. ### ¿Qué dicen las métricas DORA sobre el desarrollo basado en trunk? DORA identifica el TBD como una de las 24 capacidades que predicen el rendimiento en la entrega de software. Los equipos élite que despliegan múltiples veces al día integran de forma continua. Las ramas de larga duración aparecen consistentemente en el extremo de bajo rendimiento de su distribución. ### ¿Es el desarrollo basado en trunk adecuado para equipos grandes? En equipos de 50 o más personas, TBD funciona bien a nivel de servicio individual. En un monorepo compartido requiere convenciones estrictas de CI y propiedad del código. El tamaño del equipo no es el obstáculo principal: lo son la calidad de los tests y la disciplina en el alcance de las historias. ### ¿Cuánto tiempo lleva migrar a TBD desde Gitflow? Una migración gradual tarda entre 6 y 8 semanas. La secuencia recomendada: establecer una regla de duración máxima de ramas, asegurar un CI verde y rápido, añadir feature flags en un piloto, y reducir la duración de las ramas progresivamente semana a semana. ### ¿Qué ocurre si alguien rompe main en un equipo TBD? Con CI configurado correctamente, una rotura en main se detecta en minutos. La práctica habitual es revertir el commit problemático de inmediato y luego investigar. En equipos maduros de TBD, el tiempo medio de restauración de main suele ser inferior a 10 minutos.