Trunk-based development

Cómo funciona

• Una única rama de larga vida (main o master), siempre en estado desplegable.
• Ramas de funcionalidad de horas o pocos días, con un pull request pequeño y revisión rápida; o commits directos en equipos muy pequeños que trabajan en pareja.
• El trabajo incompleto se integra oculto tras un feature toggle o mediante branch by abstraction.
• El pipeline de integración se ejecuta en cada cambio y, si se rompe, arreglarlo es la máxima prioridad.

DORA asocia el alto desempeño con tener tres o menos ramas activas, integrarlas en la principal al menos una vez al día y no tener periodos de congelación de código.

Comparación con GitFlow

Aspecto	GitFlow	Trunk-based
Ramas de larga vida	main, develop, release/*, hotfix/*	Solo main
Integración	Al cerrar la funcionalidad	Continua, diaria
Release	Rama de release estabilizada	Tag o despliegue desde main
Adecuado para	Software versionado con varias versiones mantenidas	Servicios desplegados continuamente

Branch by abstraction

Para un cambio grande (reemplazar el cliente HTTP del buró, cambiar el ORM):

1. Introduce una abstracción sobre el uso actual y migra los llamadores a ella.
2. Crea la nueva implementación detrás de la abstracción.
3. Cambia gradualmente los llamadores (o un toggle) a la nueva.
4. Elimina la implementación antigua y, si ya no aporta, la abstracción.

Cada paso se integra en main sin romper el build.

Prerrequisitos

Capacidad	Por qué
Suite de pruebas rápida	Integrar a menudo solo es seguro si el feedback llega en minutos
Revisión de código ágil	PR esperando dos días equivale a una rama larga
Feature toggles	Ocultar trabajo incompleto
Migraciones de BD compatibles	Patrón expand and contract en varios despliegues
Protección de rama	Checks obligatorios en CI antes del merge

Antipatrones frecuentes

• Llamar «trunk-based» a ramas de dos semanas con rebase diario.
• PR de 2 000 líneas: imposibles de revisar, se aprueban sin leer.
• Desactivar pruebas inestables en lugar de arreglarlas: el trunk deja de ser fiable.

Migrar desde GitFlow paso a paso

Paso	Acción	Duración típica
1	Medir la línea base: vida de ramas, tamaño de PR, tiempo de revisión	2 semanas
2	Acelerar el pipeline (objetivo < 10 min) y estabilizar pruebas inestables	Variable
3	Introducir feature toggles y acordar su uso	1–2 sprints
4	Limitar la vida de las ramas a 2 días; PR pequeños	Continuo
5	Integrar develop en main y eliminar develop	Un día
6	Releases desde main con tags; hotfixes también desde main	Continuo

Cambiar primero la estrategia de ramas sin pipeline rápido ni toggles produce frustración y vuelta atrás.

Protección de la rama principal

Regla	Motivo
Checks de CI obligatorios	Nada entra roto
Al menos una revisión aprobada	Revisión entre pares y segregación de funciones
Rama actualizada antes del merge (o merge queue)	Evita que dos PR verdes rompan juntos
Historial lineal (squash o rebase)	Historial legible; un commit por cambio
Sin push directo ni force push	Trazabilidad

Con muchas integraciones diarias, una merge queue (GitHub, GitLab) prueba cada PR sobre el estado real de la rama antes de integrarlo.

Releases y hotfixes

main ──●──●──●──●──●──●──●──●──
             │           │
          v1.8.0      v1.9.0        (tags; el despliegue continuo publica cada commit,
                                     o se publica desde un tag)

Hotfix: corregir en main → desplegar desde main.
Solo si hay que mantener una versión antigua (app móvil, cliente on-premise):
main ──●──●──●──●──
          └─ release/1.8 ──●(cherry-pick del fix)── v1.8.1

Las ramas de release, si existen, se crean justo antes de publicar, solo reciben cherry-picks desde main y nunca se integran de vuelta.

Revisión de código compatible con el ritmo

• Objetivo de primera revisión en horas, no días; franjas fijas de revisión en el equipo.
• PR de menos de unas 400 líneas cambiadas; si es mayor, dividir.
• Pairing o mob para cambios complejos, que sustituye a la revisión posterior.
• Automatizar lo mecánico (formato, lint) para que la revisión humana se centre en diseño y riesgos.

Criterios de implementación

Mide el tiempo de vida de las ramas y el tamaño de los PR antes y después. Acuerda un objetivo de revisión (p. ej. en menos de 4 horas laborables). Es la base para continuous deployment y mejora directamente el change lead time de las métricas DORA.