GitLab CI: configuración, stages y variables para automatización

GitLab CI reúne en un solo lugar la automatización que necesitas para integrar código de forma continua, reducir riesgos y acelerar entregas con confianza. Con un único archivo de configuración, .gitlab-ci.yml, puedes construir, probar y desplegar cambios de manera consistente y con poca intervención humana.

¿Qué hace GitLab CI en Continuous Integration y DevOps?

GitLab CI es el hub central de automatización que orquesta builds, tests y deploys continuos. Minimiza el riesgo de bugs nuevos y evita versiones que no compilan o no funcionan. Toda la configuración vive en .gitlab-ci.yml, escrito en yaml, un formato similar a json pero más legible.

• Automatización end-to-end desde que el desarrollador termina cambios hasta llegar a dispositivos de clientes.
• Menos fricción: menos pasos manuales y mayor consistencia.
• Configuración declarativa: se prioriza la claridad sobre la lógica compleja.

¿Cómo se conectan Continuous Delivery y Continuous Deployment?

• Continuous Delivery: siempre hay un artefacto listo para producción, pero el release se realiza con una acción manual aprobatoria.
• Continuous Deployment: el paso a producción se automatiza por completo; los releases suceden continuamente sin pasos manuales.

¿Cómo fluye el pipeline desde Source Control?

• Nuevo branch, commits y push al repositorio central detonan jobs de build y test.
• Si las pruebas fallan, se bloquea el merge con merge requests, evitando que código defectuoso llegue a producción.
• Ambientes dinámicos para review apps: con clusters como Kubernetes, cada branch puede levantar una app vinculada a la interfaz del merge request para ver cambios con un clic.
• Tras el merge, el deploy puede dispararse por Continuous Delivery (manual) o Continuous Deployment (automatizado).

¿Por qué los contenedores definen el ambiente?

• image global: .gitlab-ci.yml declara un contenedor base para el pipeline.
• Ejemplos: Node para Angular, Python para Flask.
• Hay miles de imágenes disponibles con los artefactos necesarios para tu build.

¿Cómo se configura .gitlab-ci.yml con keywords y stages?

El archivo es declarativo y se organiza por keywords. La mejor práctica es mover la lógica compleja a scripts externos, por ejemplo en package.json (sección scripts) o bash, dejando a .gitlab-ci.yml definir “qué” se ejecuta y “cuándo”.

¿Qué stages y jobs necesitas?

• Stages típicos: build, test y deploy. Puedes añadir otros como generar documentación o notificar en Slack.
• Jobs: tareas con nombre propio asignadas a un stage específico.
• variables: se pueden definir a nivel global o por job.
• script: la “carnita”, donde se automatiza lo que ocurrirá.

image: node:latest

stages:
  - build
  - test
  - deploy

Compile:
  stage: Build
  variables:
    ENV: dev
  script:
    - ng build
  only:
    - branches
  # También puedes usar 'accept' para definir cuándo no corre.

¿Cuándo debe ejecutar cada job?

• only y también accept permiten definir condiciones de ejecución.
• Otros keywords útiles a explorar: before script y after script para tareas previas y posteriores al job.

¿Qué tipos de variables ofrece GitLab CI y para qué sirven?

GitLab CI expone múltiples tipos de variables para parametrizar y asegurar tus pipelines. Bien usadas, refuerzan la seguridad, trazabilidad y control de despliegues.

¿Qué variables automatizan builds y despliegues?

• trigger variables: se inyectan automáticamente al detonar un nuevo build.
• project variables: propias del proyecto, útiles para credenciales o tokens.
• protected variables: visibles solo en proyectos o branches definidos, por ejemplo, secretos de producción expuestos únicamente en el branch master.
• group variables: disponibles a nivel de grupo para compartir configuración.
• variables de job: declaradas dentro de cada job en GitLabCI.yml.
• variables globales: definidas en la raíz de .gitlab-ci.yml.
• variables de deployment: usadas cuando se integran servicios de despliegue, como al conectar con Kubernetes.
• predefined variables: expuestas por GitLab en cada trabajo. Útiles para auditoría y trazabilidad porque incluyen, por ejemplo, el commit SHA que detonó el build, los tags y las referencias del job.

¿Con qué keywords y variables comenzarías a automatizar tu pipeline en GitLab CI? Comparte en comentarios tus casos de uso y en qué parte integrarías before script y after script.