GitLab CI/CD: Pipelines Automatizados a Escala

El archivo .gitlab-ci.yml en la raíz del repositorio define todo tu pipeline CI/CD. Declara stages (fases ordenadas), jobs (unidades de trabajo dentro de stages) y configuración global (imagen por defecto, variables, caching). GitLab parsea este archivo en cada push y crea un pipeline — un grafo acíclico dirigido de jobs que se ejecutan en GitLab Runners.

Las keywords globales aplican a todos los jobs: default establece la imagen base y timeout, variables define variables de entorno, y workflow:rules controla cuándo se crean pipelines. Usa include para importar templates compartidos de otros archivos o repositorios, manteniendo el archivo CI principal limpio. La keyword extends permite que los jobs hereden de jobs template prefijados con punto (ej: .build-template).

Un .gitlab-ci.yml bien organizado separa concerns: configuración global arriba, directivas include para templates compartidos, definiciones de stages, y luego jobs individuales agrupados por stage. Para proyectos grandes, dividí la configuración en múltiples archivos usando include:local para referenciar archivos dentro del mismo repositorio.

Los stages corren secuencialmente (test antes de build antes de deploy), pero los jobs dentro del mismo stage corren en paralelo. Este paralelismo es clave para pipelines rápidos: corre unit tests, lint y type-check simultáneamente en el stage de test. Usa needs para crear dependencias de jobs que bypasean el orden de stages — un job de deploy puede arrancar apenas termina el job de build, incluso si otros jobs del stage de test siguen corriendo (pipelines DAG).

Los artifacts son archivos producidos por un job y pasados a jobs downstream. Configura artifacts:paths para especificar archivos y artifacts:expire_in para auto-borrarlos (ej: 1 hour para salidas de build, 30 days para reportes de test). Usa artifacts:reports:junit para publicar resultados de test en la UI de merge request de GitLab. En producción, los reportes de cobertura de tests se suben como artifacts y se muestran directamente en los merge requests.

El caching persiste archivos entre ejecuciones de pipeline en el mismo runner. Usa cache:key para acotar caches (por rama, por job) y cache:paths para especificar directorios. Para Node.js, cachea node_modules/ con una key basada en el hash de package-lock.json: key: { files: ["package-lock.json"] }. Esto asegura que el cache se invalide cuando las dependencias cambien, ahorrando 30–90 segundos por job.

Las reglas de job (rules) reemplazan la sintaxis vieja only/except y proveen control granular sobre cuándo corren los jobs. Las reglas evalúan condiciones (nombre de rama, cambios en archivos, variables) y establecen atributos (when: on_success, manual, delayed). Un pipeline bien estructurado usa rules para saltar jobs innecesarios — por ejemplo, saltar jobs de deployment en pipelines de merge request, o saltar tests de frontend cuando solo cambiaron archivos de backend.

Las keywords only/except siguen funcionando pero se consideran legacy. Soportan nombres de rama, tags y triggers pero carecen de la composabilidad de rules. Un patrón común de migración: reemplaza only: [main] con rules: [{ if: '$CI_COMMIT_BRANCH == "main"' }]. A diferencia de only/except, las entradas de rules pueden combinar múltiples condiciones, establecer when y allow_failure, y usar changes para detectar modificaciones de archivos.

workflow:rules controla la creación de pipelines a nivel global — antes de que corra cualquier job. Usalo para prevenir pipelines duplicados cuando tanto un push de rama como un evento de merge request se disparan para el mismo commit. El patrón estándar crea pipelines para merge requests, commits tagueados y la rama por defecto, salteando todo lo demás. Esto elimina ejecuciones redundantes de pipeline y ahorra capacidad de runners.

Buildear imágenes Docker en CI requiere Docker-in-Docker (DinD) o Kaniko. DinD corre un daemon Docker dentro del contenedor CI, requiriendo modo --privileged — un riesgo de seguridad en ambientes de runners compartidos. Kaniko buildea imágenes sin daemon, corriendo enteramente en userspace. Ten en cuenta que Kaniko ya no tiene mantenimiento — Google archivó el proyecto el 3 de junio de 2025, y la propia documentación de GitLab ahora lo marca como no mantenido y apunta a Buildah o Podman en su lugar. Los pipelines Kaniko existentes siguen funcionando, pero los setups daemonless nuevos deberían preferir Buildah, Podman o el fork de Kaniko mantenido por la comunidad en Chainguard.

Kaniko en GitLab CI se configura como un job usando la imagen gcr.io/kaniko-project/executor. Pasa el contexto de build, ruta del Dockerfile y registry destino. Habilita cache de capas con --cache=true --cache-repo=$REGISTRY/cache para rebuilds drásticamente más rápidos. La autenticación al registry se maneja vía un archivo de clave JSON montado como variable CI/CD.

En producción, Kaniko eliminó la necesidad de runners privilegiados por completo. Los tiempos de build bajaron de 4 minutos (DinD con cache frío) a 90 segundos (Kaniko con cache de capas remoto). El template de job Kaniko se define una vez en una librería CI compartida y se incluye en los 20+ repositorios de microservicios, asegurando configuración de build consistente en toda la organización.

Los ambientes de GitLab trackean deployments a staging, producción y ambientes de review. Define un ambiente en un job de deploy con environment: { name: production, url: https://api.example.com }. GitLab trackea historial de deployments, habilita rollback desde la UI y muestra estado del ambiente en merge requests. Los ambientes protegidos restringen quién puede desplegar — solo maintainers pueden desplegar a producción.

Las review apps son ambientes dinámicos creados por merge request, que le dan a los developers una preview en vivo de sus cambios. El job de deploy crea el ambiente al abrir el merge request y un stop job lo destruye al mergear. Esto es poderoso para cambios de frontend donde la revisión visual importa. En producción, los ambientes de review despliegan a un namespace compartido de GKE con auto-limpieza después de 48 horas de inactividad.

El scoping de ambientes aplica también a las variables CI/CD. Configura DB_HOST a una base de datos de staging para el ambiente staging y una de producción para producción. Las variables pueden estar enmascaradas (ocultas en logs de jobs) y protegidas (solo disponibles en ramas protegidas). Esta separación asegura que los pipelines de staging nunca toquen accidentalmente recursos de producción.

Los GitLab Runners son los agentes que ejecutan jobs CI/CD. Vienen en tres alcances: runners compartidos están disponibles para todos los proyectos en una instancia GitLab (GitLab.com los provee por defecto en Linux), runners de grupo sirven a todos los proyectos dentro de un grupo, y runners específicos están asignados a proyectos individuales. Elige el alcance según requerimientos de seguridad, necesidades de recursos y costo.

Los tags de runner controlan qué runner toma un job. Taguea un runner macOS con macos y uno con GPU con gpu, luego usa tags: [macos] en la definición del job. Esto es esencial para builds móviles (macOS para iOS), cargas de ML (GPU) y compliance (runners on-premise para código sensible). En producción, los builds Fastlane iOS corren en un runner macOS dedicado tagueado macos-m1, mientras todos los demás jobs usan runners Linux compartidos.

Para runners self-managed, el tipo de executor determina cómo se aíslan los jobs. El executor Docker corre cada job en un contenedor nuevo (más común). El executor Kubernetes genera pods en un cluster, habilitando autoscaling. El executor Shell corre directamente en el host (útil para macOS). En producción, los runners de grupo usan el executor Kubernetes en GKE con autoscaling de 2 a 20 pods según profundidad de cola, manteniendo costos bajos fuera de hora pico mientras manejan cargas máximas.

Las variables CI/CD se definen en múltiples niveles: instancia, grupo, proyecto y job. Los niveles inferiores sobreescriben a los superiores, así que una variable de proyecto sobreescribe una variable de grupo con el mismo nombre. Define variables en el .gitlab-ci.yml para valores no sensibles (tags de imagen, feature flags) y en la UI de GitLab (Settings > CI/CD > Variables) para secrets como claves API, contraseñas de base de datos y credenciales de registry.

Protege variables marcándolas como protegidas (disponibles solo en ramas y tags protegidos) y enmascaradas (redactadas de logs de jobs). Para secrets que nunca deben aparecer en YAML, usa la integración de GitLab con gestores externos de secrets como HashiCorp Vault vía secrets:vault. Variables predefinidas como $CI_COMMIT_SHA, $CI_PIPELINE_ID y $CI_REGISTRY_IMAGE están disponibles en cada job automáticamente.

En producción, todos los secrets se almacenan como variables CI/CD enmascaradas y protegidas acotadas a sus respectivos ambientes. El pipeline de 41 apps Android de marca usa variables a nivel de grupo para configuración de firma compartida y variables a nivel de proyecto para claves específicas de marca. Una convención estricta: ningún secret en YAML, ninguna contraseña sin enmascarar, y rotación trimestral forzada mediante jobs de validación de pipeline.

Las librerías CI/CD compartidas son repositorios centrales de templates de pipeline reutilizables. En vez de duplicar configuración de .gitlab-ci.yml en 20+ repositorios, define templates una vez e incluirlos en todos lados. Un repositorio de templates contiene archivos YAML con jobs ocultos (prefijados con .) que los repositorios de servicio extienden. Los cambios a la librería compartida se propagan a todos los proyectos en su próxima ejecución de pipeline.

La keyword include soporta cuatro fuentes: local (mismo repo), file/project (otro proyecto GitLab), remote (cualquier URL) y template (templates mantenidos por GitLab). Organiza templates por concern: kaniko.yml para builds Docker, helm.yml para deployments Kubernetes, test-node.yml para testing Node.js, y security.yml para escaneo. Los repositorios de servicio incluyen el template y extienden el job oculto, sobreescribiendo solo lo que es específico del servicio.

En producción, el repositorio your-org/ci-templates contiene 8 templates compartidos usados por los 26 microservicios. Cuando la versión de Kaniko necesita actualizarse o se requiere un nuevo paso de escaneo de seguridad, un solo cambio en la librería compartida actualiza el pipeline de cada proyecto. Este enfoque centralizado redujo el mantenimiento de CI/CD de horas por semana a minutos por mes.

Auto DevOps es el pipeline CI/CD opinionado de GitLab que automáticamente detecta el lenguaje del proyecto, buildea, testea, escanea y despliega sin ninguna configuración .gitlab-ci.yml. Incluye Auto Build (usando Herokuish o Cloud Native Buildpacks), Auto Test, Auto Code Quality, Auto SAST, Auto Dependency Scanning, Auto Container Scanning, Auto Review Apps, Auto Deploy (a Kubernetes) y Auto Monitoring.

Auto DevOps es ideal para arrancar rápido o para equipos sin experiencia profunda en CI/CD. Habilitalo a nivel de proyecto o grupo. Detecta el lenguaje desde el contenido del repositorio (ej: un package.json indica Node.js) y aplica los pasos correspondientes de build y test. Para deployments Kubernetes, configura KUBE_CONTEXT o conecta un cluster vía el GitLab Kubernetes Agent.

Para equipos maduros, Auto DevOps sirve como punto de partida más que como solución final. En producción, los microservicios nuevos arrancan con Auto DevOps habilitado y gradualmente migran a archivos .gitlab-ci.yml custom a medida que sus requerimientos de pipeline se vuelven específicos (builds Kaniko custom, deployments Helm, builds móviles específicos de marca). El beneficio clave: ningún proyecto se lanza sin al menos CI/CD básico, porque Auto DevOps lo provee por defecto.

GitLab incluye escaneo de seguridad integrado: SAST (Testing Estático de Seguridad de Aplicaciones) analiza código fuente por vulnerabilidades, DAST (Testing Dinámico de Seguridad) escanea aplicaciones en ejecución por vulnerabilidades de runtime, el escaneo de dependencias chequea librerías de terceros por CVEs conocidos, y el escaneo de contenedores chequea imágenes Docker por vulnerabilidades a nivel de SO. Habilitalos incluyendo los templates de seguridad de GitLab.

Los resultados de SAST aparecen directamente en merge requests como anotaciones de código, mostrando exactamente qué línea tiene una vulnerabilidad y su severidad. El escaneo de dependencias compara tu lockfile (package-lock.json, Gemfile.lock, go.sum) contra bases de datos de vulnerabilidades. El dashboard de seguridad agrega hallazgos de todos los proyectos. Configura allowlists de vulnerabilidades para suprimir falsos positivos y umbrales de severidad para bloquear merges en hallazgos críticos.

Para escaneo custom, Trivy se integra fácilmente: agrega un job que ejecute trivy image --severity HIGH,CRITICAL --exit-code 1 $IMAGE en el stage de scan. Trivy es más rápido que el scanner de contenedores integrado de GitLab y produce menos falsos positivos. Combina con trivy fs para escaneo de filesystem y trivy config para detección de misconfiguración IaC (Terraform, YAML de Kubernetes, Dockerfiles). En producción, SAST, escaneo de dependencias y escaneo de contenedores corren en cada merge request, y los hallazgos críticos bloquean el merge hasta que se resuelvan.

Los pipelines de merge request corren sobre el resultado del merge — el código como se vería después de mergear, no solo la rama. Esto atrapa problemas de integración que los pipelines de rama no detectan. Habilita con workflow:rules que crean pipelines para merge requests y ramas protegidas. Usa $CI_MERGE_REQUEST_IID para ejecutar o saltar jobs condicionalmente.

Configura merge trains para encolar y testear merge requests automáticamente en forma secuencial. Cada MR en el tren se testea con los cambios combinados de todos los MRs que tiene adelante, asegurando que la rama main se mantenga verde. Si un MR en el tren rompe, se remueve y todos los MRs subsiguientes se retestean. Esto elimina el patrón de “mergear y rezar” que causa fallas en la rama main.

En producción, los pipelines de merge request ejecutan stages de test, lint, build y escaneo de seguridad. Los stages de deployment se saltan (solo corren en la rama main). La cobertura de código se muestra como anotaciones del merge request. El merge se bloquea si los tests fallan, la cobertura cae debajo del 80%, o SAST encuentra vulnerabilidades críticas. Esta puerta de calidad automatizada atrapa el 90% de los issues antes de que comience la revisión humana.

Los pipelines padre-hijo permiten que un job en el pipeline principal dispare un pipeline hijo definido en un archivo YAML separado. El pipeline padre genera o referencia la configuración del hijo, y GitLab lo corre como un pipeline vinculado. Esto es esencial para monorepos: detecta qué servicios cambiaron y dispara solo sus pipelines, evitando un único pipeline masivo que corra todo en cada commit.

Los triggers downstream (keyword trigger) arrancan pipelines en otros proyectos completamente. Usalos para dependencias cross-project: cuando se actualiza el repo de librería compartida, dispara pipelines en todos los repos consumidores para validar compatibilidad. Combina con strategy: depend para que el pipeline padre espere a que el pipeline downstream complete y refleje su estado. Pasa variables downstream con trigger:variables.

En producción, el monorepo que contiene librerías compartidas usa pipelines padre-hijo: el padre detecta paquetes cambiados, genera un YAML dinámico de pipeline hijo con trigger:include:artifact, y cada pipeline hijo testea solo el paquete afectado. Para triggers cross-project, actualizar el repo your-org/ci-templates dispara pipelines de validación en 5 servicios consumidores críticos para detectar cambios que rompan antes de que se propaguen.

GitLab CI se integra con Fastlane para automatización de builds iOS y Android. Fastlane maneja code signing, building, testing y publicación en App Store y Google Play. En GitLab CI, Fastlane corre dentro de un runner macOS (para iOS) o un runner Linux con Android SDK (para Android). Las variables CI/CD almacenan claves de firma, provisioning profiles y credenciales de store.

El pipeline móvil de la plataforma buildea 41 APKs Android de marca desde un solo codebase. Cada marca tiene diferente nombre de app, icono, colores y clave de firma. Una estrategia matrix en GitLab CI genera jobs paralelos para cada marca, con Fastlane aplicando configuración específica de marca en tiempo de build. El pipeline completo — buildear, firmar y subir 41 APKs a Google Play — se completa en menos de 3 horas.

Para iOS, Fastlane Match gestiona certificados de code signing y provisioning profiles en un repositorio Git privado. El runner CI obtiene credenciales vía Match, buildea la app con fastlane gym y sube a TestFlight con fastlane pilot. En producción, los builds iOS y Android se disparan automáticamente en tagged releases, eliminando el ciclo de release manual de 2 semanas que existía antes de la automatización CI/CD.

La plataforma corre pipelines GitLab CI/CD para 26 microservicios y 41 apps móviles de marca. La infraestructura CI/CD es el backbone de todo el workflow de desarrollo — cada cambio de código pasa por testing automatizado, escaneo de seguridad, build Docker y deployment Kubernetes sin intervención manual.

Componentes CI/CD y Catálogo (GA): Los Componentes CI/CD son unidades de configuración de pipeline reutilizables con parámetros de entrada tipados, evolucionando más allá del mecanismo tradicional de include. Los componentes están versionados, publicados en el Catálogo CI/CD y son descubribles en toda la organización. Cada proyecto puede publicar hasta 100 componentes. El Catálogo provee una interfaz buscable para encontrar y consumir componentes. Uso: include: component: gitlab.com/org/components/[email protected]. Esto cambia la configuración de pipeline de copiar-pegar YAML a distribución de software apropiada con versionado semántico.

Permisos Granulares de Job Token (18.3): GitLab ahora soporta job tokens con privilegio mínimo y scoping granular de permisos. En vez de acceso todo-o-nada con CI_JOB_TOKEN, puedes definir exactamente qué recursos puede acceder un token de pipeline. Los job tokens ahora pueden autenticar operaciones Git push, habilitando pipelines que hacen commit de vuelta al repositorio (ej: auto-versionado, generación de changelog) sin requerir personal access tokens. Esto elimina una preocupación de seguridad mayor en pipelines CI/CD.

Verificación de Validez de Secrets (GA en 18.7): Cuando GitLab detecta credenciales filtradas en tu repositorio (vía Secret Detection), ahora verifica si esas credenciales siguen activas y explotables. En vez de solo marcar filtraciones potenciales, GitLab contacta al proveedor del servicio (GitHub, AWS, GCP, Slack, etc.) para chequear si el secret está vivo. Los secrets activos se marcan como críticos, mientras los secrets revocados se marcan como resueltos. Esto reduce drásticamente el ruido de alertas y enfoca la remediación en riesgos reales.

SLSA Nivel 1 para Componentes Reutilizables: Los Componentes CI/CD publicados en el Catálogo ahora llevan atestaciones de seguridad de cadena de suministro conformes a SLSA (Supply-chain Levels for Software Artifacts) Nivel 1. Esto provee metadata de procedencia sobre cómo se construyeron y publicaron los componentes, estableciendo confianza en configuraciones de pipeline reutilizables. Combinado con pipelines firmados, esto crea una cadena de confianza auditable desde el código fuente del componente hasta la ejecución del pipeline.

GitLab 18.11 (16 de abril de 2026): El release 18.11 introdujo el CI Expert Agent (beta), que examina repositorios y propone configuraciones completas de pipeline CI/CD desde descripciones en lenguaje natural -- sin necesidad de YAML manual. El Data Analyst Agent es ahora GA, habilitando consultas en lenguaje natural sobre analytics de proyecto y métricas CI/CD sin escribir SQL. La Resolución de Vulnerabilidades SAST Agéntica es ahora GA para clientes Ultimate, analizando automáticamente resultados de escaneo de seguridad, generando correcciones de código con scores de confianza y creando merge requests. Los escaneos incrementales de Advanced SAST analizan solo el código cambiado, reduciendo drásticamente los tiempos de escaneo. La lista de plataformas LLM self-hosted ahora incluye Mistral AI, Azure OpenAI y endpoints custom compatibles con OpenAI junto a AWS Bedrock y Google Vertex AI. Kubernetes 1.35 es soportado por el GitLab Agent for Kubernetes. Los controles de gasto para GitLab Credits permiten a las organizaciones establecer topes mensuales a nivel de suscripción y por usuario en el uso de features de AI.

GitLab 19.0 (21 de mayo de 2026): La nueva versión mayor incluye GitLab Secrets Manager en beta abierta para Premium y Ultimate -- una alternativa nativa a HashiCorp Vault o AWS Secrets Manager para secretos de CI/CD. Los job tokens ganan soporte de push entre proyectos: un pipeline ahora puede hacer push a otro repositorio con CI_JOB_TOKEN en vez de personal access tokens o deploy tokens. Los inputs de CI/CD agregan acceso por índice de array y selección de múltiples valores en la UI de pipelines. El Catálogo CI/CD gana analíticas detalladas de uso de componentes (Ultimate), mostrando qué proyectos consumen cada componente y qué versiones fijan. Los merge trains obtienen límites configurables de pipelines paralelos (antes fijo en 20), y el escaneo de dependencias basado en SBOM alcanza disponibilidad general con cobertura completa de dependencias transitivas para Maven, Gradle y Python. Para instancias self-managed, 19.0 eleva la versión mínima de PostgreSQL a 17, elimina el soporte de Redis 6 y descontinúa los paquetes de Ubuntu 20.04. GitLab Runner 19.0 se lanza en conjunto.

GitLab 19.1 (18 de junio de 2026) y 19.2 (16 de julio de 2026): 19.1 agregó políticas de ejecución de pipelines programados en beta — impone jobs de CI/CD en cadencias diaria, semanal o mensual sobre todos los proyectos en alcance, independientemente de la actividad de commits —, hizo que las analíticas de CI/CD calculen las tasas de falla y éxito solo con pipelines completados (excluyendo cancelados y saltados), extendió la detección de secretos en ramas feature para escanear cada commit desde el punto de divergencia, agregó integración con escáneres externos SARIF 2.1.0, y lanzó el rol Security Manager como GA. 19.2 promovió las políticas de ejecución de pipelines programados a GA para Ultimate, hizo el CI Expert Agent generalmente disponible desde Free en adelante para crear, depurar y optimizar pipelines, agregó rebase automático antes del merge para los métodos semi-linear y fast-forward en todos los tiers, e introdujo auto-remediación del escaneo de dependencias en beta, que abre merge requests para actualizar dependencias vulnerables. GitLab Duo CLI lleva la Duo Agent Platform a la terminal con contexto sobre tus proyectos, pipelines y configuraciones de agentes.