Skip to content

Tema:

Introduccion a gitlab ci.

Introducción

Gitlab Ci es una herramienta de ci/cd brindada por gitlab que nos permite llevar a cabo en su totalidad el proceso de despliegue de software por medio de pipelines de integracion continua.

Objetivo

Objetivo General:

  • El objetivo de la practica es conocer la solucion de cicd brindada por gitlab y familiarizarnos con sus conceptos.

Desarrollo del tema

1) ¿Qué es GitLab CI/CD?

GitLab CI/CD (Continuous Integration / Continuous Delivery/Deployment) automatiza el ciclo de vida del software: - Build: compilar/empacar la app. - Test: ejecutar pruebas y análisis. - Delivery/Deploy: entregar o desplegar a entornos (dev/stage/prod).

2) El archivo .gitlab-ci.yml

Archivo declarativo en la raíz del repo que define: - stages (fases), jobs (tareas), rules (cuándo correr), - variables, artefactos, cache, environments, etc.

Ejemplo mínimo: 

stages: [build, test, deploy]

build:
  stage: build
  script: echo "Compilando"

test:
  stage: test
  script: echo "Probando"

deploy:
  stage: deploy
  script: echo "Desplegando"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

3) Conceptos clave

3.1 Pipelines

  • Conjunto de jobs ejecutados según .gitlab-ci.yml.
  • Se disparan por push, merge request, tag, schedule, manual, API.

3.2 Stages

  • Fases del pipeline, ejecutadas en orden (p.ej. build → test → deploy).
  • Los jobs dentro de la misma stage corren en paralelo.

3.3 Jobs

  • Unidad de trabajo. Atributos frecuentes:
  • stage, script, image, services, needs, artifacts, cache, rules, when, retry, timeout, tags, environment.
  • Plantillas: con extends: o anclas YAML para reutilizar.

3.4 Runners

  • Agentes que ejecutan jobs.
  • Shared runners (compartidos) o specific runners (dedicados).
  • Ejecutores: docker, shell, kubernetes, vm, etc.
  • Selección por tags: del job.

3.5 Variables

  • Definibles en:
  • .gitlab-ci.yml → variables:
  • Configuración del proyecto/grupo (enmascaradas/protegidas).
  • Variables del sistema (CI_*).
  • Uso: $MI_VAR o ${MI_VAR}. Se pueden inyectar en rules: if, script, etc.

Ejemplo: 

variables:
  DOCKER_IMAGE: "myorg/myapp:${CI_COMMIT_SHORT_SHA}"

3.6 Artefactos y Cache

  • artifacts: archivos que persisten entre jobs (dentro del pipeline).
  • cache: acelera builds reutilizando dependencias entre pipelines. 
    artifacts:
  paths: [dist/, coverage/]
  expire_in: 7 days

cache:
  key: ${CI_PROJECT_NAME}
  paths: [node_modules/]

3.7 Imagen y Servicios (contenerización)

  • image: define la imagen del job.
  • services: levanta contenedores auxiliares (BD, etc.). 
    image: node:20
services:
  - name: postgres:16
    alias: db

3.8 Rules y Workflow

  • rules: controla ejecución a nivel job (reemplaza only/except).
  • Condiciones: if, changes, exists, allow_failure, when.
  • workflow: rules: habilita/omite el pipeline completo.
workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH == "main"'

test:
  stage: test
  script: npm test
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - changes:
        - src/**/*

3.9 DAG con needs

  • Permite dependencias entre jobs sin respetar el orden de stages → pipelines más rápidos. 
    unit:
  stage: test
  script: npm run test

lint:
  stage: test
  script: npm run lint

package:
  stage: build
  script: npm run build
  needs: [unit, lint]

3.10 Environments y Deployments

  • environment: registra despliegues (dev/stage/prod), URL y controles.
  • when: manual para despliegues aprobados; when: delayed para diferidos.
deploy_prod:
  stage: deploy
  script: ./scripts/deploy.sh
  environment:
    name: production
    url: https://app.example.com
    on_stop: stop_prod
  when: manual

3.11 Reportes (test, cobertura, seguridad)

  • Publicación de reportes para la UI de GitLab: 
    test:
  stage: test
  script: npm run test:junit
  artifacts:
    reports:
      junit: reports/junit.xml

3.12 Reutilización e includes

  • Reutilizá fragmentos con include: (archivo local, proyecto remoto, URL). 
    include:
  - local: .gitlab/ci/base.yml
  - project: infra/pipelines
    file: templates/docker.yml

3.13 Child/Parent y Multi-proyecto

  • Child pipelines (estáticos o dinámicos) para dividir responsabilidades.
  • Multi-project pipelines con trigger: para orquestar repos.
generate-child:
  stage: build
  trigger:
    include: child.yml
    strategy: depend

3.14 Schedules, Tags y MR pipelines

  • Schedules: pipelines programados (cron) con variables propias.
  • Tags: pipelines sólo para tags (releases).
  • Merge Request pipelines: validan cambios antes de fusionar.

4) Patrón de pipeline recomendado (web app genérica)

stages: [verify, build, test, package, deploy]

.default:
  image: alpine:3.20

lint:
  stage: verify
  image: node:20
  script: [ "npm ci", "npm run lint" ]
  rules:
    - changes: [ "src/**/*", "package*.json" ]

unit:
  stage: test
  image: node:20
  script: [ "npm ci", "npm test -- --ci --reporters=jest-junit" ]
  artifacts:
    when: always
    reports:
      junit: reports/junit.xml
  needs: [lint]

build_image:
  stage: package
  image: docker:27
  services: [ "docker:27-dind" ]
  variables:
    DOCKER_HOST: tcp://docker:2375/
    DOCKER_TLS_CERTDIR: ""
    IMAGE: "registry.example.com/app:${CI_COMMIT_SHORT_SHA}"
  script:
    - docker build -t "$IMAGE" .
    - docker push "$IMAGE"
  rules:
    - if: '$CI_COMMIT_BRANCH'
  needs: [unit]

deploy_staging:
  stage: deploy
  script: ./scripts/deploy.sh staging "$IMAGE"
  environment:
    name: staging
    url: https://staging.example.com
    auto_stop_in: 3 days
  when: manual
  needs: [build_image]

deploy_prod:
  stage: deploy
  script: ./scripts/deploy.sh production "$IMAGE"
  environment:
    name: production
    url: https://app.example.com
  when: manual
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
  needs: [build_image]

5) Glosario rápido

  • Pipeline: ejecución completa del CI.
  • Stage: fase secuencial del pipeline.
  • Job: tarea concreta ejecutada por un runner.
  • Runner: agente que ejecuta jobs.
  • Artifacts/Cache: persistencia de archivos y dependencias.
  • Rules/Workflow: condiciones de ejecución (job/pipeline).
  • Needs (DAG): dependencias entre jobs para paralelizar.
  • Environment: registro y control de despliegues.
  • Include/Extends: reutilización y plantillas.
  • Child/Parent/Trigger: orquestación entre pipelines.

6) Buenas prácticas

  • Mantener .gitlab-ci.yml pequeño y reutilizable (usa include/extends).
  • Preferir rules + workflow en lugar de only/except.
  • Usar needs para reducir tiempos (DAG).
  • Publicar reportes (junit/coverage) y artefactos clave.
  • Proteger variables sensibles y entornos de producción.
  • Nombrar stages y jobs de forma semántica y consistente.