Qué es trunk based development, visto desde un dev solo

¿Qué es trunk based development? Es un modelo de ramas en el que todos integran cambios pequeños en una única rama compartida, normalmente llamada main o trunk, al menos una vez al día. Las ramas, si las usas, viven horas y no semanas. El trabajo sin terminar se envía oculto detrás de un feature flag, así el trunk siempre se puede desplegar. Esa es la idea entera, y es menos exótica de lo que sugiere el nombre.

Así de concreto: abres un proyecto secundario que dejaste hace tres semanas. La rama de la feature va 41 commits por detrás de main, dos archivos tienen conflictos y lo que estabas construyendo ya no encaja con el código que lo rodea. Trunk based development es el hábito que evita esa escena.

Qué significa realmente trunk based development

La web de referencia trunkbaseddevelopment.com lo define como un modelo de control de versiones en el que los desarrolladores colaboran en una rama compartida y evitan otras ramas de desarrollo de larga vida. Los commits directos al trunk son válidos para equipos muy pequeños. Los pull requests también, siempre que las ramas de feature sean cortas y salgan del trabajo de un único desarrollador.

Tres reglas cargan con casi todo el peso.

• Integra en el trunk al menos una vez cada 24 horas.

• Mantén el trunk en verde: un build roto en main es la prioridad de todo el equipo.

• Oculta el trabajo incompleto con feature flags en lugar de dejarlo en una rama lateral.

Fíjate en lo que falta. No hay rama develop, no hay una rama de release larga por cada feature, no hay una fase de integración al final en la que todos descubren que su código no encaja. En los modelos antiguos, el dolor se acumula y se paga todo de golpe.

Por qué gana a las ramas de larga vida en la mayoría de equipos pequeños

Una rama de larga vida es un préstamo. Cada día que vive se aleja un poco más de main, y los intereses aparecen como conflictos de merge, suposiciones caducadas y reviews que nadie termina porque el diff toca 60 archivos.

La página de capacidades de DORA sobre trunk based development vincula estas prácticas con una mayor velocidad de entrega, estabilidad y disponibilidad, según su investigación State of DevOps. Ten tres ramas activas o menos en el repositorio. Integra en main al menos una vez al día. Evita los code freezes y las fases de integración. Son objetivos concretos y medibles, algo poco habitual en este campo.

Para un dev solo o un equipo de tres, el argumento es todavía más simple. Los merges pequeños son fáciles de revisar, fáciles de revertir y fáciles de entender seis meses después, cuando estás leyendo git blame a las 22h preguntándote qué pensaba tu yo de antes.

Tres razones para hacerlo, una para no hacerlo. Las razones: diffs más pequeños, feedback más rápido del CI y una main que puedes desplegar un viernes sin sudar. La razón en contra: si tus tests son flojos, integrar a diario solo propaga la rotura más rápido. Volvemos a eso más abajo.

¿Ramas cortas o commit directo a main?

Ambas opciones cuentan como trunk based development. La diferencia está en cuánta seguridad quieres antes de que el código entre.

Hacer commit directo a main funciona si estás solo o en pareja, tu build local tarda menos de un minuto y confías en tus tests. Es el bucle más rápido que existe. La mayoría de builders en solitario ya lo hacen sin llamarlo de ninguna manera.

Las ramas cortas con pull request tienen sentido cuando entra una segunda o tercera persona, o cuando quieres que el CI corra sobre un checkout limpio antes del merge. La disciplina está en la palabra corta. Una rama que sobrevive más allá del día siguiente ya va camino del modelo que intentas abandonar.

Una rutina práctica que aguanta:

• Actualiza main y crea una rama con un nombre que diga qué cambia.

• Haz el cambio más pequeño que haga avanzar las cosas y ejecuta el build local completo.

• Abre el PR, deja correr el CI y haz el merge el mismo día.

• Borra la rama. No dejes que se acumulen.

Si un cambio no cabe en un día, la respuesta no es una rama más larga. La respuesta es partirlo en rodajas más finas.

¿Cómo envías trabajo a medio terminar sin romper main?

Esta es la pregunta que frena a la mayoría. Si integras a diario, vas a integrar código de features que todavía no existen. Dos técnicas lo resuelven.

La primera es el feature flag. El nuevo camino de código se integra, pero apagado, así que los usuarios nunca lo ven. Un flag puede ser tan simple como un booleano en una variable de entorno:

const showNewCheckout = process.env.FEATURE_NEW_CHECKOUT === "true";

export function Checkout() {
  return showNewCheckout ? <NewCheckout /> : <OldCheckout />;
}

Para un side project basta. Cuando necesites segmentación, despliegues graduales o un kill switch sin volver a desplegar, un servicio gestionado se gana su sitio.

La segunda técnica es branch by abstraction, para cambios más grandes como sustituir un cliente de base de datos o un proveedor de pagos. Pones una interfaz delante de la implementación antigua, construyes la nueva detrás de la misma interfaz, mueves los llamadores poco a poco y después borras la vieja. Cada paso es un merge pequeño al trunk y nada se queda en una rama larga.

Una advertencia honesta sobre los flags: son deuda. Un flag que se queda en el código un año es una rama disfrazada. Dale a cada flag un dueño y una fecha de eliminación, y bórralo cuando la feature esté desplegada al 100 %.

Qué necesita tu CI antes de probarlo

Trunk based development sin red de seguridad es solo rotura rápida. Necesitas tres cosas antes de comprometerte con un hábito de merge diario.

• Un build que corra en cada push y termine en minutos, no en media hora.

• Tests que fallen cuando algo real se rompe. Los números de cobertura importan menos que si un cambio malo llega a detectarse.

• Una forma rápida de volver atrás: revertir el commit o apagar el flag.

El análisis estático es una capa extra barata. Detecta una clase de problemas, como bugs evidentes, malas prácticas de seguridad y código duplicado, antes de que una persona lea el diff.

Si eres el único revisor, las herramientas que señalan los puntos de riesgo ayudan todavía más, porque nadie más te dirá que el archivo que tocas una y otra vez se está convirtiendo en un desastre.

No hace falta un pipeline pesado el primer día. Un único workflow que instale, lintee, pruebe y despliegue main es un buen punto de partida. Funciona, no es óptimo, y vale la pena hacerlo igualmente: es la primera versión que funciona, y puedes afinarla después.

Ramas de release, hotfixes y lo que todavía requiere cuidado

Trunk based development no prohíbe las ramas de release. Algunos equipos cortan una rama desde el trunk justo antes de una release, la endurecen, la publican y la borran. Otros publican directamente desde el trunk y corrigen hacia delante cuando aparece un bug. Para una web que se despliega varias veces por semana, corregir hacia delante casi siempre es más sencillo.

Las apps móviles y todo lo que pase por una revisión lenta en una tienda son otra historia. Ahí puedes mantener una rama de release corta por versión para parchear lo que ya tienen los usuarios. Aun así, la regla se mantiene: las correcciones entran primero en el trunk y después se hacen cherry-pick, nunca al revés.

Los hotfixes siguen la misma lógica. Corriges en el trunk, despliegas, listo. Una rama de hotfix separada que nunca se fusiona de vuelta es la forma en que los equipos acaban con dos historias divergentes.

Una primera semana realista

Día uno: revisa cómo se ramifica tu repo hoy. Lista las ramas abiertas y anota la antigüedad de cada una. Todo lo que tenga más de unos pocos días es candidato a merge o a borrado. Con eso solo suele verse dónde está la fricción.

Día dos: añade el mecanismo de flags. Incluso una variable de entorno sirve. Elige una feature en curso, pon su punto de entrada detrás de un flag y luego integra lo que tengas.

Días tres a cinco: cambia el hábito. Corta cada tarea en piezas que puedan aterrizar en un día e integra cada pieza cuando pase el CI. Al principio, las primeras piezas parecerán demasiado pequeñas. No lo son. Un commit que añade una columna dormida en la base de datos o una función sin usar es una unidad de progreso perfectamente válida, porque es segura, revisada y ya está integrada.

Al final de la semana sabrás dos cosas: si tus tests son lo bastante fiables y qué partes de tu código se resisten a los cambios pequeños. Ambas son útiles, y ninguna aparece mientras trabajas en ramas largas.

No necesitas un dashboard para comprobarlo. Mira cuánto viven tus ramas, con qué frecuencia main está en rojo y cuánto tarda un cambio desde el primer commit hasta producción. Si la antigüedad de las ramas baja y los despliegues se vuelven aburridos, el hábito está dando resultado.

Si quieres números sobre el efecto en usuarios de lo que envías detrás de flags, una herramienta de experimentación puede vincular cada rollout a métricas reales en lugar de a la intuición.

Si eres un equipo de uno, una libreta sirve. Anota cada semana cuánto tarda un cambio desde el merge hasta el despliegue, durante un mes. La tendencia te dirá más que cualquier cifra suelta.

¿Cambiar o esperar?

Cambia si trabajas solo, en pareja o en un equipo pequeño con tests en los que confías a medias y un CI que puedes mejorar. El coste de probarlo es una semana de commits pequeños algo incómodos. El coste de seguir con ramas largas se paga en conflictos y reviews lentas, y crece con cada colaborador.

Espera si no tienes ningún test automatizado ni forma de volver atrás. Arregla eso primero, porque integrar a diario en un trunk sin tests solo traslada el dolor de sitio.

No es un método perfecto. Es uno que funciona. Elige el próximo cambio pequeño de tu proyecto actual, intégralo hoy y mira cómo se siente. ¿Cuál es la porción más pequeña de tu feature actual que podrías enviar antes de esta noche?