Trunk-Based Development

Trunk-Based Development (TBD) es una estrategia de control de versiones donde los desarrolladores colaboran en una única rama principal (trunk/main) haciendo commits pequeños y frecuentes.

Puntos importantes

Trunk-Based Development (TBD) se apalanca en una rama de larga duración (trunk o main) sobre la cual se articula todo el ciclo de desarrollo: procesos, ambientes, cambios, rollbacks y despliegues se orquestan siempre a partir de esta rama principal.

En TBD, los pull requests se gestionan mediante ramas feature efímeras, clonadas desde el trunk. Estas ramas tienen un ciclo de vida corto, se integran rápidamente y evitan la proliferación de ramas de larga duración, reduciendo complejidad y conflictos de integración.

A partir de los commits en trunk se generan artefactos versionados (por ejemplo, imágenes Docker, JAR, etc.) que se promueven a los distintos ambientes (DEV, QA, UAT y PROD). Para ello se utilizan tags asociados a esos commits, que versionan entregables específicos y habilitan una trazabilidad clara de cada despliegue dentro del ciclo de vida de desarrollo.

Este modelo demanda un nivel elevado de disciplina y madurez técnica del equipo, dado que todos trabajan sobre la misma rama y deben mantenerla en estado constante de “listo para desplegar”, respaldada por integración continua y validaciones automatizadas.

En contextos de alta demanda de producto, donde se requieren liberaciones frecuentes o incluso diarias, TBD habilita una promoción ágil y eficiente de cambios, incrementando velocidad, efectividad y calidad sobre una única rama, una única aplicación y un objetivo común.

La promoción entre ambientes se ejecuta a partir de tags creados sobre main y vinculados a un artefacto específico, los cuales actúan como identificadores únicos de la versión y se despliegan de forma consistente a lo largo de toda la cadena de entornos.

Principios Fundamentales

• Una rama principal: Todo el código converge en main o trunk
• Commits frecuentes: Integración diaria o incluso varias veces al día
• Ramas de vida corta: Si se usan, duran menos de 24 horas
• Feature flags: Para código no listo sin bloquear integraciones
• CI/CD obligatorio: Tests automáticos en cada commit

Independencia: Versionamiento vs Despliegue

⚠️ IMPORTANTE: El flujo de versionamiento del código (TBD) NO afecta el flujo de despliegue a ambientes.

Separación de responsabilidades

Beneficios de TBD

✅ Para Desarrollo

• Menos conflictos: Integraciones frecuentes evitan merge hell
• Feedback rápido: CI/CD detecta problemas en minutos
• Simplicidad: Sin gestión compleja de ramas
• Colaboración: Todo el equipo ve el código actualizado

✅ Para CI/CD

• Continuous Integration real: Tests en cada commit
• Deployment más simple: Siempre desde main
• Rollback fácil: Solo revertir commit en main
• Pipeline lineal: Sin esperar merges de múltiples ramas

✅ Para el Negocio

• Time to market: Features a producción más rápido
• Menor riesgo: Cambios pequeños son más seguros
• Calidad: Tests obligatorios en cada integración

Estrategias de Release con TBD

Descripción:

• Despliegues a PROD en fechas fijas (ej: viernes cada semana)
• Los commits van a main continuamente
• Solo lo que está en main el viernes va a PROD

Release on Demand (Bajo Demanda)

Descripción:

• main siempre está listo para producción
• Deployamos cuando queramos/necesitemos
• Requiere Feature Flags para funcionalidades incompletas

Continuous Deployment (Despliegue Continuo)

Descripción:

• Cada commit a main va automáticamente a PROD
• Requiere alta madurez en tests y monitoring
• Feature Flags obligatorios

Feature Flags en TBD

¿Por qué son esenciales?

Problema sin Feature Flags:

// Código a medio hacer va a main y se despliega
function newFeature() {
  // TODO: implementar validación
  // TODO: manejar errores
  saveToDatabase(data); // PELIGRO: incompleto en PROD
}

Solución con Feature Flags:

function processCheckout() {
  if (featureFlags.isEnabled('new-checkout-flow')) {
    return newCheckoutFlow(); // Solo para beta users
  }
  return oldCheckoutFlow(); // Usuarios normales
}

Tipos de Feature Flags

1. Release Flags: Ocultar features incompletas
2. Experiment Flags: A/B testing
3. Ops Flags: Circuit breakers, kill switches
4. Permission Flags: Features por roles

Consideraciones para el Equipo

• Commits pequeños y frecuentes
• Tests obligatorios
• Uso de feature flags
• Pull Requests rápidos (menos de 2 horas de review)

Mejores Prácticas

✅ DO's

1. Commit al menos una vez al día a main
2. Escribe tests antes de cada commit
3. Usa feature flags para trabajo en progreso
4. Reviews rápidos de PR (menos de 2 horas)
5. Mantén main siempre desplegable

❌ DON'Ts

1. No crear ramas de larga vida (más de 24 horas)
2. No hacer commits grandes (más de 500 líneas)
3. No pushear código sin tests
4. No esperar días para integrar
5. No confundir versionamiento con despliegue

Herramientas Recomendadas

Feature Flags

• LaunchDarkly: Solución empresarial completa
• Unleash: Open source, self-hosted
• Flagsmith: Open source con cloud option
• ConfigCat: Sencillo y económico

CI/CD

• GitHub Actions: Integrado con GitHub
• GitLab CI: Pipelines poderosos
• Jenkins: Flexible y extensible
• CircleCI: Rápido y confiable

Monitoreo

• Datadog: Observability completa
• New Relic: APM y monitoring
• Sentry: Error tracking
• Prometheus + Grafana: Open source

Conclusión

Trunk-Based Development simplifica el versionamiento del código mientras permite mantener cualquier flujo de despliegue (DEV → QA → UAT → PROD). La clave está en:

1. Separar conceptos: Versionamiento ≠ Despliegue
2. Feature Flags: Para desarrollo seguro e incremental
3. CI/CD robusto: Tests automáticos obligatorios
4. Cultura de equipo: Commits frecuentes y reviews rápidos

El resultado: código más limpio, menos conflictos, y entregas más rápidas.