Lección 146: Práctica: configuración del pipeline para CI/CD en GitLab

En esta lección aprenderemos:

1. Crear y configurar un pipeline en GitLab CI para una aplicación Spring Boot.
2. Implementar las etapas de build, test y deploy.
3. Entender cómo monitorizar la ejecución del pipeline y arreglar errores.

Así que, ¡prepárate! Configurar un pipeline de CI/CD es como reinstalar el sistema operativo: no apetece hacerlo, pero después todo funciona (al menos, debería).

Por qué necesitamos configurar un pipeline de CI/CD

Cada vez que los desarrolladores añaden nuevo código, nuestro proceso de build, test y despliegue debe ejecutarse automáticamente. Esto acelera mucho el desarrollo y minimiza el factor humano (es decir, menos "errores accidentales").

Escenario real

Imagina que tu equipo desarrolla una aplicación Spring Boot. Cada commit al repositorio lanza un pipeline que:

• Comprueba que el proyecto se compila.
• Ejecuta todos los tests automáticos.
• Despliega la aplicación en un entorno de prueba y/o staging.
• Al final, pone la aplicación verificada en production.

Si el pipeline falla, GitLab te mostrará claramente dónde ocurrió el error. Eso es lo que vamos a configurar.

Construcción del pipeline: etapas principales

Empecemos creando el archivo .gitlab-ci.yml en la raíz de nuestro proyecto. Ese es el "corazón" del pipeline de GitLab CI, donde describimos todas las etapas.

stages: # Definimos las etapas de nuestro pipeline
  - build
  - test
  - deploy

Aquí indicamos las etapas principales:

1. build: compilación del proyecto.
2. test: testing (unit y/o integration tests).
3. deploy: despliegue en entorno staging o production.

La etapa "build" se encarga de compilar nuestra aplicación. Para Spring Boot usaremos Maven.

build:
  stage: build
  image: maven:3.8.5-openjdk-17 # Imagen Docker con Maven y Java 17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar # Guardamos el artefacto JAR compilado
  only:
    - main # Ejecutamos esta etapa solo en la rama main

Repasemos los puntos clave:

• image: indicamos la imagen Docker donde se ejecutará esta etapa (aquí Maven + JDK 17).
• script: comandos a ejecutar. Llamamos a mvn clean package para compilar el proyecto.
• artifacts: guardamos los artefactos resultantes (en este caso los JAR).
• only: ejecutamos esta etapa solo en la rama "main", para no construir cada rama de prueba.

Ahora añadimos el testing. Esta etapa es importante para asegurarnos de que el nuevo código no rompe la funcionalidad existente.

test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test # Ejecutamos todos los tests
  only:
    - merge_requests # Ejecutamos tests para merge requests

Qué hace esta etapa:

• Usa la misma imagen Docker que la de build.
• Se ejecuta el comando mvn test, que valida nuestro código.
• Está configurado para ejecutarse en merge requests, ya que el sentido principal del testing es revisar el código antes de mergearlo en la rama principal.

La etapa de deploy se encarga del despliegue de la aplicación. Para empezar configuraremos el deploy en un entorno staging.

deploy:
  stage: deploy
  image: docker:20.10.16 # Usamos Docker para el despliegue
  services:
    - docker:dind # Docker-in-Docker para trabajar con contenedores
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main # El despliegue se ejecuta solo desde la rama main

Desgranando los detalles:

• image y services: usamos Docker para el despliegue.
• script: construimos la imagen Docker de nuestra aplicación y lanzamos el contenedor.
• only: el deploy se hace solo desde la rama principal (main).

Ejemplo completo del pipeline

Así es como queda el archivo .gitlab-ci.yml completo con todas las etapas:

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: maven:3.8.5-openjdk-17
  script:
    - mvn clean package -DskipTests
  artifacts:
    paths:
      - target/*.jar
  only:
    - main

test:
  stage: test
  image: maven:3.8.5-openjdk-17
  script:
    - mvn test
  only:
    - merge_requests

deploy:
  stage: deploy
  image: docker:20.10.16
  services:
    - docker:dind
  script:
    - docker build -t my-spring-app:latest .
    - docker run -d -p 8080:8080 my-spring-app:latest
  only:
    - main

Ahora tenemos un pipeline funcionando que, por etapas:

1. Compila la aplicación (build).
2. Ejecuta los unit tests (test).
3. Despliega la aplicación compilada en un contenedor (deploy).

Cómo seguir el pipeline

Después de un commit en GitLab:

1. Abre la pestaña CI/CD → Pipelines.
2. Verás la lista de pipelines lanzados y su estado (success, failed, running, etc.).
3. Si algo va mal, puedes clicar en la etapa concreta y ver los logs de ejecución.

Errores típicos y cómo solucionarlos

• Error: "Docker daemon not available"
  Asegúrate de haber añadido docker:dind en la sección services.
• Error de build "Unable to find dependency"
  Revisa el archivo pom.xml — puede que una dependencia esté mal indicada o que no haya acceso a los repositorios Maven.
• Los tests fallan en la etapa "test"
  Siempre revisa tus tests localmente antes de pushearlos al repositorio.

Ahora estás listo para automatizar la compilación, testing y despliegue de tu aplicación Spring Boot usando GitLab CI. Y no te asusten los errores. Son inevitables, pero se pueden vencer.