Lección 145: Integración con GitLab CI: compilación y pruebas automáticas

Hoy vamos a profundizar en GitLab CI, la herramienta integrada del sistema de control de versiones GitLab para gestionar procesos de CI/CD. Su principal ventaja es la integración seamless con el repositorio de código. Desde GitLab puedes describir todo el proceso de build, test e incluso deploy usando un archivo YAML normalito.

Conceptos básicos de GitLab CI

Antes de ponernos con la práctica, un poco de teoría:

• Pipeline — un conjunto de etapas que automatizan todo el proceso (por ejemplo: build → test → deploy).
• Stage — una etapa individual del pipeline (por ejemplo, "test" o "build").
• Job — una tarea dentro de una stage (por ejemplo, lanzar los tests).
• Runner — el ejecutor que lanza tus jobs. Puede ser local o estar alojado por GitLab.

Es un poco como una línea de montaje en una fábrica: el código entra por un extremo, y tu pipeline CI/CD, como un robot bien entrenado, compila, prueba, valida y, voilà, ¡todo listo!

Objetivos de esta lección

En la sesión de hoy vamos a:

1. Crear un .gitlab-ci.yml básico para un proyecto Spring Boot.
2. Configurar las etapas de build y test.
3. Asegurarnos de que la compilación y las pruebas automáticas pasen con éxito en cada commit.

Práctica: Configurar GitLab CI para un proyecto Spring Boot

1. Preparación del proyecto Spring Boot

Antes que nada, asegúrate de que tu proyecto Spring Boot ya existe y está configurado para funcionar con Maven. Por ejemplo, tenemos una pequeña aplicación que usa controllers, services y repositories.

Estructura del proyecto:

my-spring-boot-app/
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   │        └── application.yml
│   ├── test/
│   │   ├── java/
│   │   └── resources/
├── pom.xml

Si todavía no tienes tu propio proyecto — créalo con Spring Initializr (https://start.spring.io).

Ahora que tu proyecto está listo, añadamos un poco de "magia de automatización".

2. Creación del archivo .gitlab-ci.yml

Este es el archivo clave para configurar los pipelines de CI/CD; es el que controla la automatización. El archivo debe estar en la raíz de tu repositorio.

Ejemplo de .gitlab-ci.yml para un proyecto Spring Boot:

stages: # Definimos las etapas del pipeline
  - build
  - test

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=/cache/.m2/repository" # Almacenamos en caché las dependencias locales de Maven

build:
  stage: build
  image: maven:3.8.5-openjdk-11 # Usamos una imagen Docker con Maven y JDK
  script:
    - mvn clean compile # Comando para compilar el proyecto
  artifacts:
    paths:
      - target/ # Pasamos los artifacts (p. ej., archivos jar) a las siguientes etapas

test:
  stage: test
  image: maven:3.8.5-openjdk-11
  script:
    - mvn test # Ejecutamos los tests
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml # Registramos los resultados de los tests

¡Listo! Ahora expliquemos qué hemos escrito aquí.

• stages: indicamos las etapas del pipeline que se ejecutarán en orden: primero build, luego test.
• image: usamos una imagen Docker con Maven y Java 11. Esto ayuda a reproducir el entorno de build.
• variables: aquí definimos la configuración de Maven para acelerar la compilación con caching de dependencias.
• script: conjunto de comandos que deben ejecutarse en cada etapa.
• artifacts: archivos que se pasan entre etapas o que se incluyen en los resultados del pipeline.

P.D.: Puede que YAML se lea como un montón de hechizos. Pero en realidad lo importante es saber distinguir las indentaciones y recordar que los dos puntos (:) separan clave y valor.

3. Probar el pipeline

1. Haz commit del archivo .gitlab-ci.yml en el repositorio:

   
   git add .gitlab-ci.yml
   git commit -m "Añadí GitLab CI"
   git push origin main
   

2. Abre GitLab y ve a CI/CD → Pipelines. Allí verás la ejecución del pipeline. Si todo está bien configurado, las etapas build y test se ejecutarán con éxito (color verde 🎉).

Errores frecuentes y cómo solucionarlos

1. Error: "No such file or directory"
   • Significa que el GitLab Runner no puede encontrar algún archivo o directorio (por ejemplo, pom.xml). Asegúrate de que tu proyecto está correctamente subido al repositorio.
2. Error: "Permission denied"
   • Puede que el Runner no tenga permisos para ejecutar comandos. Revisa los permisos del Runner.
3. Error de build: "Dependency not found"
   • Asegúrate de que tu proyecto Maven está bien configurado y que todas las dependencias están declaradas en pom.xml.

¿Y cómo te ayudará esto en la vida real?

Cada vez que hagas cambios en el repositorio (por ejemplo, añadas nueva funcionalidad), tu código se compilará, testeará y validará automáticamente. Así sabrás al instante si algo se ha roto.

Ahora adelante — añade la automatización, que estás a un paso de crear un pipeline verdaderamente profesional.