DevOps

Qué es Integración Continua

La integración continua es una de las prácticas más difundidas en el ecosistema DevOps. Es un proceso que se origina en un servidor de versionado como lo puede ser Git y finaliza con la ejecución de un conjunto de pruebas que se ejecutan sobre el código compilado o interpretado.

En una organización con múltiples desarrolladores escribiendo código sobre el mismo repositorio, la integración representa un desafío mayúsculo. Es por eso que este tipo de prácticas son necesarias y, si se implementan de manera adecuada, se obtienen resultados notorios en la entrega y calidad del código.

Prácticas y principios básicos de la Integración Continua

• Repositorio de origen: Solo se mantiene un repositorio donde se encuentre todo el código, independientemente si este contiene scripts, fuentes, binarios o archivos de configuración. La fuente es única.
• Automatización: Idealmente, se debe automatizar todo, de no ser posible, es una práctica recomendada, automatizar la construcción de la aplicación. A esta práctica se le llama Build.
• Pruebas automatizadas: Automatizar las pruebas que se realizan sobre el código, pero también sobre el procedimiento de construcción. Por ejemplo, cuando se desarrolla alguna funcionalidad, se debería desarrollar el chequeo que valida el correcto funcionamiento de ese código. También se deben desarrollar chequeos que validen que la compilación del código fue correcta.
• Cambios publicados: Todo cambio publicado al repositorio principal, debe ser probado en una máquina virtual, contenedor, o cualquier cosa que permita validar que los cambios, no rompan la cadena de construcción. Un fallo en este proceso puede provocar problemas a futuro.
• Compilaciones fallidas: Alineado con el principio anterior, de ocurrir un fallo en el proceso de construcción, el mismo debe disparar acciones inmediatas para corregir el problema. En las organizaciones donde las prácticas DevOps están más desarrolladas, un fallo en la construcción del software es tan importante como un fallo en los sistemas ya productivos, porque presenta una interrupción para los equipos de desarrollo.
• Ambientes homogéneos: Las distintas etapas por las que pasa el código, conocidos como ambientes deben ser análogos al ambiente de producción. Esta práctica es importante debido a que garantiza que la aplicación se va a comportar igual tanto en ambientes de desarrollo como en ambientes productivos.
• Rápida construcción: El proceso de compilación y construcción del código debe ser rápido. Un proceso lento desalienta a los desarrolladores a hacer cambios periódicos por lo que, debemos de preocuparnos por mejorar y hacer eficiente el mecanismo de construcción de la aplicación.

Estas prácticas y principios están construidas sobre la base que sostiene al movimiento DevOps: la Comunicación. Esto no sería posible si las organizaciones siguen trabajando en un esquema de silos.

Etapas de la Integración Continua

Todo ciclo DevOps se dice que tiene un comienzo, pero que carece de un final. Esto se debe a que el movimiento propone ciclos donde se busca la mejora continua, obteniendo como resultado, un ciclo infinito.

• Planificación: El ciclo de integración continua y del proceso completo, comienza con una etapa de planeamiento. Ya sea estemos desarrollando una funcionalidad nueva, o resolviendo un problema, lo que sea que se vaya a desarrollar, se planifica. Si bien la etapa es agnóstica a la metodología, lo normal es que se planifique usando metodologías ágiles o afines.
• Codificación: El equipo de desarrollo empieza a escribir el código que da vida a la funcionalidad o resuelve el problema encontrado. Acá se hacen uso herramientas de gestión de código como Git o similares.
• Construcción: El proceso de compilación del código, donde se ejecutan las herramientas y/o scripts que generan el artefacto del componente o aplicación.
• Pruebas de funcionamiento: Esta etapa introduce los primeros chequeos a ejecutar sobre el código desarrollado y sobre la aplicación desplegada. La idea es hacer pruebas sencillas que descarten problemas “evidentes”. Este tipo de pruebas se le conoce como Smoke tests o Pruebas de humo.

Qué es Despliegue Continuo

El despliegue continuo comienza luego de que la etapa de integración finaliza, dando lugar a las tareas esenciales para asegurar la calidad del código o del artefacto generado y a las tareas que involucran el despliegue y entrega final. En esta linea de razonamiento, no hay un inicio, sino una continuación del flujo originado por el proceso de integración. Por el contrario, esta etapa sí tiene un final, siendo este, el servidor o contenedor donde se quiere impactar el código o artefacto de la aplicación.

Antes de entrar en detalles, cabe destacar que existe una etapa previa, contenida dentro del Despliegue Continuo la cual se le conoce como “Entrega Continua”. La diferencia más notoria entre la entrega continua y el despliegue continuo radica en la forma que se hace el despliegue, mientras que en el despliegue continuo cada versión se despliega de forma automática en el destino, en la entrega continua, este procedimiento tiene un paso manual y es la aprobación del cambio. En otras palabras, el despliegue se hace automático, pero hay un operador que aprieta un “botón”.

Prácticas y principios básicos del Despliegue Continuo

• Automatización: Es cierto que esta práctica también se repite en la Integración Continua, pero acá no podemos pasar al siguiente nivel en el ciclo, sin automatismos. Dicho de otra forma, no podemos pasar de Integración continua a despliegue continuo, sin automatizar.
• Control de versiones: Todo debería estar en un servidor de versionado.
• Calidad del software: Si bien también es una práctica que se debería aplicar en el ciclo de Integración Continua, acá evoluciona a un nivel donde se vuelve fundamental, al igual que la automatización, y que deriva en acciones concretas que debemos de efectuar frente a determinados eventos. Por ejemplo, si un fallo un chequeo es considerado crítico, el proceso de entrega se interrumpe y la prioridad pasa a ser, resolver el fallo. Se trabaja bajo la consigna de que no se introducen problemas en etapas posteriores de la cadena.
• Procedimiento confiable: El proceso de entrega y despliegue debe ser confiable y reproducible. Un proceso que al ejecutarse dos veces genera resultados distintos, no es un proceso confiable. Debemos de poder ejecutar el procedimiento paso a paso y el resultado permanecer constante. Este proceso debe ser igual en todos los ambientes a los que aplique.
• Todos son responsables: En el equipo DevOps, todos son responsables por la calidad y entrega de las aplicaciones y por los errores que surjan que deban ser atendidos.
• Definición de realizado: Si una tarea está marcada como “Realizada”, implica que tiene que compilar y entregarse. Cada marca de “terminado” implica que dicha funcionalidad o falla arreglada puede ser liberada y desplegada.

Etapas del Despliegue Continuo

Además de las etapas contenidas en el ciclo de Integración Continua se agregan:

• Testing: En esta etapa se agregan pruebas de calidad de código, cobertura de código, performance, seguridad, deuda técnica, etc. Es de vital importancia que en esta etapa estén bien definidos los criterios de aceptación, dado que, de estos, depende si se continua con el ciclo o de detiene. Es importante aclarar, de que no se trata de una etapa nueva, sino una extensión a la anterior.
• Release: En esta etapa se efectuarán todas las tareas relacionadas con la liberación, desde la confección de los documentos como notas, changelogs, etc. En esta etapa, además, se configuran las bases necesarias para poder desplegar el código o artefacto, como, por ejemplo, el etiquetado del código (version tagging), congelamiento del código, etc.
• Despliegue: Se escriben e impactan los automatismos para desplegar la aplicación o componente, en cada uno de los ambientes que formen parte del ciclo. Este despliegue suele ser concatenado, es decir, primero se despliega en un ambiente replica de producción llamado “staging”, el cual sirve para hacer las validaciones finales y funcionales del despliegue. La cantidad de ambientes previos a producción va a estar determinada por la necesidad de la organización y no tanto por definición, por lo que podría haber, entre los ambientes de desarrollo y de staging, un ambiente de integración, donde se pone a prueba la aplicación junto con el ecosistema con el cual va a interactuar, como lo pueden ser servicios de LDAP, Single Sign On, APIs, etc.
• Operación: En esta etapa se monitorea y se mide el estado de salud y performance del despliegue. Un buen sistema de monitoreo nos permite anticiparnos a los problemas y aprender de ellos. Recuperarnos más rápido de lo que fallamos es parte esencial de la ecuación, y todo un desafío sino se cuenta con las herramientas adecuadas. Acá suelen integrarse automatismos que nos permitan reaccionar espontáneamente a determinados eventos.

Top de herramientas de CI/CD

Los ciclos de Integración y Despliegue continuo no suelen ser prácticas que se implementan unilateralmente, sino por el contrario, lo normal en una organización que hace de DevOps su cultura, es que se implemente un ciclo similar al de la siguiente imagen:

El ciclo es infinito y representa el trabajo en busca de la Mejora Continua (Continous Improvement) y finaliza (si es que tiene fin) cuando el objeto de ese ciclo se depreca o llega a un estado de madurez en el cual no requiere cambios.

Las herramientas de CI/CD articulan la implementación de estos ciclos y nos permiten, por medio de conectores y plugins, describir las tareas que se deben ejecutar en cada etapa del ciclo DevOps.

Existen muchas herramientas, algunas Open Source, otras cerradas, algunas gratis con opciones de soporte y licenciamiento, y otras directamente se requiere de una licencia para poder operar más allá del período de prueba de pocos días. Entre las herramientas más populares tenemos:

• Jenkins
• Gitlab
• CircleCI
• Bamboo
• TeamCity
• CodeFresh

De las herramientas mencionadas, algunas son soluciones SaaS, es decir, no se ejecutan en ambientes on-premise, y otras se pueden desplegar tanto en ambientes locales como en ambientes de cloud. En particular, vamos a hacer doble clic sobre Gitlab, Jenkins y CodeFresh.

Gitlab

Gitlab es una suite completa de CI/CD que se puede desplegar no solo en containers y máquinas virtuales, sino que podemos usar el servicio SaaS.

Armar un pipeline en Gitlab (ciclo devops) es muy sencillo y basta con crear un archivo oculto de nombre “.gitlab-ci” en la raíz del repositorio que queremos vincular al ciclo.

Gitlab viene con todo lo necesario para poder armar cada etapa de del ciclo y ofrece la posibilidad de extender sus capacidades mediante integraciones que pueden activarse, incluso, algunas de ellas en versiones gratis.

Entre otras características, Gitlab ofrece:

• Registro de imágenes integrada
• Integración con clusters de Kubernetes
• Integración con ChatOps
• Integración con Docker en los ciclos
• Sintaxis basada en YAML
• Un lugar para todo: Versionado y Pipeline en un solo lugar
• API expuesta
• Repositorios de Charts de Helm
• Y mucho más…

La versión gratuita de Gitlab provee lo necesario para una inmensidad de casos de uso y sin duda ofrece, para las empresas que están recién iniciando el camino hacia la cultura DevOps, un aliado con una curva de aprendizaje menos empinada que otros productos en la industria.

Jenkins

Jenkins es un veterano en el armado de ciclos DevOps puesto que hace varios años que está en el mercado. Presenta algunas diferencias interesantes respecto a Gitlab, como, por ejemplo:

• Muchísima información y casos de uso disponibles para usar
• Una biblioteca de plugins inmensa (1700+)
• Se integra con servicios también con plugins
• Open Source
• Y mucho más…

El desafío en el uso de Jenkins radica en que utiliza un lenguaje propio de código para escribir los ciclos y en la gestión de estos plugins cuando el proyecto escala, por lo que no solo debemos de contemplar la administración del motor de CI/CD sino que también el ecosistema de plugins y en ocasiones, mantener la compatibilidad, es todo un reto.

Existe una variante de Jenkins, llamada JenkinsX que no es más que la evolución de la plataforma, a un formato compatible con las tecnologías cloud nativas. JenkinsX ofrece características más alineadas con las tecnologías basadas en containers y se integra con plataformas como Kubernetes sin mucho esfuerzo.

CodeFresh

Codefresh es una plataforma de CI/CD cloud nativa desde su concepción específicamente pensada para Kubernetes. Ofrece la posibilidad de ejecutarse en ambientes on-premise o cloud, y SaaS. No es una plataforma tan popular como Gitlab y Jenkins pero sin duda que merece un lugar en la lista.

Entre las características que tiene, destacan:

• Biblioteca extensa de plugins
• Registro de imágenes de containers
• Repositorios de Charts de Helm
• Despliegue nativo en containers, VMs, Serverless y más.
• Sintaxis basada en YAML
• Modelo de enfoque basado en GitOps
• Integraciones con servicios externos
• Y mucho más

El potencial de esta aplicación radica en su integración nativa con plataformas como Kubernetes y en el modelo de despliegue basado en GitOps, un paradigma relativamente nuevo y que desde hace algunos años ha demostrado ser un complemento necesario a los procesos DevOps.

Conclusiones

No importa qué herramienta elijamos para comenzar el recorrido en el mundo de los ciclos de Integración y Despliegue Continuo, cualquiera de las herramientas mencionadas presenta pros y contras en régimen de comparación. Todas fueron diseñadas con distintos enfoques y para servir a distintos requerimientos y para seleccionar una, debemos de mirar las necesidades internas y ver cuál es la que mejor se ajusta a nuestra organización.