1. Introducción: Production AI Pipeline

Descripción

Los módulos 1-7 te dieron las piezas individuales: workflows básicos, testing automatizado, AI checks, secrets management, Docker build, deployment pipelines, notifications, y advanced patterns. Cada módulo produjo un mini-proyecto funcional. Pero en producción, estas piezas no existen aisladas — necesitan funcionar juntas, en orden, con manejo de errores entre stages, y con la capacidad de recuperarse de failures sin intervención manual.

El Módulo 8 es la culminación. Aquí integras todo en un pipeline production-grade que lleva tu aplicación AI desde un commit hasta producción de forma completamente automatizada. No es "pegar los workflows anteriores en un solo archivo." Es diseñar un sistema cohesivo donde cada stage sabe qué hacer si el stage anterior falló, donde los datos fluyen entre jobs a través de outputs y artifacts, y donde un failure post-deploy triggerea rollback automático sin que nadie tenga que intervenir.

La integración es un skill en sí mismo. Saber buildear Docker, saber correr tests, y saber deployear son habilidades individuales. Conectarlos en un pipeline donde Docker build depende de que los tests pasen, donde el deploy usa la imagen que Docker buildeó, y donde un failure en el smoke test post-deploy triggerea un rollback que usa la imagen anterior — eso es integration engineering. Y es exactamente lo que construirás aquí.

Contexto: ¿Dónde estamos en la guía?

Has completado 7 módulos. Tienes todas las piezas:

• ✅ Módulo 1: Workflows, jobs, steps, YAML, triggers
• ✅ Módulo 2: pytest, matrix testing, caching, test reports
• ✅ Módulo 3: Prompt regression, cost estimation, quality gates
• ✅ Módulo 4: GitHub Secrets, environments, OIDC
• ✅ Módulo 5: Docker build, push, layer caching, GHCR
• ✅ Módulo 6: Staging, production, approval gates, rollback strategies
• ✅ Módulo 7: Notifications, scheduled workflows, reusable patterns

Este es el módulo final. Lo que construyes aquí es portfolio-worthy.

Por qué un módulo de integración

En la industria, la mayoría de pipelines CI/CD no fallan por falta de conocimiento técnico. Fallan por problemas de integración:

• Un job produce un output, pero el siguiente job lo consume con el nombre equivocado
• El rollback funciona en staging pero falla en production porque el environment tiene diferentes variables
• Las notifications llegan para CI failures, pero no para deploy failures porque el job de notify no tiene if: always()
• El cost monitoring corre, pero el artifact de comparación no se encuentra porque la retención expiró

Estos bugs no aparecen cuando testeas cada pieza por separado. Solo aparecen cuando todo corre junto. Por eso, este módulo existe: para forzarte a encontrar y resolver los bugs de integración antes de que lleguen a producción.

El valor de un AI engineer no es solo saber configurar un workflow. Es saber diseñar un sistema de workflows que funcionen como un todo coherente, resiliente, y observable.

Objetivo del módulo

Al completar este módulo serás capaz de:

• ✅ Diseñar la arquitectura de un pipeline production-grade: stages, dependencies, data flow entre jobs
• ✅ Implementar el pipeline completo: lint → test → AI checks → Docker build → push → deploy staging → smoke tests → approve → deploy production
• ✅ Configurar rollback automático: si el deploy falla o los smoke tests fallan, redeployear la versión anterior
• ✅ Implementar cost monitoring: track del costo estimado por deployment, alertas si el costo sube
• ✅ Crear pipeline documentation: README del pipeline, runbook de troubleshooting, diagrama de flujo
• ✅ Implementar post-deployment validation: health check + prompt test después del deploy
• ✅ Ejecutar el pipeline end-to-end al menos una vez exitosamente y una vez con failure + rollback

Prerequisitos

Conocimiento requerido

• ✅ Módulos 1-7 completados: Tienes todas las piezas individuales
• ✅ Pipeline del Módulo 7 funcionando: Tienes CI con notifications, health checks, y reusable patterns
• ✅ Docker workflow del Módulo 5: Sabes buildear y pushear images
• ✅ Deployment del Módulo 6: Entiendes staging, production, approval gates

Herramientas necesarias

• ✅ GitHub repo con Actions habilitado
• ✅ Secrets configurados: OPENAI_API_KEY, SLACK_WEBHOOK_URL
• ✅ GHCR (GitHub Container Registry) accesible
• ✅ GitHub Environments configurados: staging, production

# Verifica Docker
docker --version

# Verifica que puedes hacer push a GHCR
echo $GITHUB_TOKEN | docker login ghcr.io -u tu-usuario --password-stdin

# Verifica secretos (en GitHub UI)
# Settings → Secrets → OPENAI_API_KEY ✅
# Settings → Secrets → SLACK_WEBHOOK_URL ✅

# Verifica environments (en GitHub UI)
# Settings → Environments → staging ✅
# Settings → Environments → production (con required reviewers) ✅

Contenido del módulo

Estas son las 8 cápsulas que componen este módulo:

Cápsula 02: Pipeline Architecture

Cómo conectar stages, pasar datos entre jobs (outputs, artifacts), manejar dependencies. El diagrama completo del pipeline y las decisiones de arquitectura.

Skill principal: Diseñar el data flow entre jobs — saber cuándo usar outputs (string corto, inmediato) vs artifacts (archivo, retención).

Cápsula 03: Full Pipeline Implementation

El pipeline completo en un solo YAML: lint → test → AI checks → Docker build → push → deploy staging → smoke tests → approve → deploy production. La implementación real, no un bosquejo.

Skill principal: Escribir y debugear un YAML de ~200 líneas con múltiples jobs interdependientes.

Cápsula 04: Rollback Automático

Si el deploy falla o los smoke tests post-deploy fallan, el pipeline automáticamente redeploya la versión anterior. Edge cases: primer deploy (no hay versión anterior), rollback que también falla.

Skill principal: Implementar continue-on-error + condicionales para crear un flujo de recovery dentro de un job.

Cápsula 05: Cost Monitoring en Pipeline

Track del costo estimado de prompts por deployment, comparación con el deployment anterior, alerta si el costo aumenta más de un threshold. Artifact con historial de costos.

Skill principal: Integrar scripts de análisis (Python) en el pipeline y usar artifacts para crear un historial de datos.

Cápsula 06: Pipeline Documentation

README del pipeline, runbook para troubleshooting, diagrama de flujo ASCII. La documentación es tan importante como el código — sin ella, el pipeline se convierte en una caja negra.

Skill principal: Crear documentación operacional que reduce el bus factor y acelera el troubleshooting.

Cápsula 07: Post-Deployment Validation

Smoke tests en producción: health check + prompt test básico. Qué hacer si la validación falla (trigger rollback automático). La diferencia entre "el deploy se completó" y "la aplicación funciona correctamente."

Skill principal: Diseñar validaciones de AI systems que balancean confiabilidad (retries, timeouts) con velocidad de feedback.

Cápsula 08: Proyecto Final — Production AI Pipeline

EL entregable. Pipeline completo commit-to-production que funciona end-to-end. Debe ejecutarse al menos una vez exitosamente (happy path) y una vez con failure + rollback (error path). Portfolio-worthy.

Skill principal: Integrar todos los componentes, testear end-to-end en ambos paths (success y failure), y documentar el resultado.

El pipeline completo: Vista general

Commit
  │
  ├─► CI Stage
  │   ├── Lint (ruff)
  │   ├── Test (pytest, matrix)
  │   └── AI Checks (prompt regression, cost estimation)
  │
  ├─► Build Stage
  │   ├── Docker build (layer caching)
  │   ├── Image tagging (SHA + latest)
  │   ├── Security scan (trivy)
  │   └── Push to GHCR
  │
  ├─► Deploy Staging
  │   ├── Pull image
  │   ├── Deploy to staging environment
  │   └── Smoke tests (health + prompt)
  │
  ├─► Approval Gate
  │   └── Manual approval from reviewer
  │
  ├─► Deploy Production
  │   ├── Save current production tag (for rollback)
  │   ├── Pull new image
  │   ├── Deploy to production environment
  │   └── Post-deploy validation
  │
  ├─► Rollback (if validation fails)
  │   ├── Redeploy previous tag
  │   └── Notify: rollback executed
  │
  └─► Notifications
      ├── Failure at any stage → Slack alert
      ├── Deploy to production success → Slack confirmation
      └── Rollback executed → Slack alert

Cada módulo anterior contribuyó una pieza:

Qué es diferente en este módulo

Los módulos anteriores te enseñaron features aisladas. Este módulo te enseña tres skills de integración:

1. Data flow entre jobs

jobs:
  build:
    outputs:
      image-tag: ${{ steps.meta.outputs.tag }}
    steps:
      - id: meta
        run: echo "tag=ghcr.io/org/app:abc123" >> $GITHUB_OUTPUT

  deploy:
    needs: build
    steps:
      - run: docker pull ${{ needs.build.outputs.image-tag }}

El Docker image tag viaja del job de build al job de deploy a través de outputs. Sin esto, no hay forma de que deploy sepa qué imagen usar.

2. Error recovery

  deploy:
    steps:
      - name: Save current tag for rollback
        run: echo "current_tag=abc123" >> $GITHUB_OUTPUT

      - name: Deploy new version
        run: ./deploy.sh ${{ needs.build.outputs.image-tag }}

  rollback:
    needs: deploy
    if: failure()
    steps:
      - name: Redeploy previous version
        run: ./deploy.sh ${{ needs.deploy.outputs.current-tag }}

Si deploy falla, el job de rollback se activa y redeploya la versión anterior.

3. Notification orchestration

No una notificación genérica de "CI falló," sino notificaciones específicas por stage:

• ✅ "AI checks fallaron — posible regression en prompt"
• ✅ "Docker build falló — revisa Dockerfile"
• ✅ "Deploy a production exitoso — versión abc123 live"
• ✅ "Rollback ejecutado — versión anterior restored"

El approach: Incremental, no big bang

No vas a escribir el pipeline de 300 líneas de una sola vez. El approach es incremental:

1. Cápsula 02: Entiende la arquitectura y el data flow
2. Cápsula 03: Implementa el pipeline completo (el YAML grande)
3. Cápsula 04: Agrega rollback automático
4. Cápsula 05: Agrega cost monitoring
5. Cápsula 06: Documenta todo
6. Cápsula 07: Agrega post-deployment validation
7. Cápsula 08: Integra, testea end-to-end, valida

Cada cápsula agrega una layer al pipeline. Al final de la cápsula 03 ya tienes un pipeline funcional. Las cápsulas 04-07 lo hacen production-grade. La cápsula 08 es la validación final.

Analogía: orquesta sinfónica

Piensa en los módulos anteriores como músicos individuales practicando su instrumento:

• Módulo 1-2: El violinista practica escalas (lint, test)
• Módulo 3: El percusionista aprende ritmos complejos (AI checks)
• Módulo 4: El técnico de sonido prepara el equipo (secrets, security)
• Módulo 5: El escenógrafo monta el escenario (Docker, containers)
• Módulo 6: Cada sección ensaya junta (deploy, rollback básico)
• Módulo 7: El director de orquesta establece señales (notifications, scheduling, patterns)

Módulo 8 es el concierto. Todos tocan juntos, siguiendo la misma partitura. El director coordina entradas, salidas, y recuperaciones. Si un músico se equivoca (deploy falla), el director tiene un plan: volver al último compás estable (rollback).

La diferencia entre un ensayo individual y un concierto es la misma diferencia entre un job aislado y un pipeline integrado. La coordinación es un skill que solo aprendes haciendo.

Setup técnico recomendado

Antes de empezar, asegúrate de tener:

Herramientas

# Verifica que tienes todo instalado:
python --version    # Python 3.10+
docker --version    # Docker 20+
gh --version        # GitHub CLI 2.0+
git --version       # Git 2.30+

Si alguna herramienta falta, instálala antes de continuar. El módulo asume que todo está listo.

Tiempo estimado

Repo preparado

Tu repo debería tener (del Módulo 7):

.github/
├── actions/
│   └── setup-ai-project/
│       └── action.yml          # Composite action
├── workflows/
│   ├── reusable-ai-ci.yml     # Reusable workflow
│   └── ci.yml                 # Pipeline principal
scripts/
├── pipeline_metrics.py         # Health metrics
├── prompt_regression.py        # Prompt checks
└── cost_estimation.py          # Cost estimation (lo crearás aquí)
tests/
├── test_main.py
└── conftest.py
src/
├── main.py
└── prompts.json
Dockerfile
requirements.txt

Secrets configurados

En tu repo → Settings → Secrets and variables → Actions:

• OPENAI_API_KEY — para AI checks
• SLACK_WEBHOOK_URL — para notifications
• DEPLOY_SSH_KEY — para deploy (simulated OK)

Environments configurados

En tu repo → Settings → Environments:

• staging — sin protección
• production — con required reviewers

Si no tienes los environments configurados, las cápsulas 03-07 te guían en crearlos.

Qué NO cubre este módulo

• ❌ Cloud infrastructure real: El deploy simula production con Docker Compose. Cloud real (AWS, GCP) es la guía #17.
• ❌ Runtime monitoring: Monitorear la app en producción es la guía #18. Este módulo monitorea el pipeline, no la app.
• ❌ Multi-cloud deployment: Solo deployas a un target. Multi-region es un tema de infrastructure avanzado.
• ❌ Kubernetes: El deploy es Docker Compose. K8s deployments son tema de la guía de Cloud.
• ❌ Database migrations: El pipeline no incluye migrations. Es un tema de application architecture.

Evidencia de éxito

Al terminar este módulo, deberías poder:

• Explicar cómo fluyen los datos entre jobs (outputs y artifacts)
• Tener un pipeline YAML completo que corre lint → test → AI checks → Docker → deploy
• Ejecutar el pipeline exitosamente end-to-end (happy path)
• Provocar un failure y ver el rollback automático en acción
• Tener un README del pipeline con diagrama de flujo y troubleshooting
• Tener un artifact con el cost report del deployment
• Recibir notificaciones en Slack para deploy success y rollback

Si marcas todos los checks → completaste la guía.

Después de este módulo

Al terminar, tienes un pipeline CI/CD production-grade para AI systems. Los siguientes pasos en el AI Engineering Path:

• ✅ Guía #17 (Deployment & Cloud Infrastructure): Lleva tu pipeline a AWS/GCP con infrastructure as code
• ✅ Guía #18 (Monitoring & Observability): Monitorea tu aplicación AI en producción — latency, cost, quality, errors

Tu pipeline de esta guía se integra directamente con ambas: #17 reemplaza el deploy simulado con deploy real a la nube, y #18 agrega monitoring de la app (no solo del pipeline).

Recursos adicionales

1. GitHub Actions — Workflow Syntax - Referencia completa de YAML
2. GitHub Actions — Job Outputs - Cómo pasar datos entre jobs
3. GitHub Environments - Configuración de environments
4. Docker Compose Deploy - Docker Compose en producción
5. GitHub Actions — Deployment Strategies - Estrategias de deployment
6. DORA Metrics - Las métricas estándar de la industria para DevOps performance