8. Trunk-Based Development: una sola línea principal
La idea central
En el módulo anterior viste Git Flow, con sus ramas largas (develop, release) y ciclos de
versión explícitos. Trunk-Based Development (TBD) propone lo opuesto: en lugar de mantener varias
ramas de vida larga, el equipo apunta a que casi toda la actividad converja en una única rama estable —
el trunk (casi siempre main).
Las ramas de trabajo existen, pero son extremadamente cortas: horas o un par de días como máximo. El objetivo es mergear a menudo, idealmente varias veces al día, apoyándose en integración continua (CI) que corre los tests automáticamente en cada cambio.
Principios de Trunk-Based
- Un solo lugar "oficial": no hay una segunda rama larga tipo
develop; el trunk es la fuente de verdad compartida del equipo. Todos los desarrolladores parten del trunk actualizado y devuelven sus cambios allí. - Ramas cortas (short-lived branches): una feature o fix vive en una rama durante horas o pocos días, no semanas. Cuanto antes se integra, menos diverge del trabajo del resto del equipo.
- CI obligatoria: cada push al trunk (o PR hacia él) dispara un pipeline que compila, testea y reporta. Si el pipeline está en rojo, nadie mergea más hasta arreglarlo.
- Despliegue frecuente: lo que está en trunk y pasó CI es candidato a desplegarse. Algunos equipos despliegan varias veces al día; otros tienen una ventana diaria o semanal, pero el código siempre está listo.
- Rama release opcional: algunos equipos TBD cortan una rama
release/x.ysolo si necesitan parches sobre una versión publicada específica. No es el núcleo del modelo; en CD puro se despliega directamente desde trunk.
Feature flags: código en producción, funcionalidad apagada
¿Cómo integrás una feature grande al trunk si todavía no está lista para que la vean los usuarios? La respuesta
habitual es feature flags (también llamados feature toggles): el código vive en
main pero está desactivado mediante una variable de configuración. Cuando el equipo decide
habilitarla, cambia un valor — sin deploy de código nuevo.
Los feature flags permiten que multiples equipos integren en trunk sin bloquearse entre sí: cada uno enciende su flag cuando está listo, y los releases de producción se convierten en decisiones de negocio independientes del ciclo de código.
Ejemplo: el equipo "Café API" con Trunk-Based
El mismo equipo del módulo anterior — Lucía, Mateo, Sofía, Diego y Valentina — adopta TBD para su microservicio de notificaciones (un componente nuevo con despliegue independiente).
Día a día TBD
- Mañana Sofía crea
feature/notif-push-draft, escribe la lógica base y abre un PR chico haciamain. CI pasa en verde. Lucía lo aprueba en minutos. Merge. - Tarde Mateo agrega la integración con el proveedor externo en otro PR pequeño, con tests. El flag
FLAG_NOTIF_PUSH=falsesigue apagado en producción. - Día siguiente Diego valida en staging con el flag activo. Todo ok. Valentina enciende el flag en producción — sin deploy de nuevo código. Los usuarios ven la funcionalidad.
- Emergencia Un bug aparece. Lucía apaga el flag en segundos. El equipo corrige en una rama de un día, merge a trunk, CI verde, flag vuelve a encenderse.
La clave: en ningún momento existió una rama larga. Todos los cambios convergieron a main de a
poco, siempre con CI verde, y el control del rollout estuvo en el feature flag — no en el ciclo de release.
⚠️ ¿Qué exige Trunk-Based?
- Suite de tests confiable: si CI no da garantías reales, mergear seguido al trunk rompe producción.
- Revisión rápida: PRs chicos necesitan aprobación en horas, no días. Si el proceso de code review es lento, las ramas se alargan y se pierde el beneficio.
- Cultura de integración continua: el equipo debe estar cómodo con "subir código antes de que la feature esté 100% visible".
- Infraestructura de flags (opcional pero muy útil): sin feature flags, las features grandes requieren disciplina extra para descomponerse en pasos integrables.
Quiz: Trunk-Based Development
Repasá los principios de TBD, feature flags y qué requiere este modelo para funcionar bien.
