En el mundo del desarrollo de software, la automatización de despliegues con GitLab CI/CD se ha convertido en una solución indispensable para equipos que buscan optimizar su flujo de trabajo. Imagina un escenario en el que, debido a la dependencia de una sola persona para realizar despliegues manuales, todo el equipo se ve paralizado porque esa persona no puede conectarse al servidor. Esto fue exactamente lo que nos sucedió a nosotros, y fue el detonante para adoptar una herramienta de integración y despliegue continuo (CI/CD) que nos permitiera trabajar de manera más eficiente y colaborativa.

La automatización de procesos con GitLab CI/CD no solo resolvió nuestros problemas de despliegues manuales, sino que también nos ayudó a reducir errores, acelerar la entrega de nuevas funcionalidades y mejorar la calidad del software. Con GitLab CI/CD, logramos crear pipelines que automatizan desde la integración del código hasta el despliegue en producción, eliminando cuellos de botella y permitiendo que todos los miembros del equipo participen activamente en el proceso.

En este artículo, te cuento cómo implementamos esta solución en mi empresa – para varios de los proyectos que tenemos para un cliente importante -, los desafíos que superamos y las mejores prácticas que aprendimos en el camino. Si tu equipo aún depende de despliegues manuales o enfrenta problemas similares, esta guía te mostrará cómo GitLab CI/CD puede transformar tu flujo de trabajo. Descubre cómo la automatización de despliegues con GitLab CI/CD no solo optimiza tus procesos, sino que también fomenta la colaboración y la eficiencia en equipos de desarrollo.

GitLab CI/CD es una herramienta integrada en la plataforma GitLab que permite automatizar el proceso de Integración Continua (CI) y Despliegue Continuo (CD). Aquí te explico cómo funciona paso a paso:

1. Integración Continua (CI):

• ¿Qué es?: La Integración Continua es una práctica en la que los desarrolladores integran su código en un repositorio compartido varias veces al día. Cada vez que se realiza un cambio, se ejecutan pruebas automatizadas para asegurarse de que el nuevo código no rompa la aplicación.
• Cómo funciona en GitLab:
  • Cuando un desarrollador hace un push de código a una rama (por ejemplo, feature-branch), GitLab detecta el cambio y activa automáticamente un pipeline.
  • El pipeline es una serie de jobs (tareas) que se ejecutan en secuencia. Estos jobs pueden incluir:
    • Build: Compilar el código o preparar los archivos necesarios.
    • Test: Ejecutar pruebas unitarias, de integración o de extremo a extremo.
    • Lint: Verificar la calidad del código (por ejemplo, con herramientas como ESLint o PHP_CodeSniffer).
  • Si todas las pruebas pasan correctamente, el código puede fusionarse en la rama principal (main o develop).

2. Despliegue Continuo (CD):

• ¿Qué es?: El Despliegue Continuo es el proceso de llevar automáticamente el código validado a los entornos de staging o producción, sin necesidad de intervención manual.
• Cómo funciona en GitLab:
  • Una vez que el código ha pasado las pruebas en la etapa de CI, el pipeline puede continuar con la etapa de despliegue.
  • GitLab permite configurar diferentes entornos (por ejemplo, staging y producción) y definir reglas para cuándo y cómo se despliega el código en cada uno.
  • Por ejemplo, puedes configurar que el código solo se despliegue en producción después de que se haya fusionado en la rama main y haya sido aprobado por un revisor.

3. Componentes clave de GitLab CI/CD:

Reglas y condiciones: Puedes definir reglas para controlar cuándo se ejecutan los jobs. Por ejemplo, puedes hacer que un job solo se ejecute en la rama main o cuando se crea un Merge Request.

.gitlab-ci.yml: Este es el fichero de configuración que define cómo funciona el pipeline. En él, especificas las etapas (stages), los jobs y las reglas para ejecutarlos.

GitLab Runner: Es un agente que ejecuta los jobs definidos en el pipeline. Puede estar instalado en un servidor local, en la nube o incluso en un contenedor Docker.

Variables de entorno: GitLab permite definir variables de entorno (como credenciales o URLs de servidores) que se pueden usar en los jobs sin exponer información sensible.

4. Ejemplo de un pipeline básico:

Un pipeline típico en GitLab podría tener las siguientes etapas:

• build: Compilar el código y preparar los archivos.
• test: Ejecutar pruebas automatizadas.
• deploy: Desplegar el código en un entorno específico (staging o producción).

Aquí tienes un ejemplo simplificado de un fichero de configuración o Pipeline .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Compilando el código..."
    - npm install
    - npm run build

test_job:
  stage: test
  script:
    - echo "Ejecutando pruebas..."
    - npm test

deploy_staging:
  stage: deploy
  script:
    - echo "Desplegando en staging..."
    - npm run deploy:staging
  only:
    - main

Cómo configurar GitLab CI/CD: Creación del fichero .gitlab-ci.yml

GitLab es una plataforma que no solo te permite gestionar tu código, sino también automatizar flujos de trabajo mediante su herramienta integrada de CI/CD. Para comenzar, necesitas crear un fichero llamado .gitlab-ci.yml en la raíz de tu repositorio. Este fichero es el corazón de tu pipeline y define qué tareas se ejecutarán y en qué orden.

La estructura básica de un fichero .gitlab-ci.yml incluye:

• stages: Define las etapas del pipeline. Por ejemplo, puedes tener etapas para clonar el repositorio, ejecutar pruebas y desplegar la aplicación.
• jobs: Define las tareas que se ejecutan en cada etapa. Cada job tiene un nombre y un conjunto de instrucciones que se ejecutan en orden.

A continuación, te mostraré un ejemplo práctico basado en un proyecto real, para que puedas ver cómo funciona todo esto en la práctica.

Instalación y configuración de GitLab Runner en Ubuntu

Antes de poder ejecutar pipelines de CI/CD, es necesario configurar un GitLab Runner en un servidor. Un GitLab Runner es un agente que ejecuta los jobs definidos en tu fichero .gitlab-ci.yml. Para instalarlo en un servidor Ubuntu, sigue estos pasos:

sudo apt update && sudo apt upgrade -y

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt install gitlab-runner

sudo gitlab-runner register

sudo gitlab-runner start

sudo gitlab-runner status

Pipeline en acción: Ejemplo práctico para un proyecto Laravel con Tailwind CSS y Vue.js

En este ejemplo, vamos a configurar un pipeline para un proyecto Laravel que utiliza Tailwind CSS para los estilos y Vue.js para la interactividad del frontend, además, el proyecto está desplegado en una arquitectura Docker, que incluye contenedor de base de datos MySQL, contenedor de Apache2 y contenedor de PHP-FPM.
 El pipeline consta de tres etapas principales: pull_code (para clonar el repositorio), test (para ejecutar pruebas) y deploy_app (para desplegar la aplicación).
Aquí está el fichero .gitlab-ci.yml.

Nota: Por privacidad, se han eliminado referencias al cliente y producto y reemplazadas por «myApp»

stages:
  - pull_code
  - test
  - deploy_app

pull_code:
  stage: pull_code
  script:
    - git -C /opt/myapp pull https://$GIT_USERNAME:$GIT_PAT@source.example.com/myorg/myapp.git main
  artifacts:
    paths:
      - /opt/myapp
  only:
    - main  # Solo se ejecuta en la rama 'main'
  tags:
    - ubuntu  # Se ejecuta en un runner con la etiqueta 'ubuntu'

test:
  stage: test
  script:
    - echo "Ejecutando pruebas de Laravel..."
    # Ejecuta pruebas unitarias de Laravel
    - docker exec -t php-container bash -c "cd /var/www/html && php artisan test"
  only:
    - main
  tags:
    - ubuntu

deploy_app:
  stage: deploy_app
  script:
    - echo "Desplegando aplicación..."
    # Verifica si el contenedor de PHP está en ejecución
    - docker ps | grep php-container || echo "El contenedor de PHP no está en ejecución"

    # Ejecuta composer dumpautoload dentro del contenedor
    - docker exec -t php-container bash -c "cd /var/www/html && composer dumpautoload"

    # Ejecuta migraciones de Laravel dentro del contenedor
    - docker exec -t php-container bash -c "cd /var/www/html && php artisan migrate"
    
    # Compila el frontend, ejecuta NPM dentro del contenedor
    - docker exec -t php-container bash -c "cd /var/www/html && npm run build"
  only:
    - main  # Solo se ejecuta en la rama 'main'
  tags:
    - ubuntu  # Se ejecuta en un runner con la etiqueta 'ubuntu'

Explicación detallada:

1. pull_code:
   • Clona el repositorio en un directorio específico (/opt/myapp).
   • Guarda el contenido clonado como un artefacto, lo que significa que estará disponible para las siguientes etapas.
2. test:
   • Pruebas de Laravel: Ejecuta las pruebas unitarias de Laravel utilizando el comando php artisan test.
3. deploy_app:
   • Verifica si el contenedor Docker php-container está en ejecución.
   • Ejecuta comandos dentro del contenedor para:
     • actualizar dependencias (composer dumpautoload) 
     • ejecutar migraciones (php artisan migrate)
     • construir los assets del frontend (npm run build).

Una vez configurado nuestro fichero de pipeline, lo añadiremos a la configuración de CI/CD de nuestro repositorio. Para ello accederemos dentro de nuestro repositorio, al menú Build y ahí en la opción Pipeline editor . Seleccionaremos entonces la rama sobre la que queremos aplicar CI/CD e introduciremos nuestro código YAML en el editor.

El pipeline anteriormente descrito mediante YAML puede expresarse de forma gráfica así

Gestión segura de variables de entorno en GitLab CI/CD

Las variables de entorno son una parte fundamental de cualquier pipeline de CI/CD, ya que permiten almacenar información sensible (como credenciales o tokens) y configuraciones específicas del entorno. En nuestro caso, debido a la configuración del repositorio GIT, que se debe utilizar mediante PAT ( Personal Access Token ), necesitamos que nuestros Pipelines de CI/CD incluyan la configuración necesaria en forma de variable de entorno, para poder hacer pull del repositorio.

En GitLab, puedes definir variables de entorno de dos maneras:

1. Variables de entorno a nivel de proyecto

Estas variables están disponibles solo para el proyecto en el que se definen.
Para configurarlas:

• 1. Ve a la sección CI/CD de tu proyecto en Gitlab.
• 2. Haz click en variables
• 3. Agrega dos nuevas variables con nombre y un valor.
  Por ejemplo:
  • Variable 1, para el usuario de GIT:
    • Nombre: GIT_USERNAME
    • Valor: mi_usuario_de_gitlab
  • Variable 2, para el PAT de GIT:
    • Nombre: GIT_PAT
    • Valor: mi_token_pat_gitlab

2. Variables de entorno a nivel de grupo o instancia
Estas variables están disponibles para todos los proyectos dentro de un grupo o instancia de GitLab. Son útiles para configuraciones compartidas, como credenciales de acceso a servicios comunes.

Uso de variables de entorno en el pipeline

Una vez definidas, puedes usar las variables de entorno en tu fichero .gitlab-ci.yml. Por ejemplo:

pull_code:
  stage: pull_code
  script:
    - git -C /opt/myapp pull https://$GIT_USERNAME:$GIT_PAT@source.example.com/myorg/myapp.git main
  artifacts:
    paths:
      - /opt/myapp
  only:
    - main  # Solo se ejecuta en la rama 'main'
  tags:
    - ubuntu  # Se ejecuta en un runner con la etiqueta 'ubuntu'

Protección de variables sensibles
GitLab permite marcar variables como protegidas o enmascaradas:

• Protegidas: Solo están disponibles en pipelines que se ejecutan en ramas protegidas (como main o production).
• Enmascaradas: Su valor no se muestra en los logs del pipeline, lo que las hace ideales para contraseñas o tokens.

Para marcar una variable como protegida o enmascarada, simplemente activa las opciones correspondientes al crearla en la interfaz de GitLab.

Listado de pipelines ejecutadas

Trabajos de la pipeline

Salida de ejecución de un Job

1. Activación de pipelines

Las pipelines se ejecutan automáticamente en los siguientes casos:

• Trigger manual: Algunas pipelines pueden configurarse para ejecutarse manualmente, lo que es útil para despliegues en producción que requieren aprobación.
• Push a una rama: Cuando haces un push a una rama en tu repositorio, GitLab ejecuta automáticamente la pipeline asociada a esa rama.
• Merge Request (MR): Cuando creas o actualizas un Merge Request, GitLab puede ejecutar una pipeline para verificar que los cambios no rompan el código.
• Programación (Schedules): Puedes configurar pipelines para que se ejecuten en horarios específicos, como cada noche o los fines de semana.

2. Condiciones para ejcutar jobs

Cada job en una pipeline puede tener reglas específicas que determinan cuándo se ejecuta. Estas reglas se definen con las siguientes directivas:

only y except

only: Especifica cuándo un job debe ejecutarse. Por ejemplo, puedes limitar un job a una rama específica:

deploy_production:
  stage: deploy
  script:
    - echo "Desplegando en producción..."
  only:
    - main

except: Especifica cuándo un job no debe ejecutarse. Por ejemplo, puedes evitar que un job se ejecute en ramas de desarrollo:

test:
  stage: test
  script:
    - echo "Ejecutando pruebas..."
  except:
    - development