Integración Continua rápida y sencilla con GitLab CI

¿Aún no has descubierto las ventajas que la Integración Continua puede tener en tus desarrollos? ¿Usas GitLab para gestionar tus proyectos y nunca te has parado a pensar que hacen esas pestañas que nunca has usado encima de tus repositorios?

Pestañas en los proyectos - Integracion Continua en GitLab

Pues podrías deshabilitarlas en los settings… o continuar leyendo para descubrir algunas formas en las que pueden ayudarte a multiplicar tu productividad de una forma muy sencilla.

Este post pretende ser un resumen de alto nivel de como GitLab interpreta los conceptos principales de Continuous Integration/Delivery y presenta las caracteristicas de la herramienta y su forma de llamar a las cosas, dado que todo puede sonar más complicado de lo que en realidad es. En siguientes artículos, ilustraremos todo esto con una sencilla demo haciendo uso del generador de páginas estáticas que incluye la suite y un caso de uso real de implantación de Integración Contínua con GitLab en un flujo de trabajo.

El crecimiento del producto lo ha catapultado a los stacks tecnológicos de muchas empresas, parte de esta popularidad viene de la mano con ser un fantástico proyecto open-source que seguir; su ciclo de actualización es increíble y son capaces de incluir nuevas funcionalidades el 22 de cada mes. Uno de los factores más importantes en esta ecuación es el hecho de que no solo ofrecen una solución auto-alojada, que te permite tener tus proyectos bajo control en tus servidores, sino que es también una bastante completa. Solo tienes que preguntar a tu colega ops de referencia y te contará como incluso la versión community (no comercial) trae consigo muchas cosas que son increíblemente caras o que simplemente no incluyen otras soluciones SaaS similares.

El masterplan - Integracion Continua en GitLab

De vez en cuando pasa, que simplemente nos acomodamos en aquellas plataformas y herramientas que ya conocemos y ni nos percatamos de la aparición de alternativas que pudieran mejorar nuestro día a día. Creo que este es el caso de algunas de las opciones menos conocidas de GitLab. El proyecto es mucho más que un sevidor de control de versiones tradicional, de hecho el año pasado describieron su «masterplan» para convertirse en algo más parecido a una «suite» para cubrir cada uno de los pasos en el ciclo de desarrollo; o en sus palabras: pasar de idea a producción. Y para rematar, tanto en pasadas como en futuras actualizaciones, están incluyendo integraciones con otros servicios muy interesantes que merece la pena tener presentes (p.e. chatops para slack/mattermost o monitorización con Prometheus)

Diferencias con otras herramientas de Integración Continua.

Empecemos describiendo aquello que lo convierte en una opción tan potente. Para empezar, está basado en un modelo de fichero de configuración escrito en YAML y almacenado en la raíz de cada repositorio. Esta aproximación tiene algunas ventajas que vale la pena mencionar con el resto:

  1. Estrecha relación entre los sistemas (tanto Integración Continua como la gestión de versiones son un único producto).
  2. La configuración de Integración Continua pasa a estar versionada:
    • Fomentando que cada rama tenga su propia configuración.
    • Permitiendo a los colaboradores aportar también configuraciones.
  3. Integración con Docker sin necesidad de configurar nada, incluyendo un Docker registry privado por proyecto.
  4. Explorador de artefactos para acceder a los resultados de cada etapa del mismo modo que haríamos en local.
  5. Nada de tiempo malgastado en configurar el servidor de Integración Continua.

Desde el punto de vista del usuario, todo esto viene con algunas pegas en comparación con otros sistemas de Integración Continua, dado que emplea un modelo muy «convention over configuration«, que se traduce en una herramienta muy poderosa «de fábrica», sin perder mucho tiempo en configurarla, pero a cambio el usuario tiene que ceñirse a su manera de hacer las cosas. Es lo que ocurre con la falta de plug-ins e integraciones a los que, por ejemplo, Jenkins nos tiene acostumbrados y que permiten configurar más el detalle de nuestros proyectos (por ejemplo, crear trabajos que hagan uso de más de un repositorio en GitLab no es nada trivial). Pero hay que decir que la mayoría de los escenarios están cubiertos de sobra: alertas por email, navegar por la historia de builds del proyecto o programar ejecuciones de los trabajos son algunos ejemplos.

Pero seamos claros, ni han inventado la rueda ni son los únicos que la están usando: muchas otras herramientas de Integración Continua también descansan en paradigmas similares (.travis.yml, Jenkinsfiles…). Todo esto es cuestión de gustos. Pero el poso que te queda después de probar distintos sistemas es que la que propone GitLab es la más sencilla de configurar a la vez que permite tener la mayor cantidad de detalles bajo control en la misma pestaña del navegador. Han tomado las mejores funcionalidades de cada herramienta y las han empaquetado en una sola aplicación: tiene todo el sentido.

Principales características

Voy a tratar de ilustrar las principales bondades de la herramienta y demostrar lo fácil que es empezar a usarla sin ningún tipo de experiencia cómo sysadmin o molestar a tus devops. Como ya he mencionado, todo gira en torno al fichero .gitlab_ci.yml que contiene la definición de las diferentes stages (o pasos) que contienen diferentes trabajos que tendrán que completarse para que el proyecto pueda ser desplegado correctamente. La estructura del archivo es de lectura natural y una vez hayas visto un par de ejemplos, podrás empezar a escribir los tuyos sin apenas esfuerzo.

No tenemos más que dirigirnos a la documentación de GitLab CI para encontrarnos con basta información y ejemplos de como traducir las necesidades específicas de nuestro proyecto a sus convenciones. Para resumir, vamos a revisar cuales son las opciones de Integración Continua que cualquier repositorio tiene activadas por defecto:

Configuración de Integración/Despliegue Continuo (CI/CD)

La página de configuración da una idea de cómo de sencillo es configurar todo aquello necesario para que se obre la magia de la integración continua:

Runners

Qué pasa si te digo que por fin te puedes olvidar de configurar y gestionar slaves: el cómo se conectan al servidor de Integración Continua, cómo balancear la carga entre todos o cualquier otros detalles que son tanto tediosos como complicados en muchos casos…

Te presento a los Runners! Su instalación se reduce a algo tan sencillo como seguir los tres pasos descritos en la configuración de CI/CD de tu proyecto: instalar el binario correspondiente a tu sistema operativo, pega la URL de tu servidor y el token que aparece en esta página y listo. Además, puedes etiquetar a tus Runners en base a sus capacidades para seleccionarlos en trabajos específicos desde el fichero .gitlab_ci.yml cuando sea necesario.

Los Runners pueden utilizar diferentes executors, que no son más que formas distintas de ejecutar tus scripts/código en ellos; desde el más básico, sobre ssh, pasando por un servicio de contenedores, hasta el cluster kubernetes más grande que se te pueda ocurrir; soportando incluso ejecuciones sobre Powershell/Batch en sistemas Windows.

En su versión auto-gestionada, gitlab.com, también ofrecen la posibilidad de configurar «shared runners«: máquinas virtuales sin coste alguno y compartidas entre todos los usuarios, que se reservan dinámicamente para los proyectos de la plataforma. Esto es ideal para desarrollos open-source con recursos limitados.

Gestión de secrets

En la era de los microservicios, en la que es muy probable que tu proyecto esté integrado con docenas de APIs que utilizan tokens, secrets, contraseñas de aplicación o cualquier otra forma de autorizar ese diálogo, se convierte en prioridad alguna forma elegante de manejar toda esta complejidad. Un auténtico bad smell más frecuente de lo que creeríamos es almacenar todos estos datos en ficheros de configuración en una máquina remota o incluso dejarlos colgando en alguna parte del código. Para poner énfasis en la importancia de esto, simplemente considera cuántos servicios y proyectos están surgiendo en los últimos años para gestionar esta problemática. Los proyectos de GitLab también incluyen un sencillo keystore en su página de settings que pueden ser accedidos desde los scripts de Integración Continua para que los administradores del proyecto los gestionen.

Pipelines

Esta es la funcionalidad central de cualquier sistema de Integración Continua y, a la vez, un concepto realmente simple que se traduce en conectar todos los pasos (stages) que deben seguirse desde el momento en el que dispone de todo el código fuente al punto en el que la aplicación puede ser desplegada. Entre medias, puedes incluir todo aquello que se te ocurra para comprobar que: el código tiene buena pinta (linting), puede compilarse sin errores, funciona de forma esperada (unit tests), se integra con otros sistemas… y cualquier cosa que nos lleve a desplegar con seguridad nuestras aplicaciones.

Ejemplo de una pipeline - Integracion Continua en GitLab

Container Registry

Imagina tener tu propio docker hub privado en el que almacenar las imágenes de tu proyecto, actualizarlas en cualquier momento que sea necesario sin tener que exponerlas al publico y con la capacidad de utilizarlas desde cualquier sitio con sólo autenticarse. Puedes tener una imagen preparada para cada stage de tu pipeline y abstraer cantidad de información de build a los runners de forma transparente e increíblemente rápida. Esto se vuelve fundamental a la hora de inicializar los entornos, reduciendo el tiempo necesario para ejecutar nuestros trabajos.

Entornos y review apps

A todos nos encanta gitflow, ¿verdad? y es que hay unas cuantas razones para ello. Se construye sobre las premisas de que si cada rama es desarrollada de forma aislada, las nuevas funcionalidades no interfieren con el resto o con la estabilidad de toda la aplicación hasta que son mergeadas en master. Esto nos ayuda tanto a desarrollar funcionalidades como a testarlas.

Cuando los contenedores irrumpieron en nuestras vidas, era obvio cómo el proceso de desplegar entornos diferentes e independientes con configuraciones individuales podía agilizar nuestros despliegues. Y ahora es justo decir que utilizamos los contenedores como estándar de facto en lo que a despliegues se refiere. La mayor parte de los sistemas de Integración Continua se idearon mucho antes de que el primer contenedor de la historia fuese creado, y por tanto, sin Docker en mente. Con GitLab CI ocurre todo lo contrario: fomentan el uso de los contenedores basándose en todos los beneficios que aportan al flujo de trabajo

Dockerizando Gitflow - Integracion Continua en GitLab

Por ejemplo, un escenario que se repite en cada sprint: estás a punto de mergear la rama de una user story que tiene que ser testada por el equipo de QA y que a su vez, introduce nuevas dependencias con librerías y con un nuevo servicio (p.ej. Redis, mongoDB…) para ser desplegada. Solo tienes que actualizar tu Dockerfile para incluir la/las nuevas capas que gestionan estas dependencias y hacer push de dicha imagen a tu Docker registry local. Una vez se suban los cambios de la rama al repositorio, tendrá todo en su lugar para ser desplegada con un click en el entorno de pruebas.

Vista de entorno - Integracion Continua en GitLab

Aquí es donde entran en juego las review apps, que no es más que una forma pija de llamar a entornos creados dinámicamente por rama, para verificar los cambios y verlos desplegados. Cada rama tiene la capacidad de ser desplegada en cuanto se hace el push contra el repositorio. Este proceso puede agilizarse mediante herramientas como dpl que abstraen muchos de los detalles de implementación de las principales plataformas de despliegues en la nube. O en cambio, llamar manualmente a tu script de despliegue personalizado desde ahí.

También integra una terminal interactiva que lanzar desde el navegador y que permite determinar las causas en el caso de que algo fuese mal en nuestros despliegues. Ya no hace falta repetir el mantra de Jenkins en el que clonabas un trabajo configurado, lo renombrabas, ajustabas las ramas en su configuración… y 10 o 15 tediosos pasos después ya podías desplegar tu entorno de pruebas efímero.

Otra funcionalidad que te va a encantar es el history browser. Imagina que has desplegado unos cambios para una demo y 10 minutos antes de empezarla, descubres que esa versión tiene un bug que quedaría muy feo en camara. ¡Ningún problema! es extremadamente sencillo acceder a toda la historia de aquello que se desplegó en cada uno de nuestros entornos y revertir aquellos cambios que nos afectan para volver a cualquier estado anterior. Genial!

Redespliega o revierte los cambios - Integracion Continua en GitLab

Espero que tras esta introducción, los conceptos centrales sobre los que se asienta la Integración Continua en GitLab cobren sentido en tu contexto y en el de tus proyectos. Si no, solo espera a la continuación para descubrir a través de una demo, como podemos empezar a utilizarlo de una forma muy sencilla.

Artículos relacionados

Integración continua usando Jenkins para test automáticos en iOS

Automatización de pruebas sobre una API: Postman, Newman y Jenkins

Testing de una aplicación móvil usando Sauce Labs, Jenkins y Appium

6 comentarios en «Integración Continua rápida y sencilla con GitLab CI»

  1. Buenos días Samuel,

    Muchas gracias por ofrecernos esta visión de GitLab, la verdad que para gestionar nuestros repositorios de aplicaciones web a medida es una herramienta perfecta.

    Trabajo en Enjoysoft Consulting, nos dedicamos al desarrollo web a medida, diseño web Responsive y desarrollo de Apps y estamos empezando a usar GitLab para almacenar y gestionar nuestros repositorios.

    Os comparto nuestro sitio web, subimos noticias relacionadas con el desarrollo de Software.

    http://www.enjoysoftconsulting.com

    Saludos

    Responder
  2. Hola Samuel, excelente artículo. Tengo desde hace varios meses mi GitLab CE, y tengo varios proyectos, pero nunca había tenido la necesidad o la curiosidad de hacer CI y CD de esos proyectos. Siempre había trabajado con Jenkins o Bamboo, y ahora tengo un proyecto que e desarrollado con Spring Boot y Angular, y me gustaría usar mi servidor Tomcat. para hacerle deploy.
    He buscado ejemplos o algún artículo que me ayude a realizar el build, test y deploy en mi tomcat, pero no e tenido éxito. Si me pudieras ayudar sería genial. Gracias por compartir tus conocimientos.
    Saludos

    Responder
    • Hola Eduardo, muchas gracias por tu interés en el articulo!

      Para los deploys mediante Git te puedo enlazar un par de artículos de la documentación oficial mientras preparamos la segunda parte del articulo y el correspondiente vídeo que precisamente tratan sobre estos temas:

      https://docs.gitlab.com/ce/ci/environments.html – trata en profundidad la problemática de los despliegues y los entornos. Expone todas las opciones que GitLab CI proporciona al respecto (despliegues manuales, definición y configuración de entornos…)
      https://about.gitlab.com/2016/08/26/ci-deployment-and-environments – expone unos cuantos casos de uso que pueden ilustrar cómo hacer un despliegue sobre un servicio externo como es S3. Aunque no es tu caso, es muy útil para entender como encajan todas las piezas.

      Si habitualmente realizas tus despliegues a través de un script, trasladarlo a tu fichero de configuración de la CI resultará casi inmediato: por ejemplo, puedes configurar un executor ssh que tenga permisos de deploy sobre tu servidor tomcat (o incluso que esté corriendo en la misma máquina, aunque no es muy recomendable) y ejecutar las instrucciones de tu script en la etapa/trabajo que definas como deploy.

      Si necesitas ayuda a más bajo nivel, proporcionando detalles más concretos de tu proyecto, te propongo que la publiques en StackOverflow (o en su versión española en https://es.stackoverflow.com) y nos copies el enlace para que nos pueda ser más cómodo abordarlas con ejemplos de código o algún detalle más técnico.

      Gracias!

      Responder
  3. Samuel tengo alguna duda sobre como encajan las piezas de docker registry y gitlabCI, serías tan amable de explicar un poco mas en detalle como funciona docker registry, o como se define este para que despues encaje con gitlabCI

    Responder
  4. Muy bueno el artículo Samuel! Ya utilizamos CI en la empresa, pero leyendo esto me he enterado mejor de algunas cosas (e incluso he visto alguna cosilla nueva que desconocía 🙂

    Escribo porque quiero preguntarte algo concreto:
    ¿se puede integrar Appium en la CI de Gitlab? No he encontrado nada que diga que sí explicitamente, pero tampoco nada que diga que no.
    La idea sería usarlo para desarrollos nativos Android e iOS, pero como te digo, no encuentro ningun sitio que describa claramente como configurar esto par gitlab. (No se si se me está escapando algo o que)

    Responder

Deja un comentario

¿Necesitas una estimación?

Calcula ahora