Si estás tratando de implementar una cultura DevOps en tu organización, existe un A-B-C de prácticas que vas a tener que implementar sí o sí. Y la integración continua (en inglés continuous integration) es una de ellas. El tema es que para el proceso de continuous integration (CI) no hay solo un camino. Existen diferentes enfoques, herramientas y beneficios de implementar integración continua en devops y vamos a guiarte por todos ellos en este contenido.
Este contenido te interesa especialmente si quieres implementar una cultura DevOps en tu organización o si eres un profesional buscando desarrollarte como consultor DevOps Si este es tu caso, te recomendamos echar un ojo a esta página para trabajar como DevOps.
Integración continua devops no es solo automatización
La integración continua DevOps es una práctica ya muy extendida dentro del mundo de la programación de software, en la que los desarrolladores reflejan sus cambios de código en un repositorio compartido de forma periódica y recurrente. En esta práctica se automatiza la integración del software, entendiendo como integración tanto la compilación de este software como los tests que este debe pasar.
Pero la integración continua DevOps no es solo automatización.
La integración continua es uno de los pasos fundamentales para seguir una filosofía DevOps, ya que permite compilar y probar el software de forma mucho más continuada. Esto a su vez repercute en que, al lanzar los tests de software a cada cambio que se produce en el repositorio, se localicen y arreglen los fallos de software o “bugs” con mayor prontitud.
Empieza con dos herramientas de integración continua
Las dos principales herramientas de integración continua que vas a necesitar son:
- Repositorio de código: este servidor almacena el código y permite que varios usuarios puedan trabajar en él a la vez. El más popular es Git, aunque hay muchos más.
- Servidor de CI: este servidor vigila el estado del repositorio de código y, cuando se cumplen ciertas condiciones previamente definidas, dispara la automatización de la integración. La integración continua con Jenkins es popular, pero también tienes Gitlab CI o Cirle CI.
Cómo hacerlo bien: implementando integración continua Devops
Con estas dos herramientas listas ya estamos preparados para empezar a implementar nuestra estrategia de integración continua DevOps.
A la hora de implementar esta estrategia, lo más importante es elegir la que mejor se ajuste a nuestra operativa.
Para hacer esto, lo primero que debemos plantearnos es hasta dónde queremos probar el software que se quiere integrar.
Existen varios tipos de tests de software, que determinarán nuestra estrategia de integración continua DevOps:
- Pruebas de humo: prueba muy sencilla que sirve para comprobar el funcionamiento básico del software en cuestión. Son las más baratas de implementar en lo que a tiempo de desarrollo y costes se refiere, y se suelen implementar dentro de los procesos de integración continua DevOps. Suelen usarse para determinar si hay que pasar más pruebas o no.
- Pruebas unitarias: verifican el comportamiento de funciones y métodos de manera individual. Son tests de software baratos tanto en desarrollo como en tiempo de ejecución, y sencillos de implementar.
- Pruebas de integración: verifican que varios componentes del sistema se comporten correctamente cuando trabajan en conjunto. No son ni tan baratos ni tan sencillos como los unitarios, pero no son costosos para el valor que agregan.
- Pruebas funcionales: también conocidas como tests de aceptación, se centran en los requisitos empresariales de una aplicación o sistema. Suelen tener en cuenta inputs y outputs, pero no los estados intermedios. Dependen de los requisitos de la propia aplicación pero por norma general son igual de costosos que los tests de integración.
- Pruebas end to end: simulan el comportamiento que tendría un usuario en un entorno completo. Comprueban inputs, outputs y todos los estados intermedios que se quieran chequear, y dan un feedback muy completo. Son bastante costosas de implementar y mantener, por lo que no se suele recomendar incluir más de una o dos de estas pruebas en los procesos de integración continua DevOps. Si se incluye alguna de estas pruebas dentro de los pipelines, suele ser porque aporta muchísimo valor.
- Pruebas de rendimiento: verifican que el sistema es capaz de funcionar correctamente cuando se le somete a cierta carga de trabajo. Ayudan a medir parámetros como la fiabilidad, la velocidad de respuesta o la capacidad de escalado. No se suelen incluir dentro de los procesos de integración continua DevOps.
- Pruebas de los diferentes componentes gráficos: verifican que la interfaz de usuario de una aplicación o sistema (si lo tuviese) está correctamente implementado. Son las más caras de todas en cuanto a tiempo de desarrollo y tiempo de ejecución se refiere. No se suelen incluir en los procesos de integración continua ya que no aportan mucho valor en comparación con los recursos que consumen.
5 estrategias de integración continua en devops
Una vez tenemos claro cuáles de estas pruebas vamos a automatizar en nuestros pipelines, debemos plantearnos qué enfoque queremos escoger para implementar el sistema. Las estrategias de integración continua en devops más típicas son las siguientes:
- Integración continua básica: es el enfoque más básico que se centra en la compilación del software y su consiguiente testeo. Si alguna de las pruebas no funciona de forma correcta, se implementan mecanismos de aviso para que los desarrolladores corrijan el fallo cuanto antes.
- CI/CD: este es el enfoque más popular. Combina la integración continua básica con una serie de pasos adicionales en los que, dependiendo de si se ha hecho un cambio en infraestructura o en software, se redespliega la infraestructura o se entrega una nueva build del software (siempre que los tests definidos en la parte de CI se pasen satisfactoriamente).
- GitOps: este enfoque es muy similar al CI/CD típico, con la diferencia de que es el repositorio de código el que actúa como director. En este enfoque el despliegue de software o infraestructura siempre es automático, y viene precedido de una aceptación de cambio dentro de una rama del repositorio. Por ejemplo, si en la rama master de un repositorio se mergea una pull request y todos los tests se pasan satisfactoriamente, se desplegará el cambio sobre el entorno de producción, mientras que lo normal es que en los procesos que siguen el enfoque CI/CD clásico alguien deba aprobar el despliegue de manera manual.
- Integración continua multi repositorio: en algunas organizaciones, especialmente las grandes, es común que los proyectos se mantengan en repositorios separados. La CI multirrepo implica la implementación de la CI en cada uno de estos repositorios individuales. Los cambios en cualquier repositorio desencadenan su propia CI, y luego se coordinan y prueban conjuntamente como una aplicación más grande. Esto es útil cuando diferentes equipos trabajan en módulos o servicios independientes que se integran en una aplicación más grande.
- Integración continua distribuida: en entornos distribuidos o en la nube, la CI puede ser distribuida para aprovechar la escalabilidad y el rendimiento. Las pruebas y la construcción se realizan en múltiples servidores o contenedores de manera paralela, acelerando el proceso de CI y permitiendo la ejecución de pruebas en diferentes entornos y configuraciones, lo que permite tiempos más cortos a la hora de integrar aplicaciones (a cambio de un costo económico mayor).
Una vez sabemos qué enfoque vamos a tomar y qué pruebas vamos a realizar sobre nuestro software, ¡estamos listos para pasar toda esta teoría a código!
8 Consejos para dominar el arte de la integración continua DevOps
Ahora que ya sabes lo que es la integración continua DevOps y cómo la puedes implementar dentro de tu operativa, te dejo unos consejos para que aproveches al máximo tus pipelines.
Convierte tus procesos de CI en la única forma de desplegar tu software sobre entornos productivos. Así tendrás total control sobre tus sistemas y te quitarás el problema de mantener varias filosofías de despliegue simultáneamente, que es un gran problema de ineficiencia en muchas organizaciones.
Compila solo una vez el software dentro del pipeline, y haz que este ítem vaya avanzando por las diferentes fases de tu pipeline. Tendrás que hacer que tu compilación no dependa del sistema, pero ahorrarás mucho tiempo y, por tanto, dinero.
Elige bien las pruebas que vas a querer hacer a tu software. Ya hemos mencionado esto pero es tan importante que lo vamos a repetir aquí, escoge tus pruebas de tal manera que se cree un equilibrio entre pruebas realizadas y sus costes en tiempo. No queremos que nuestros procesos de CI se lleven media mañana por delante.
Monitoriza tus pipelines. Dentro de cada una de las diferentes fases de tu proceso, envía métricas que te puedan ser útiles, y monitoriza estas de forma efectiva. Así conocerás mejor tus pipelines y sabrás identificar de forma más rápida si hay algún problema en alguno. Las métricas más típicas para hacerlo son:
- Deploy Frequency (frecuencia de despliegue): Con qué frecuencia un equipo de software sube cambios a producción.
- Lead Time for Changes (tiempo de espera de cambios): El tiempo que se tarda en que el código que se ha “mergeado” esté productivo (medimos el cycle time del pipeline de deployment).
- Change Failure Rate (tasa de fallas en cambios): La proporción de incidentes, rollbacks y fallos en comparación con todos los despliegues.
- Mean Time to Recovery (tiempo de restauración del servicio): El tiempo que se tarda en restaurar el servicio en producción después de un incidente.
Comprueba lo que despliegas. Existen multitud de herramientas que nos permiten comprobar que el código que vamos a subir cumple con ciertos requisitos (no hay código duplicado, se cumplen ciertos estándares, no hay contraseñas en claro, etc.) como pueden ser SonarQube o Coverity. Aprovecha estas herramientas para tener claro que no sólo tu software funciona, sino que cumple con los estándares de calidad que has definido para él.
Utiliza herramientas de detección de malware. Verifica tu código y sus dependencias en busca de posibles amenazas.
Implementa integración continua no solo en el desarrollo de software, sino también en la infraestructura y configuración. Usa herramientas de administración de infraestructura como Terraform o Ansible para definir y mantener la infraestructura como código (IaC).
Automatiza procesos operativos. Desarrolla scripts sencillos de utilizar para automatizar tareas que tengan que ver con tu operativa, y trata de incluir estos en tus pipelines. Por ejemplo, puedes automatizar la generación de tu fichero changelog en base a la nomenclatura de los commits incluidos en una nueva build.
Reflexión Final
En este punto es como si hubiéramos destapado un cofre lleno de tesoros para tus proyectos, cuando dominas estos secretos y consejos de la integración continua DevOps te conviertes en el propio capitán de tu barco. Imagínate desplegar una nueva característica en tu aplicación con una facilidad que nunca habías experimentado. Visualiza tu equipo trabajando en armonía, cada línea de código encajando perfectamente con la siguiente.
Así que adelante, lleva contigo estos conocimientos. A medida que los profesionales DevOps adoptan estos principios en sus piedras angulares del proceso de desarrollo, la integración continua DevOps se convierte en una promesa de entregas más eficaces, equipos más cohesionados y proyectos más exitosos.
