La llegada de Git trajo consigo una nueva era en el desarrollo de software, caracterizada por el descubrimiento de enfoques innovadores para crear aplicaciones. Uno de estos enfoques es Gitflow, un modelo de desarrollo basado en ramas. Aunque este modelo ofrece ventajas, la integración del trabajo en él plantea desafíos en cuanto al feedback de los desarrolladores, especialmente en cuanto al momento y la frecuencia en que se recibe.
Una alternativa poderosa: Trunk-Based Development (TBD)
A diferencia del enfoque de Branch Based Development, el Trunk-Based Development (TBD) no involucra múltiples etapas y, con el objetivo de minimizar conflictos, opera en estrecha proximidad a la fuente primaria de código. Esta metodología se alinea especialmente con organizaciones en constante evolución, poniendo de nuevo en primer plano la colaboración con el cliente en el paradigma ágil. En última instancia, el foco se centra en maximizar el valor del código en producción, en lugar de en el entorno de preparación (staging environment).
El origen histórico del TBD
El Trunk-Based Development tiene raíces más profundas de lo que podría parecer. Se remonta a sistemas como CVS (Concurrent Version System) y SVN (Subversion), donde predominaba la filosofía de "todos trabajan en un tronco, con algunas ramas de corta duración destinadas a la corrección de errores (bugs) o al desarrollo experimental".
Autores de la década de los 90, incluido Jez Humble, coautor de libros como "The DevOps Handbook", "Lean Enterprise" y "Continuous Delivery", ya hablaban sobre el control de versiones y la importancia de obtener feedback rápido para evitar ramificaciones prolongadas. Esto demuestra que el Trunk-Based Development no es un concepto nuevo, sino una evolución de ideas previas.
Prácticas claves para implementar el TBD en tu equipo
A continuación, presentamos una recopilación de prácticas claves basadas en nuestra experiencia para implementar con éxito el Trunk-Based Development en tu equipo. Algunas de estas prácticas pueden formar parte de tu flujo de trabajo actual, mientras que otras pueden resultar nuevas. Te invitamos a probarlas y compartir tus opiniones.
¡Comencemos!
Desarrollando la mentalidad adecuada
El primer paso crucial es asegurar que el equipo esté alineado en la adopción del Trunk-Based Development y las prácticas que lo acompañan. Después de todo, si el equipo no está comprometido, existe una alta probabilidad de que la implementación fracase.
- Trabajar sin miedo: en la base del Trunk-Based Development se encuentra la capacidad de adaptarse a cambios rápidos. Fomentar una cultura que evite culpar a los desarrolladores por errores ayuda a eliminar el temor a realizar cambios por miedo a romper cosas.
- Priorizar la funcionalidad: el código es la fuente de verdad. Mostrarlo con frecuencia y en cualquier momento es más valioso que cualquier presentación o charla.
- Evitar la búsqueda de la perfección: enfocarse solo en la perfección puede bloquear el flujo de trabajo y retrasar integraciones. Se debe tener en cuenta que la mejora constante vendrá con el tiempo.
Fomentando la colaboración
El Trunk-Based Development fomenta la colaboración y la propiedad colectiva del código, lo cual es vital para el éxito de este enfoque.
- Cambiar "mi" por "nuestro": adoptar una mentalidad de equipo en lugar de centrarse en tareas individuales promueve la contribución conjunta y la responsabilidad compartida.
Automatización: la base del TBD
Un pipeline de integración y entrega continua (CI/CD) confiable es fundamental en el entorno de Trunk-Based Development. Facilita la detección temprana de problemas y agiliza el proceso de desarrollo.
- Despliegue azul-verde en la nube: optar por esta estrategia de despliegue proporciona un entorno seguro para la entrega continua y una experiencia fluida para los usuarios finales.
Toggles: controlando el flujo de cambios
Los toggles se convierten en aliados cruciales para los desarrolladores, permitiendo la incorporación de cambios sin necesidad de despliegues masivos.
- Comenzar con el toggle apagado: iniciar con esta configuración y posteriormente activarla y evaluar su desempeño es una buena práctica.
- Pequeños lotes con mayor frecuencia: activar toggles para un grupo limitado de usuarios minimiza el riesgo y agiliza la integración de cambios.
Work in progress constante: una filosofía de integración continua
El work in progress es el paradigma central del TBD. Esta metodología elimina la necesidad de congelar el código para revisar grandes cambios y reduce el tiempo de inactividad asociado con la integración de modificaciones.
- Demos y retroalimentación de usuarios en producción: realizar demos y recopilar comentarios directamente en el entorno de producción genera una experiencia más auténtica.
Monitorización para el éxito
El monitoreo es fundamental para el éxito del TBD, y la práctica del registro (logging) juega un papel crucial en esta metodología.
- Logs en tiempo real: brindan una visión inmediata de la actividad de la aplicación, proporcionando feedback inmediato.
- Lagging logs: facilitan el seguimiento y análisis de eventos pasados.
Alineando con el Trunk-Based Development puro: ramas de corta duración
Si bien el enfoque ideal del TBD implica hacer push directamente al tronco, las ramas de corta duración pueden ser útiles para pruebas y correcciones, al guardar el trabajo al final del día o cuando se cambia de rol durante las sesiones de pairing. Si es necesario, estas ramas pueden fusionarse de nuevo en el tronco mediante la creación de un "pull request".
- Duración limitada de las ramas: para evitar desviarse del propósito del TBD, las ramas de corta duración deben eliminarse en un plazo máximo de 48 horas. Normalmente, un desarrollador (o dos en caso de pairing) debería encargarse de contribuir a estas ramas.
- Fusión cuidadosa en el tronco: la integración de estas ramas debe ser minuciosa para mantener la integridad del código base. Se considera el paso final y una vez realizada la fusión, la rama debe ser eliminada.
Desafíos en el desarrollo profesional
A pesar del entusiasmo en torno al Trunk-Based Development y sus ventajas para equipos ágiles, persiste la resistencia al cambio. En la última década, los desarrolladores han sido formados para operar en diversos entornos, completando tareas de desarrollo, calidad y producción. La perspectiva de adoptar TBD puede generar inquietud debido al temor a afectar la producción, un desafío común a todos los desarrolladores, sin importar su especialización. Esto resalta la importancia de considerar el aspecto humano en el desarrollo de software, especialmente en entornos dinámicos.
Extreme Programming, con su conjunto de valores, sienta las bases para equipos de alto rendimiento. La segunda edición de XP, liderada por Kent Beck, introduce el valor del respeto, junto con el feedback, la sencillez, la comunicación y la valentía.
A menudo, los equipos carecen del valor y respeto necesarios para adoptar prácticas como TBD. Sin embargo, nuestro consejo es que, si tienes la oportunidad, explores este enfoque y su potencial.
Este blog fue escrito colaborativamente por Matheus Marabesi, Fernando del Caz, Javier Chacana y Arturo Menéndez, nuestros software craftpersons . Si quieres saber más sobre ellos, visita la página de Nuestro Equipo.
