Continuous Integration/Continuous Delivery: casi todo lo que tienes que saber

«Continuous Integration» (CI) y «Continuous Delivery» (CD) se encuentran en el centro del día a día de cada vez más equipos DevOps, que han adoptado esta metodología por su capacidad para introducir cambios en el código de cualquier desarrollo de forma más frecuente y con seguridad. ¿Pero qué son en realidad? ¿En qué consiste esta metodología agile?

CI/CD engloba un conjunto de principios operativos y grupo de prácticas que apuesta por que los equipos de desarrollo de software cumplan con los requisitos empresariales a la hora de desarrollar código de calidad y seguro, ya que el despliegue del mismo estará automatizada.

En el lado de CI, hablamos de un conjunto de prácticas que impulsan a los equipos de desarrollo a implementar pequeños pero continuos cambios, con revisiones frecuentes del código en los repositorios en los que almacenan los controles de versiones (de ahí la importancia de plataformas como GitHub).

Además teniendo en cuenta que la mayoría de las aplicaciones modernas requieren adaptar el código para distintas plataformas y herramientas, este tipo de repositorios y mecanismos son de gran utilidad para integrar y validar los cambios. Su objetivo último por lo tanto, es desarrollar una forma consistente y automatizada de construir, empaquetar y probar aplicaciones.

Donde termina CI (la integración de aplicaciones), comienza CD o lo que es lo mismo, el automatizar la entrega de aplicaciones a entorno de infraestructura seleccionados. Como la mayoría de los equipos trabajan con múltiples entornos distintos al de producción (por ejemplo, entornos de desarrollo o de pruebas), CD garantiza que haya una forma automatizada de entregar los nuevos desarrollos a los distintos entornos.

Gracias a esta automatización, las herramientas de CI/CD realizan por ejemplo llamadas a servidores web, bases de datos y otros servicios que almacenan los parámetros necesarios que se deben utilizar cada vez que pone en marcha el despliegue o la actualización de las aplicaciones.

De esta forma podemos hablar de que una práctica de CI/CD es madura cuando tiene la opción de implementar un despliegue continuo de las aplicaciones hacia los entornos de producción desde los entornos de prueba. Los equipos que apuestan por este sistema suelen optar por un despliegue diario, pero en ocasiones se pueden llegar introducir cambios incluso cada hora, aunque esto no siempre es lo más recomendables para según qué aplicaciones.

Así trabajan los equipos CI/CD

Al trabajar en un entorno CI, los desarrolladores «lanzan» periódicamente (el estándar es una vez al día) su código contra el controlador de versiones. De esta forma, les resulta mucho más sencillo identificar defectos y otros problemas de calidad del software, ya que la cantidad de código que hay que se comparar y revisar en cada ocasión es mucho menor.

Además de controlar el código cada vez que se compara con el controlador de versiones, los equipos que apuestan por esta metodología utilizan otras técnicas para controlar qué características y código específico está listo para entrar en un entorno de producción.

Por ejemplo, resulta habitual que muchos equipos utilicen lo que se denomina como feature flag, un mecanismo de configuración que permite activar o desactivar características y partes del código en tiempo real.

Así cuando se lanza una nueva versión, las características que aún se encuentran en desarrollo se «flaguean» de modo que aunque se despliegan en el entorno de producción, permanecen «apagadas» hasta que estén listas para ser utilizadas. Algunas herramientas que se utilizan para este propósito son CloudBees Rollout, Optimizely Rollouts, o LaunchDarkly.

Otra técnica popular para gestionar la entrega de nuevas versiones es utilizar la «ramificación» en el control de versiones. Gracias a herramientas como Gitflow, se definen los protocolos sobre cómo se añaden nuevas características al código final, desplegando distintas ramas de programación (habitualmente desarrollo, prueba y producción). Además pueden crearse ramas de características adicionales para aquellas que requieren ciclos de desarrollo más largos. Cuando la característica está completa, los desarrolladores pueden entonces fusionar los cambios de las ramas de características en la rama de desarrollo principal.

Lo interesante es que junto a todo lo anterior, la mayoría de las herramientas de CI/CD permiten a los desarrolladores desplegar las nuevas versiones «on demand», en el sentido que pueden activarse estableciendo todo tipo de reglas, ya sea mediante «commits» en el propio código que se encuentra en el repositorio de control de versiones o simplemente, estableciendo un horario predefinido.

CI/CD, contenedores y Kubernetes

Cuando el despliegue de aplicaciones se realizar en un entorno cloud, muchos equipos DevOps se apoyan en contenedores como Docker y sistemas de orquestación como Kubernetes.

Una de las principales ventajas de este enfoque es que los contenedores permiten empaquetar y desplegar las aplicaciones de forma sencilla, consiguiendo además que sean «portables». Por otro lado, trabajar con contenedores facilita ampliar, reducir o desmantelar por copleto un entorno de producción con pocos clics, en función de una carga de trabajo que puede ser variable.

Como hemos visto hasta ahora, a la hora de trabajar con esta metodología agile, casi todo son ventajas. Es necesario eso sí tener un grupo cohesionado, en el que el los equipos de desarrollo y los de operaciones sean capaces de colaborar por un lado en el desarrollo de tecnologías, pero a la vez, capaces de llegar a consensos en prácticas de trabajo y prioridades.