Trunk-Based Development — qué es, principios y trabajo en una sola rama

¿Qué es Trunk-Based Development?

Trunk-Based Development (TBD) es una metodología de gestión de versiones en la que todos los desarrolladores integran sus cambios en una única rama principal (trunk, main o master) varias veces al día. A diferencia de Git Flow con sus ramas de funcionalidad de larga duración, TBD minimiza el tiempo de vida de las ramas a unas pocas horas, raramente a 1–2 días. El objetivo principal es evitar el “infierno de fusión” (merge hell), cuando una gran funcionalidad se fusiona con el trunk después de semanas de desarrollo.

Según Google Cloud DevOps, 2024, Trunk-Based Development es una de las prácticas clave de los equipos DevOps de alto rendimiento. El State of DevOps Report (Puppet, 2023) mostró que los equipos que usan TBD se recuperan un 30% más rápido de los fallos y se enfrentan un 50% menos a defectos críticos en producción. TBD es obligatorio para Continuous Deployment.

Trunk-Based Development no significa que los desarrolladores hagan commits directamente al trunk sin revisión. En TBD se usan ramas de funcionalidad de corta duración que, tras crear un MR y una revisión de código rápida (en unas horas), se fusionan al trunk. Si la revisión lleva más de un día, la funcionalidad debe dividirse en partes más pequeñas.

State of DevOps Report: datos sobre TBD

El State of DevOps Report anual (Puppet/DORA) rastrea las prácticas de los equipos de alto rendimiento. Desde 2015, TBD está entre las 3 prácticas principales correlacionadas con una alta frecuencia de despliegue (deploy frequency) y un bajo tiempo de recuperación (MTTR). Los equipos que practican TBD despliegan código 2–3 veces más a menudo y se recuperan un 30% más rápido (DORA, 2023).

Feature Toggles: gestión de código incompleto sin ramas

Feature Toggles (banderas de funcionalidad, feature flags) son un mecanismo para activar y desactivar funcionalidades sin cambiar el código. En TBD, los feature toggles reemplazan las ramas de funcionalidad: el desarrollador envía código incompleto al trunk pero lo oculta detrás de una bandera condicional. Cuando la funcionalidad está lista para mostrarse, la bandera se cambia en la configuración sin necesidad de un nuevo despliegue.

Según Martin Fowler, 2024, los feature toggles se dividen en cuatro tipos: release toggles (gestión de visibilidad de funcionalidad), experiment toggles (pruebas A/B), ops toggles (gestión de parámetros operativos) y permission toggles (acceso por roles). En proyectos móviles, los release toggles son especialmente útiles: la nueva funcionalidad está oculta hasta la fecha de lanzamiento, pero el código ya está en el trunk y pasa por CI/CD.

// Feature Toggle en Android con Kotlin
object FeatureManager {
    private val remoteConfig = FirebaseRemoteConfig.getInstance()

    fun isEnabled(key: String): Boolean {
        return remoteConfig.getBoolean(key)
    }
}

// Uso en código
if (FeatureManager.isEnabled("new_checkout_flow")) {
    showNewCheckoutScreen()
} else {
    showOldCheckoutScreen()
}

CI/CD en Trunk-Based Development: prácticas obligatorias

Continuous Integration (CI) es el componente más importante de TBD. Cada push al trunk (o a una rama temporal antes del MR) desencadena un pipeline completo: compilación, pruebas unitarias, pruebas de integración, linters, análisis estático, verificación de cobertura de código. Si al menos una etapa falla, el autor corrige el código antes del siguiente commit. “Trunk roto — desarrollo detenido” es la regla principal de TBD.

Según Jez Humble, Continuous Delivery, 2024, Trunk-Based Development requiere un pipeline de CI que se ejecute en 10–15 minutos. Si la compilación tarda más, los desarrolladores hacen commits con menos frecuencia, lo que destruye el sentido de TBD. En proyectos móviles, las compilaciones de Android e iOS pueden durar 20–30 minutos, lo que hace que TBD sea menos conveniente. En tales casos, los equipos usan Short-Lived Feature Branches (ramas de 1 día) con CI inmediato.

# GitHub Actions para TBD (Android)
name: CI - TBD Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew testDebugUnitTest
      - name: Static analysis
        run: ./gradlew ktlintCheck detekt

Ramas de corta duración: reglas de trabajo en TBD

Las ramas de corta duración (short-lived branches) son un compromiso entre el TBD puro (commits directos al trunk) y Git Flow. Una rama vive no más de 1–2 días, contiene cambios de 1–3 commits y después de la revisión (no más de 4 horas de espera) se fusiona al trunk. Si una funcionalidad requiere más tiempo, se divide en subtareas, cada una con su propia rama de corta duración.

Según TBD Documentation, 2024, las reglas de las ramas de corta duración: la rama se crea desde un trunk fresco (no mayor de 1 hora), no se sincroniza con el trunk mediante merge/rebase (si han pasado más de 4 horas, se crea una nueva rama), el MR/PR se crea inmediatamente después del primer commit (incluso si el trabajo no está completo — como Draft).

Pre-tested commits: commits con garantía

Para Trunk-Based Development es importante la técnica de pre-tested commits: el desarrollador ejecuta el pipeline de CI en su rama antes de hacer el commit, y solo después de un estado verde el commit llega al trunk. En GitLab, esto se implementa mediante Merge Request pipelines con la opción “Merge when pipeline succeeds”. En GitHub, mediante branch protection rules con Required status checks. Esto garantiza que el trunk nunca contenga código roto.

• 1–2 días — tiempo máximo de vida de una short-lived branch
• 1–3 commits — tamaño óptimo de cambios
• 4 horas — tiempo máximo de espera de revisión de código
• Crea el MR inmediatamente después del primer commit, incluso en estado Draft

Branch by Abstraction: reemplazo de código sin ramificación

Branch by Abstraction es una técnica que permite reemplazar o cambiar significativamente una parte del sistema sin crear una rama de funcionalidad de larga duración. En lugar de ramificar en Git, el desarrollador crea una abstracción (interfaz) bajo la cual funcionan tanto la implementación antigua como la nueva. Gradualmente, todos los consumidores se trasladan a la nueva implementación, después de lo cual se elimina la antigua.

Según Branch by Abstraction, 2024, las etapas de Branch by Abstraction: 1) crear una abstracción para el componente a reemplazar, 2) implementar la nueva versión bajo la abstracción, 3) cambiar los consumidores a la nueva implementación mediante configuración, 4) eliminar la implementación antigua. Todos los pasos se confirman en el trunk en pequeñas porciones, cada una de las cuales no rompe CI/CD.

TBD vs Git Flow: comparación de enfoques

Trunk-Based Development y Git Flow son dos enfoques opuestos para la gestión de ramas. Git Flow usa ramas de larga duración y una jerarquía estricta, TBD usa una sola rama y ciclos de integración cortos. La elección entre ellos depende del tamaño del equipo, la frecuencia de lanzamientos y el nivel de automatización de CI/CD.

Errores típicos al implementar Trunk-Based Development

Los errores de TBD suelen estar relacionados con un CI/CD insuficiente o una débil disciplina de commits. El primer error es implementar TBD sin CI, que se rompe desde el primer commit fallido. Si el trunk no se puede reparar en 15 minutos, el equipo pierde la confianza en el proceso y vuelve a las ramas largas. El segundo es permitir ramas de larga duración “solo para esta funcionalidad”, lo que destruye todo el concepto.

Según Paul Hammant, 2023, el tercer error es la mala modularidad del código. Trunk-Based Development requiere que el código esté dividido en módulos independientes. Si un cambio en una clase rompe otros tres módulos, los desarrolladores no pueden hacer commits en pequeñas porciones. El cuarto es ignorar los feature toggles: intentar enviar código incompleto sin una bandera provoca la rotura del trunk para todo el equipo.

Trunk-Based Development en el desarrollo móvil

Trunk-Based Development en proyectos móviles tiene particularidades debido a los largos tiempos de compilación (20–30 minutos para Android e iOS) y los estrictos requisitos de calidad. Google y Spotify usan TBD en el desarrollo móvil, aplicando ramas de corta duración con CI obligatorio antes de la fusión. Los feature toggles se gestionan a través de Firebase Remote Config o LaunchDarkly.

Según LaunchDarkly Docs, 2024, en el desarrollo móvil, TBD ofrece una ventaja: las funcionalidades se prueban en el trunk junto con el resto del código antes de la fecha de lanzamiento, lo que reduce el riesgo de problemas de integración. Si el pipeline de CI lleva más de 15 minutos, son óptimas las ramas de corta duración de 1 día con CI automático en cada push. Para Apple App Store y Google Play, TBD requiere la configuración de implementaciones graduales mediante feature toggles.

Feature Flags como servicio: LaunchDarkly y Firebase

Para gestionar los feature toggles en TBD se utilizan plataformas: LaunchDarkly (enterprise, con todas las funciones), Firebase Remote Config (gratuito para proyectos pequeños), Split.io (código abierto). Proporcionan: activación selectiva de funcionalidades por porcentaje de usuarios, pruebas A/B, monitoreo de uso y desactivación automática en caso de errores. En proyectos móviles, Firebase Remote Config es la opción más popular debido a su integración con Firebase y su umbral gratuito de hasta 1000 usuarios.