Trunk-Based Development
¡Hola a todos!
Generalmente utilizamos algún flujo git como estrategia de desarrollo en nuestros equipos. Normalmente 3 ramas:
- main o master
- Código que corre en producción
- Protegida
- Generalmente utilizada solo para hacer el deploy, pues todas las pruebas fueron hechas en la rama de staging.
- staging o release
- Código que corre en ambiente de staging (pre-producción)
- Protegida
- Utilizada para pruebas de funcionalidad en condiciones reales, detección de bugs y problemas, validación de configuraciones, prueba de integración, carga, etc.
- develop
- Sumatorio de las nuevas funcionalidades viniendo de todos los equipos y hotfixes encontrados en producción.
Generalmente tenemos un flujo parecido a esto que es la idea del gitflow y muy bien aceptada hoy en día.
¿Pero ya escuchaste hablar de la estrategia Trunk-Based Development (TBD)?
Trunk-Based Development (TBD) es una estrategia de desarrollo de software en la que todos los desarrolladores colaboran en una única rama principal (generalmente llamada "trunk" o "master/main") y hacen commits frecuentes directamente en ella.
Exige mucho más concentración y rigor y por eso se recomienda un pipeline de CI depurado en el trunk.
En el caso de proyectos open source, los desarrolladores no pueden crear ramas en el repositorio donde tenemos el trunk. El desarrollador está obligado a crear un fork del proyecto y después, cuando finalizada su contribución, crear un PR trunk to trunk o mantener su fork actualizado con el fork del proyecto principal y desarrollar en una rama en su repositorio y pedir crear el PR.
Los desarrolladores trabajando en sus propios repositorios no rompen la compilación con ningún commit. Es función de los desarrolladores asumir el hábito de probar que el commit es bueno.
En un proyecto empresarial podemos crear ramas en el mismo repositorio para desarrollo de las features y hacer un PR directo para el trunk.
Un trabajo solamente es considerado concluido si está mergeado en el trunk del proyecto principal.
Nuevas ramas serán creadas por los mantenedores del repositorio para una rama de release que vivirá por un período pequeño. Esta rama será sustituida por otra rama de release en el futuro, o no, caso quiera mantener el histórico dependiendo del proyecto.
No existe una regla bien definida, ya vi casos que solamente son creadas tags para marcaciones sin ramas de release.
Aún es posible que exista solamente una rama trunk y punto final, todo depende del tipo de proyecto.
En caso de usar ramas de release, un bug debe ser corregido en el trunk y fusionado a la rama de release solamente por los mantenedores.
Trabajar con TBD en Git exige una cultura de desarrollo disciplinada, con prácticas como code reviews, pruebas automatizadas rigurosas y una buena comunicación entre el equipo, pero los beneficios en términos de calidad y velocidad de entrega pueden ser significativos. Un pipeline robusto es extremadamente necesario.
Ventajas
-
Integración Continua y Rápida
: Como todos están trabajando en la misma rama, los cambios son integrados frecuentemente, lo que ayuda a detectar problemas de integración rápidamente. Esto reduce el riesgo de sorpresas desagradables al final del ciclo de desarrollo. -
Simplicidad en el Control de Versión
: Con menos ramas long-lived, la gestión del repositorio se vuelve más simple y fácil de mantener. Esto reduce el overhead de merges complejos y conflictos difíciles de resolver. -
Feedback Rápido
: Los cambios son probados e integrados de forma continua, permitiendo que problemas sean identificados y corregidos rápidamente. Esto acelera el ciclo de feedback y aumenta la calidad del código. -
Facilita el DevOps y el Continuous Delivery
: TBD es una práctica que se alinea bien con las prácticas de DevOps, como Continuous Integration (CI) y Continuous Deployment (CD), ya que el código está siempre en un estado listo para deploy. -
Reducción de Ramas Largas y Conflictos de Merge
: Como el foco está en commits frecuentes en la rama principal, evitas la creación de long-lived branches que pueden causar grandes conflictos de merge. Esto también reduce la posibilidad de "merge hell". -
Estimula la Colaboración
: TBD incentiva la colaboración y la comunicación frecuente entre los miembros del equipo, ya que todos están constantemente revisando e integrando el trabajo de los demás. -
Agilidad en la Resolución de Bugs
: Los bugs pueden ser corregidos rápidamente, sin la necesidad de hacer cherry-pick o backport para otras ramas, ya que el código está centralizado. -
Mayor Transparencia y Visibilidad
: Con todos trabajando en la misma rama, es más fácil para todos los miembros del equipo tener visibilidad del estado actual del proyecto.
Desventajas
-
Riesgo de Inestabilidad en la Rama Principal
: Como todos los desarrolladores están haciendo commits frecuentes en la misma rama, hay un mayor riesgo de introducir bugs o problemas que afectan a todo el equipo. Esto puede causar inestabilidad, especialmente si las pruebas no son rigurosas. -
Mayor Necesidad de Disciplina y Buenas Prácticas
: El equipo necesita tener una disciplina rigurosa en relación a prácticas como code reviews, pruebas automatizadas y control de calidad. Recomiendo el uso de sonarqube para ayudar en el proceso de calidad. -
Complejidad en Equipos Grandes
: Puede ser difícil coordinar y gestionar el trabajo sin que ocurran conflictos frecuentes con personas trabajando en el mismo punto del código. -
Dependencia de Pruebas Automatizadas Fuertes
: TBD depende fuertemente de una suite de pruebas automatizadas robusta. Si las pruebas no son suficientemente abarcadoras o si hay falsos positivos/negativos estos serán integrados a la rama principal. -
Menos Aislamiento de Funcionalidades
: En metodologías donde se usa feature branches, las nuevas funcionalidades pueden ser desarrolladas y probadas de forma aislada antes de ser integradas, no en el caso del TBD. -
Dificultad en Gestionar Releases
: En proyectos donde hay necesidad de gestionar múltiples versiones o releases simultáneos, TBD puede ser más desafiante, pues todos los cambios van directo a la rama principal. Esto puede complicar la creación de hotfixes o versiones anteriores. No es muy recomendado para este escenario. -
Curva de Aprendizaje
: Para equipos acostumbrados a trabajar con long-lived branches y merges tradicionales, la transición a TBD puede exigir un cambio significativo en la mentalidad y en las prácticas de trabajo, lo que puede llevar algún tiempo para adaptarse y onboardings mayores y más entrenamiento por parte de la empresa. -
Menos Flexibilidad en Ciclos de Desarrollo
: En escenarios donde ciertas funcionalidades necesitan ser lanzadas separadamente o en cronogramas diferentes, el enfoque de TBD no está muy bien adaptado.