Hoy voy a enseñarte a dar tus primeros pasos con algunos conceptos básicos de GitLab CI, que es la herramienta de integración continua de nuestros amigos de GitLab. De esta forma, podrás configurar tu repositorio para construir los proyectos automáticamente cuando hagas push a una rama, por ejemplo. O pasar los tests e, incluso, automatizar despliegues automáticos en tus diferentes servidores de una forma más que sencilla.

Por muy profesional que sea o experiencia que tenga, este artículo es sólo para intentar atraerte a este mundo y mostrarte sus bondades de una forma relativamente masticada. Si quieres profundizar y convertirte en un experto, nada mejor que la documentación oficial.

Tu servidor vs. gitlab.com

Por si no lo sabes, además de gitlab.com, puedes descargar tú mismo los ejecutables y montarte tu servidor, lo que tiene sus ventajas y desventajas. Generalmente, instalar tu propio servidor de gitlab conlleva una gran retaila de ventajas, pero también acarrea un mayor mantenimiento y, por supuesto, una curva de aprendizaje mucho más empinada.

Para poder habilitar en tu propio servidor de gitlab los runner, necesitas instalar el servicio aparte. Yo me voy a centrar, para aprender los conceptos básicos, en cómo configurar un entorno básico en gitlab.com sin necesidad de todo esto. Si quieres aprender cómo montar todo el tinglado de gitlab runner para un entorno de integración continua en tu propio servidor, te recomiendo encarecidamente este otro artículo de mi compañero Rubén Aguilera.

Conceptos básicos de GitLab CI

A continuación te defino algunas palabras que vas a ver contínuamente y es importante conocer bien. No hace falta que las estudies de memoria, del propio uso la vas a concer y, si vienes de otros entornos de integración continua, seguro que ya las conoces más que de sobra:

.gitlab-ci.yml: este es el archivo que deberás añadir a tu proyecto (sí, es un archivo oculto). Utiliza, como puedes deducir de la extensión, la sintaxis yaml y te permitirá definir diferentes etapas de ejecución según las ramas de tu repositorio, entre otras muchas cosas.

Pipeline: hace referencia al conjunto de tareas que deben ejecutarse en un punto concreto. Puede ser, por ejemplo, pasar los tests y (si pasan) desplegar en preproducción, o pasar el sonar, etc.

Stage: cada fase del pipeline. Imagínate un pipeline que construye el proyecto y genera un binario que, después, despliega en un servidor. Pues un stage es construir y otro stage es desplegarlo, por ejemplo. Bueno, pues así de simple. Más adelante, cuando veas el código, lo entenderás.

Runner:un runner es la unidad mínima de ejecución. Es el servicio de gitlab en el que se ejecutará la orden que programes. Es el concepto más complejo y, a la vez, el más básico. Cuando crees un runner, si eres el administrador del servidor de gitlab, puedes configurarlo, por ejemplo, para que sea un runner de terminal (sh). Eso significa que, cada comando que programes, se ejecutará directamente en la máquina del servidor. Si, por ejemplo, necesitas java, tendrás que instalarlo en el servidor para poder utilizarlo. Otra opción (entre muchas) es configurar un runner de docker. Esto te permite que especifiques en tu archivo de configuración (el .yml) qué imagen quieres utilizar y los comandos que programes en cada fase, serán ejecutados sobre ese servicio virtualizado.

Configuración básica

Hay que tener clara una cosa: pueden tenerse varios runners en un mismo servidor. Pueden ser compartidos entre varios proyectos o incluso configurar un runner específico para cada proyecto. En el servidor público, usarás los shared runners. Son runners compartidos entre todos los proyectos del servidor (y sí, en gitlab.com son compartidos entre TODOS).

Para habilitar los runners para tu proyecto, ve a la sección de ajustes > CI/CD  y expande la sección de runners. Ahí podrás habilitar tus shared runners. Si quieres ver un ejemplo de un gitlab-ci.yml, te dejo uno aquí mismo:

stages:
  - test
  - deploy

services:
  - mysql:8

variables:
  MYSQL_DATABASE: mon3x
  MYSQL_ROOT_PASSWORD: root

image: openjdk:13

all-tests:
  stage: test
  script:
    - ./mvnw clean verify -Dspring.profiles.active=pre
  only:
    - develop

pages:
  stage: deploy
  script:
    - ./mvnw generate-resources
    - mkdir .public
    - cp -r target/generated-docs/index.html .public
    - mv .public public
  artifacts:
    paths:
      - public
  only:
    - master

Al inicio del fichero se definen dos stages. Después, cada job se ejecuta en su correspondiente stage. El job llamado «all-tests», por ejemplo, se ejecuta en el stage de test, tal y como lo indica la etiqueta «stage» del mismo.

La parte de «services» indica que queremos conectarnos a una base de datos mysql versión 8. Se pone así porque el shared runner de gitlab dispone de contenedores de mysql para que tu contenedor pueda conectarse a ellos. Cuenta con más servicios. Ya sabes, la documentación oficial te contará todo de lo que disponen.

Podemos ver, además, un apartado de variables: el nombre de la base de datos que debe crear en el contenedor asociado con mysql y la contraseña para que nuestro proyecto se conecte y ejecute los tests.

Por últio, en la etiqueta de imagen, especificamos que el contenedor principal es un contenedor de java 13. De esta forma, en este contenedor java 13 se ejecutarán los scripts y, cuando necesiten contectarse a una base de datos, tendrán el otro contenedor a su disposición.

Espero que estos conceptos básicos de GitLab CI puedan ayudarte y hacerte a tí el camino un poquito más fácil de lo que fue para mí. Recuerda: esto es solo una pequeñísima parte de todo lo que puedes hacer con esta herramienta. Nunca dejes de aprender.