Modulo 01. Conceptos base de CI y CD

Objetivo del modulo

Entender por que CI/CD no es solo "automatizar pasos", sino construir una cadena fiable desde el codigo hasta la entrega que aporte calidad, velocidad y trazabilidad.

Resultados esperados

• Distinguir integracion continua de entrega continua y despliegue continuo.
• Explicar el papel de artefactos, tests y quality gates.
• Relacionar pipeline con calidad, velocidad y trazabilidad.
• Identificar los componentes de una pipeline bien disenada.

Desarrollo teorico

La integracion continua (CI) busca que el codigo se integre frecuentemente en una rama compartida y se valide rapido mediante builds y pruebas automatizadas. La idea fundamental es que los conflictos se detecten pronto, cuando son pequenos y faciles de resolver, en lugar de descubrirlos semanas despues en una integracion masiva. El principio basico es: cada commit en la rama principal (o cada merge request) dispara un build automatico que compila, ejecuta tests y produce un artefacto verificable.

La entrega continua (Continuous Delivery) anade la capacidad de tener un artefacto siempre listo para ser liberado de forma controlada. No significa que cada commit llega automaticamente a produccion, sino que en cualquier momento se podria liberar porque el artefacto ha pasado todas las validaciones necesarias. La decision de liberar sigue siendo humana, pero el proceso tecnico esta listo.

El despliegue continuo (Continuous Deployment) va un paso mas alla: promueve automaticamente a produccion cuando se cumplen todas las condiciones definidas en el pipeline. No hay intervencion humana entre el commit y produccion si el pipeline aprueba. En la practica, muy pocas organizaciones aplican despliegue continuo puro, pero muchas aspiran a acercarse.

El pipeline como cadena de valor. El pipeline es la secuencia automatizada que transforma commits en artefactos verificables y desplegables. Si esta bien disenado, reduce incertidumbre: sabes que codigo se ha probado, con que dependencias, que checks ha superado y que version exacta se despliega. Si esta mal disenado, automatiza errores y los acelera. Un pipeline roto que deja pasar codigo con tests fallidos es peor que no tener pipeline.

Un pipeline tipico en GitHub Actions se veria asi:

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/

Este ejemplo ilustra las fases basicas: checkout del codigo, instalacion de dependencias, validacion de estilo (lint), ejecucion de tests, build del artefacto y publicacion del artefacto para su uso posterior.

En GitLab CI la estructura es similar pero con sintaxis propia:

stages:
  - validate
  - test
  - build
  - package

lint:
  stage: validate
  script:
    - npm ci
    - npm run lint

test:
  stage: test
  script:
    - npm ci
    - npm test

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/

Artefactos. El artefacto es la pieza central del pipeline. Puede ser un paquete npm, una imagen Docker, un binario compilado, un JAR, un chart de Helm o un bundle de frontend. Lo critico es que sea identificable (con version o SHA), trazable (vinculado al commit que lo genero) y que sea el mismo que avanzo por todas las etapas. Reconstruir el artefacto entre test y deploy es un anti-patron peligroso: podriais estar desplegando algo diferente de lo que se probo.

Quality gates. Un quality gate es un punto de decision automatizado que bloquea el avance del pipeline si no se cumplen criterios minimos. Ejemplos: cobertura de tests por debajo de un umbral, vulnerabilidades criticas detectadas por SAST/DAST, lint con errores, tests fallidos. Los gates convierten el pipeline en una puerta de calidad objetiva y no en un simple encadenamiento de scripts.

Trazabilidad. Cada ejecucion del pipeline debe permitir responder: que commit se construyo, que tests paso, que version del artefacto se genero, quien aprobo la liberacion y en que momento se desplego. Sin esta trazabilidad, cuando algo falla en produccion es imposible hacer un rollback informado.

CI/CD no es solo para desarrollo. Equipos de infraestructura usan pipelines para validar cambios de Terraform (terraform plan como step del pipeline), equipos de datos para validar transformaciones y equipos de plataforma para validar configuraciones de Kubernetes. El principio es el mismo: cambios frecuentes, validacion automatica, artefactos trazables.

Contenido ampliado

Puntos clave

• Automatizar no basta; hay que automatizar con criterio y quality gates.
• El artefacto probado y el desplegado deben ser exactamente el mismo.
• La cadena de entrega afecta directamente a calidad, velocidad y riesgo.
• CI detecta problemas pronto; CD los hace liberables con control.
• La trazabilidad es lo que permite hacer rollback informado.
• Pipelines aplican tanto a codigo de aplicacion como a infraestructura.

Checklist operativa

• Aclarar que parte del proceso es CI y cual es CD.
• Definir cuando un cambio se considera liberable (quality gates).
• Versionar artefactos de forma explicita y vincularlos al commit.
• Configurar notificaciones para pipelines rotos.
• Revisar que el artefacto no se reconstruye entre etapas.
• Asegurar que los tests son relevantes y no solo decorativos.

Errores frecuentes

• Llamar CI/CD a cualquier script sin control ni quality gates.
• Reconstruir artefactos diferentes entre test y deploy.
• No distinguir entre "deployable" y "auto desplegado".
• Tener tests que siempre pasan sin cubrir casos reales.
• No versionar artefactos ni vincularlos al commit de origen.
• Ignorar pipelines rotos como algo normal.

Practica sugerida

Describe el flujo ideal desde un commit hasta un artefacto listo para produccion. Incluye: trigger del pipeline, steps de validacion, build, test, quality gates, generacion del artefacto y publicacion. Implementa un workflow basico en GitHub Actions o GitLab CI para un proyecto Node.js que ejecute lint, tests y build.

Preguntas de autoevaluacion

• Que diferencia hay entre entrega continua y despliegue continuo.
• Por que el artefacto es una pieza central del pipeline.
• Que valor real aporta CI a un equipo de desarrollo o de plataforma.
• Que pasa si se reconstruye el artefacto entre la etapa de test y la de deploy.
• Como ayudan los quality gates a mantener la calidad del software.

Cierre

CI/CD tiene sentido cuando convierte cambios en software desplegable con menos incertidumbre y mas control, no cuando solo encadena comandos sin criterio de calidad.

Modulo 02. Diseno de stages y artefactos

Objetivo del modulo

Organizar un pipeline en etapas con proposito claro y artefactos trazables entre ellas, para maximizar control, paralelismo y confianza en la entrega.

Resultados esperados

• Disenar stages coherentes para build, package, test y deploy.
• Entender que artefacto debe circular por el pipeline.
• Evitar diferencias entre lo probado y lo desplegado.
• Aplicar criterios de separacion y nombrado de stages.

Desarrollo teorico

Los stages no deberian existir por tradicion sino por control. Un stage responde a una pregunta: compila, pasa pruebas, se puede empaquetar, cumple politicas de seguridad, puede desplegarse. La separacion ayuda a aislar fallos, paralelizar validaciones y dejar rastro de cada decision.

Anatomia de stages bien disenados. Un pipeline maduro suele contener al menos estas etapas:

1. Checkout y preparacion: Clonar el repositorio, instalar dependencias. Es el punto de partida reproducible.
2. Lint y validacion estatica: Verificar estilo de codigo, reglas de linting, formateo. Estos checks son rapidos y detectan errores triviales.
3. Build/Compile: Compilar o transpilar el codigo fuente en un artefacto ejecutable.
4. Test unitario: Ejecutar tests que validan componentes individuales sin dependencias externas.
5. Test de integracion: Validar interacciones entre componentes, con base de datos, APIs externas o servicios auxiliares.
6. Security scan: Analisis estatico de seguridad (SAST), escaneo de dependencias (SCA), deteccion de secretos.
7. Package: Generar el artefacto versionado y publicarlo en un registro (imagen Docker, paquete npm, binario).
8. Deploy a staging: Desplegar en un entorno pre-produccion para validacion adicional.
9. Smoke tests / E2E: Verificar que el despliegue funciona en un entorno real.
10. Deploy a produccion: Promocion final con posibilidad de rollback.

No todos los proyectos necesitan las diez etapas. Un microservicio simple puede fusionar build y package. Una libreria puede omitir deploy. Lo importante es que cada stage tenga un proposito claro y un criterio de paso/fallo definido.

Ejemplo en GitHub Actions:

name: Full Pipeline
on:
  push:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test -- --coverage
      - uses: actions/upload-artifact@v4
        with:
          name: coverage-report
          path: coverage/

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy-staging:
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
      - run: ./scripts/deploy.sh staging

Ejemplo en GitLab CI:

stages:
  - validate
  - test
  - build
  - deploy

lint:
  stage: validate
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  script:
    - npm ci
    - npm test -- --coverage
  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
  artifacts:
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml

build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

deploy-staging:
  stage: deploy
  script:
    - ./scripts/deploy.sh staging
  environment:
    name: staging
  only:
    - main

El artefacto como pieza central. El artefacto es la unidad trazable que avanza por el pipeline. Puede ser un paquete, una imagen de contenedor, un binario o un chart de Helm. Lo critico es que sea identificable (version, SHA del commit, timestamp), que se construya una sola vez y que avance sin reconstruirse. Cuando pruebas una build y luego despliegas otra generada despues con dependencias distintas, pierdes coherencia y aumentas riesgo.

El anti-patron mas peligroso es reconstruir el artefacto en cada stage o en cada entorno. En CI haces npm run build con dependencias de la semana pasada. En staging alguien actualizo una dependencia y el npm ci instala algo diferente. En produccion el build incluye un fix de ultima hora que nunca paso tests. El resultado: lo que se desplego no es lo que se probo.

Versionado del artefacto. Cada artefacto debe tener una version explicita. Opciones comunes:

• Semantic versioning: v1.2.3.
• SHA del commit: a1b2c3d.
• Combinacion: v1.2.3-a1b2c3d.
• Timestamp: 20260326-143022.

El versionado permite rollback informado: si la version v1.2.3 falla en produccion, puedes volver a v1.2.2 sabiendo exactamente que codigo contiene cada una.

Paralelismo y dependencias. Los stages que no dependen entre si pueden ejecutarse en paralelo. Lint y tests unitarios pueden correr simultaneamente. Security scan puede correr en paralelo con tests de integracion. El paralelismo reduce el tiempo total del pipeline sin comprometer la validacion. La clave es modelar correctamente las dependencias: needs en GitHub Actions, stage ordering en GitLab CI.

Contenido ampliado

Puntos clave

• Cada stage debe tener proposito comprensible y criterio de paso/fallo.
• El artefacto debe construirse una vez y avanzar sin reconstruirse.
• La trazabilidad de version habilita rollback y auditoria.
• El paralelismo reduce tiempo total sin sacrificar validacion.
• Los stages independientes deben ejecutarse en paralelo.
• Reconstruir el artefacto entre entornos es un anti-patron critico.

Checklist operativa

• Definir artefacto unico por ejecucion con version explicita.
• Revisar que stages pueden ir en paralelo.
• Asegurar versionado consistente entre etapas y entornos.
• Verificar que el artefacto desplegado es el mismo que paso tests.
• Documentar criterio de paso/fallo de cada stage.
• Configurar limpieza automatica de artefactos antiguos.

Errores frecuentes

• Mezclar build y deploy sin frontera clara de responsabilidad.
• Reconstruir artefactos en cada entorno con dependencias potencialmente distintas.
• No conservar metadatos de version, commit o timestamp en el artefacto.
• Disenar stages secuenciales cuando podrian ejecutarse en paralelo.
• No definir criterio de fallo claro para cada stage.
• Almacenar artefactos indefinidamente sin politica de retencion.

Practica sugerida

Dibuja un pipeline para una API Node.js con las siguientes etapas: lint, unit test, build, security scan, package (imagen Docker), deploy a staging, smoke tests y deploy a produccion. Implementa las tres primeras etapas en GitHub Actions o GitLab CI. Define el artefacto, su versionado y que stages pueden ejecutarse en paralelo.

Preguntas de autoevaluacion

• Que diferencia operativa hay entre build y package.
• Por que importa desplegar el mismo artefacto que se probo.
• Que informacion minima debe acompañar a un artefacto para ser trazable.
• Que stages podrian ejecutarse en paralelo en un pipeline tipico.
• Que consecuencias tiene reconstruir el artefacto en cada entorno.

Cierre

Cuando los stages estan bien definidos y el artefacto es trazable, el pipeline deja de ser una caja negra y pasa a ser una pieza confiable de entrega que aporta confianza a cada liberacion.