La propuesta integrada de GitLab

GitLab adoptó CI/CD desde muy temprano y lo integró directamente en el núcleo de la plataforma. No es un servicio aparte ni una aplicación marketplace: basta con crear un archivo .gitlab-ci.yml en la raíz del repositorio para que GitLab detecte el pipeline y empiece a ejecutarlo. Esa integración profunda es su mayor atractivo frente a alternativas externas.

Conceptos básicos: stages y jobs

Un pipeline de GitLab se organiza en stages (etapas) que se ejecutan en orden, y cada stage contiene uno o varios jobs que corren en paralelo. Si algún job falla, los siguientes stages no se ejecutan. La lógica es simple pero potente: agrupa el trabajo por fase y deja que GitLab decida qué puede paralelizarse.

Ejemplo para una app PHP con frontend Node

stages:
  - lint
  - test
  - build
  - deploy

lint_php:
  stage: lint
  image: php:8.2
  script:
    - composer install
    - vendor/bin/phpcs src/

test_php:
  stage: test
  image: php:8.2
  script:
    - composer install
    - vendor/bin/phpunit

build_frontend:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - public/build/
    expire_in: 1 week

deploy_staging:
  stage: deploy
  script:
    - rsync -avz public/ user@staging:/var/www/
  only:
    - main

Runners: dónde se ejecuta el pipeline

Un runner es el proceso que realmente corre los jobs. GitLab te ofrece dos opciones:

• Shared runners: infraestructura gestionada por GitLab. Ideal para empezar, sin configurar nada. Tienen cuota de minutos mensuales según el plan.
• Self-hosted runners: máquinas propias que registras contra tu instancia. Te dan control total del entorno, acceso a red interna y minutos ilimitados, a cambio de mantenerlos tú.

Muchos equipos combinan ambos: shared para tests rápidos, self-hosted para deploys a infraestructura privada o builds pesados.

Variables: configuración sin hardcodear

Las variables se definen a tres niveles: en el propio YAML, en los settings del proyecto o en los de grupo. Las que guardan credenciales deben marcarse como protected y masked para que solo funcionen en ramas protegidas y no aparezcan en los logs.

deploy_prod:
  stage: deploy
  script:
    - echo "Desplegando versión $CI_COMMIT_SHA"
    - curl -X POST $WEBHOOK_URL -H "Authorization: $DEPLOY_TOKEN"
  only:
    - tags

Las variables que empiezan por CI_ las inyecta GitLab automáticamente: hash del commit, nombre de rama, URL del proyecto, ID del pipeline. Todas documentadas y listas para usar.

Artifacts y cache: la diferencia que importa

Estos dos conceptos se confunden seguido, pero cumplen roles distintos:

• Artifacts: archivos generados por un job que quieres conservar. Se suben al servidor y quedan disponibles para descargar o para jobs posteriores. Úsalos para builds compilados, reportes de tests o coverage.
• Cache: archivos que quieres reutilizar entre ejecuciones para acelerar el pipeline, como vendor/ o node_modules/. No se garantizan: si el cache se pierde, el job simplemente lo reconstruye.

Ventajas que notarás rápido

La vista de pipelines de GitLab muestra gráficamente cada stage, los logs en tiempo real y el estado de cada job. Puedes reintentar un job individual sin relanzar todo el pipeline, cancelar ejecuciones, descargar artifacts con un clic y comparar tiempos entre pipelines. Para equipos que ya viven en GitLab, no hay fricción: el mismo lugar donde revisas el código es donde orquestas la entrega.