GitLab CI/CD

Cómo funciona

El archivo .gitlab-ci.yml define jobs y reglas. Los runners ejecutan el trabajo; etapas, dependencias y artefactos coordinan el recorrido. Las aprobaciones y los ambientes permiten controlar promociones.

Ejemplo: probar un proyecto Node.js

Este pipeline requiere un repositorio con package-lock.json y un script test:

stages: [test]

pruebas:
  image: node:22
  stage: test
  script:
    - npm ci
    - npm test

Pipeline completo de ejemplo

stages: [build, test, deploy]

default:
  interruptible: true # cancela pipelines antiguos de la misma rama

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

variables:
  MAVEN_OPTS: '-Dmaven.repo.local=$CI_PROJECT_DIR/.m2'

build:
  stage: build
  image: maven:3-eclipse-temurin-21
  cache: { key: maven, paths: [.m2/] }
  script: ./mvnw -q package -DskipTests
  artifacts: { paths: [target/*.jar], expire_in: 1 week }

pruebas:
  stage: test
  image: maven:3-eclipse-temurin-21
  needs: [build]
  cache: { key: maven, paths: [.m2/], policy: pull }
  script: ./mvnw -q verify
  artifacts:
    reports: { junit: target/surefire-reports/*.xml }

deploy_prod:
  stage: deploy
  needs: [pruebas]
  image: google/cloud-sdk:slim
  environment: { name: produccion, url: https://api.krediya.example }
  resource_group: produccion # un despliegue a la vez
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual
  id_tokens:
    GCP_TOKEN:
      {
        aud: 'https://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/gitlab/providers/gitlab',
      }
  script:
    - echo "$GCP_TOKEN" > token.jwt
    - gcloud iam workload-identity-pools create-cred-config "$WIF_PROVIDER" --service-account="$DEPLOY_SA" --credential-source-file=token.jwt --output-file=cred.json
    - gcloud auth login --cred-file=cred.json
    - gcloud run deploy api-solicitudes --image "$IMAGE" --region us-east1

Conceptos que conviene dominar

Concepto	Para qué
rules	Decidir si un job se ejecuta (rama, cambios en rutas, variables)
needs	Grafo de dependencias: un job empieza en cuanto terminan los que necesita
cache vs artifacts	Caché: acelerar (dependencias). Artifacts: pasar resultados entre jobs
environment	Historial de despliegues, rollback y entornos protegidos
resource_group	Serializar despliegues al mismo entorno
id_tokens	Tokens OIDC para autenticarse en la nube sin claves estáticas
include / componentes	Reutilizar plantillas desde otros proyectos o el catálogo de componentes CI/CD
Pipelines padre-hijo	Monorepos: un pipeline por componente según lo que cambió

Seguridad

• Sin claves estáticas: OIDC con Workload Identity Federation en GCP o roles en AWS.
• Variables protegidas y enmascaradas, disponibles solo en ramas o etiquetas protegidas.
• Entornos protegidos con aprobadores para producción.
• Runners: separa runners de despliegue (con acceso a producción) de los de pruebas, y evita runners compartidos con privilegios para proyectos sensibles.
• Escaneos integrados (SAST, dependencias, secretos, contenedores) según el plan, o alternativas abiertas como Trivy y Gitleaks en jobs propios.

Medir el pipeline

Los informes de JUnit y cobertura se muestran en el merge request. Analiza la duración por job y la tasa de fallos inestables; un pipeline lento o poco fiable empeora directamente el change lead time de las métricas DORA.

Criterios de implementación

Protege credenciales y runners que acceden a ambientes sensibles. Conserva informes y artefactos según su utilidad. Los escáneres y políticas integrados tienen requisitos de plan y configuración; CI/CD puede integrar herramientas externas cuando convenga.