Rediseñando el modelo de desarrollo interno de Babel: volando a producción

Cómo en el pasaje de la Biblia, cada proyecto habla su propio lenguaje. Alguno habla una lengua más común, como puede ser JAVA. Otros, incluso dentro del mismo proyecto, hablan varios idiomas y dialectos: JAVA y AngularJS, por ejemplo.

Nuestra visión y objetivo era disponer de un ciclo de vida del software único y homogéneo, independiente de la lengua o lenguas habladas en el proyecto, minimizar las interacciones del desarrollador y automatizar las tareas más tediosas y repetitivas, consiguiendo que el desarrollador se centre en lo más importante: desarrollar.

Teniendo como prioridad interna la creación de un flujo común de desarrollo e integración, se compuso un equipo multidisciplinar con dos perfiles de infraestructura cloud y enfocados a la filosofía DevOps y dos desarrolladores JAVA.

El primer paso fue diseñar el flujo de integración continua y despliegue continuo que queremos implementar, así como la infraestructura que da servicio y soporte al proyecto.

Buenos conocedores de Azure, se eligió esta plataforma para el despliegue de la infraestructura. Al ser un servicio crítico en BABEL, optamos por una forma de despliegue ágil, que permitiese actualizar o incluso redesplegar servicios (o la plataforma completa) rápidamente. Por ello toda la infraestructura está desplegada con Terraform y Ansible. Además, este código se adhiere al Gitflow definido para los proyectos de desarrollo.

Con la idea de simplificar la integración de proyectos dentro del flujo de CI, tratamos de que la configuración fuese lo más sencilla posible. Para ello, realizamos el desarrollo de una librería para Jenkins. Dicha librería sería la encargada de llevar toda la lógica del workflow de CI. Esta aproximación nos permite disponer de un sencillo fichero de configuración dentro del repositorio de código del proyecto, mediante el cual podemos definir en pocos parámetros qué tipo de proyecto y qué pasos queremos dar dentro del workflow. Como extra, se trata de una librería modular, por lo que se pueden realizar pequeños desarrollos para añadir nuevas tecnologías o tests de manera sencilla. Otras funciones de la librería son controlar el tipo de cambio realizado, la versión del código, etiquetar las nuevas versiones subidas en el repositorio...

Además, para facilitar la integración de nuevos proyectos basados en arquitecturas de microservicios, se implementó un clúster de Kubernetes (basado en Azure AKS), que dota a Jenkins de los workers necesarios para llevar a cabo los jobs de los distintos proyectos.

Este enfoque nos permite añadir pasos de QA en el ciclo: podemos añadir nuevos sistemas de tests (JMeter por ejemplo) y generar un módulo en la librería, para que los proyectos que lo necesiten hagan uso de dichos tests.

Como fase final, el sistema genera un informe automático con todos los resultados (satisfactorios o no) de todas las fases involucradas en el proceso y que es remitido al desarrollador o al equipo.

Tras la implantación, formación y acompañamiento de los distintos equipos y proyectos se ha conseguido tener un ciclo de integración continua homogéneo y común a todos los proyectos.

Este paso ha permitido a muchos proyectos reducir el time to market del producto, mejorar la calidad del mismo y evitar inconsistencias en producción.

Así mismo, ha sentado las bases para comenzar con los primeros pasos para implantar técnicas de CND (Cloud Native Development).