Salir más de 10 veces a producción en un día y no morir en el intento.
Estamos en tiempos en donde escuchamos hablar de microservicios, contenerización, integración continua y agilismo. Si bien son temas muy interesantes, lo que es realmente relevante para una compañía es lograr entregas de valor a la mayor velocidad posible con seguridad y calidad.
Y es que esas entregas de valor pueden ser tan pequeñas como un cambio en la UI, o por ejemplo, la mejora de un servicio para que sea más seguro y robusto.
¿Cómo lograrlo y no morir en el intento? 💀
Desde Bancolombia implementamos diferentes estrategias para lograr varios despliegues a producción al día, una de las más importantes es el flujo en el control de versiones.
Cómo:
Si bien hay muchas formas de llevar el control de versiones de nuestros repositorios como Git Flow, GitHub Flow, One Flow, Forking WorkFlow, GitLab Flow y Trunk Base Development, identificamos que con Trunk Base Development (TBD) podemos lograr entregas continuas de valor de una forma mucho más ágil, apoyados en la automatización y en las buenas prácticas en el desarrollo de software.
Pero bien, ¿qué es TBD?
Trunk Base Development lo podríamos describir como un estándar para la gestión de código fuente, que tiene como objetivo mejorar la integración continua, usando una sola rama principal en el repositorio (trunk).
Branches
Con TBD contamos con una rama principal (trunk) que debería contar con políticas de pull request y triggers para que se ejecuten automáticamente los pipelines definidos. En nuestro caso, la rama trunk es la rama equivalente a máster en el modelo Git Flow y adicional a esto, contamos con ramas temporales (features).
Como la duración de estas ramas debe ser muy corta, una vez finalizado el feature, esta rama debe integrarse a la rama principal y debe eliminarse la rama temporal. También es importante tener un estándar para el nombramiento de las ramas temporales, buscando dar mayor claridad al equipo de trabajo.
Debemos evitar ramas feature de larga duración para garantizar la integración continua sobre la rama principal. La idea es realizar entregas de valor rápidas y pequeñas para obtener una retroalimentación temprana.
Pull Request
Los pull request son útiles para contribuir en proyectos open source y para gestionar cambios en repositorios compartidos. Además, incentivan la revisión del código y fomentan discusiones que permiten obtener un feedback temprano para los desarrolladores, antes de que los cambios sean integrados en la rama principal.
Deploy
Una vez aprobado el pull request y realizadas las validaciones respectivas, se hace el despliegue. Siempre que algo inesperado ocurra, se debe hacer un rollback que permita devolver los ambientes a su estado anterior.
Merge
Si todo sale bien en la integración de los cambios, se fusiona la rama temporal con la rama principal bajo la estrategia más adecuada (basic, squash, rebase).
💡 ¿Cómo empiezo a usar TBD?
Si quieres migrar de otro flujo para el control de versiones o aún no tienes un estándar definido en tu repositorio o en los de tu organización, podemos recomendarte:
Garantiza que no existan procesos manuales que se conviertan en stoppers en el flujo que requieres para llevar tu aplicación a los diferentes ambientes. Si identificas alguno, puedes buscar la forma de automatizarlo para sacarle mayor provecho a este flujo.
Sabemos que es un reto y por eso los proyectos que trabajan con este flujo deben ser organizados. Este flujo ayuda a su vez a que los equipos adquieran una mayor madurez y mejoren sus habilidades en el desarrollo iterativamente.
Con el enfoque de TBD se despliega el artefacto automáticamente en todos los ambientes, tanto pre-productivos como productivos en un solo pipeline. Es por esto que se deben hacer validaciones muy estrictas (fitness functions — tela por cortar en una próxima publicación — ) antes de pasar al próximo stage y estar preparado para revertir los cambios si alguna de las tareas falla.
Somos conscientes de que a pesar de tener estas validaciones automáticas, existe la posibilidad de que en los ambientes productivos algo no funcione como esperábamos. También, es posible que algunos features sean integrados a la rama principal cuando aún no queremos llevarlos a producción, es allí donde entran en juego otras estrategias como Feature Flags. Te dejamos el enlace a uno de nuestros artículos en donde entramos en mayor detalle sobre el tema.
Finalmente, podemos decir que no es una regla de oro o la mejor estrategia para todos los escenarios. Realmente es una decisión por parte del equipo que lo desee implementar y que debe ser consciente de los impactos y de los beneficios que se pueden llegar a tener.
Finalmente, los invitamos a continuar leyendo nuestros artículos y a revisar los proyectos Open Source que tenemos para la comunidad, pueden contribuir 💪 y usar nuestras herramientas 😀.
