Cuando diseñas la arquitectura de un proyecto grande, como el del Banco Interamericano de Desarrollo, una de las decisiones más críticas es cómo vas a mezclar las contribuciones del equipo en tu Version Control System. Definir reglas claras de colaboración en GitHub desde el inicio evita ramas eternas, commits ilegibles y bloqueos entre equipos técnicos y no técnicos.

¿Qué es Trunk Based Development y por qué usarlo?

La técnica que vas a aplicar sobre tu monorepositorio se llama Trunk Based Development, y su idea central es simple pero poderosa.

En lugar de mantener ramas largas que viven semanas, promueves pull requests pequeños, frecuentes y enfocados. Muchos desarrolladores contribuyen sobre una única rama principal, y los branches secundarios se mantienen lineales, con un propósito específico y una vida útil de uno o dos días máximo.

¿Qué es la cadencia en desarrollo de software? Es el ritmo con el que tu equipo entrega contribuciones integradas a la rama principal. Una buena cadencia significa ciclos cortos, predecibles y constantes.

Piensa en Trunk Based Development como un coach de natación: no te cambia el estilo completo, te corrige pequeños movimientos de los brazos para que avances más rápido sin romper tu técnica. Esos ajustes pequeños y continuos son los que terminan generando el mayor impacto.

¿Cómo proteger la rama principal con rulesets en GitHub?

GitHub te permite establecer reglas de negocio del ciclo de desarrollo mediante rulesets, que son políticas configurables sobre tus ramas.

Estas reglas pueden ser obligatorias o no, y aplicarse específicamente sobre la rama principal para validar cómo se contribuye a ella. Los tipos de validación que puedes activar incluyen:

• Validaciones de seguridad sobre el código que entra.
• Validaciones sobre el origen de la contribución.
• Validaciones sobre los comentarios y aprobaciones de otros miembros del equipo.

Al aplicar estas reglas, te aseguras de que cada merge respete la filosofía del Trunk Based Development y mantenga limpia la historia del repositorio.

¿Cómo afectan estas reglas al equipo no técnico?

Las reglas no solo ordenan al equipo de desarrollo, también ponen límites claros sobre el scope aceptable de las tareas que el equipo técnico puede entregar.

Esto le comunica al equipo no técnico qué cabe en un ciclo corto y qué no. Hace explícita la cantidad de trabajo alcanzable en uno o dos días, lo que facilita la planeación, las negociaciones de alcance y la comunicación abierta entre áreas.

¿Cómo configurar entornos para acelerar el trabajo?

Otra palanca para acelerar el desarrollo es definir entornos diferenciados, cada uno con sus propias reglas.

En el entorno de desarrollo puedes darle libertades al equipo: experimentar, romper cosas, iterar rápido. En cambio, en producción restringes las capacidades tanto del equipo técnico como del no técnico, y abres la puerta a despliegues automatizados.

Con un entorno de producción bien protegido, puedes integrar técnicas avanzadas de despliegue:

• Blue/Green deployment, que mantiene dos versiones paralelas para cambiar tráfico sin downtime.
• Canary deployment, que libera cambios a un porcentaje pequeño de usuarios antes de escalar.
• Despliegues automatizados que reducen errores humanos y aceleran la entrega.

¿Qué es Blue/Green deployment? Es una técnica donde mantienes dos entornos productivos idénticos. Uno sirve tráfico real mientras el otro recibe la nueva versión, y cuando está listo, intercambias el tráfico.

¿Existen alternativas a Trunk Based Development?

Sí, y elegir la correcta depende del tamaño del equipo, el volumen de trabajo y la madurez del proyecto. Las alternativas más comunes manejan ciclos más largos y múltiples ramas protegidas:

• GitFlow, con ramas separadas para features, releases y hotfixes.
• OneFlow, una versión simplificada de GitFlow con menos ramas permanentes.
• Feature Branch Workflow, donde cada funcionalidad vive en su propia rama hasta integrarse.

Ten en cuenta que estas reglas no son inmutables. Se deben adaptar a las capacidades del equipo, al volumen de trabajo y a la fase del proyecto. Pero tener reglas claras desde el principio facilita la colaboración, tanto de quienes ya están como de los nuevos miembros que se integran a un proyecto de gran envergadura.

¿Qué técnica has usado tú para mezclar contribuciones en tu equipo? Cuéntame en los comentarios qué problemas encontraste y cómo los resolviste.