Módulo 6: Proyecto — Pipeline CI/CD Completo con Claude Code
Módulo 6: Proyecto Integrador — Pipeline CI/CD Completo
Módulo 6: Proyecto Integrador — Pipeline CI/CD Completo
Descripción
Este es el módulo culminante de la guía. Los Módulos 1-5 te dieron cada pieza por separado: GitHub Actions como plataforma, code review automático en PRs, SDK headless para portabilidad cross-platform, deployment automation, y resiliencia con security scanning + rollback. Ahora conectas todas las piezas en un pipeline end-to-end que demuestra el potencial completo de Claude Code como agente de CI/CD.
El pipeline completo opera así: PR abierto → code review automático → tests y linting → security scan → merge a main → changelog generado → deployment readiness check → staging deploy → staging validation → production deploy con approval gate → monitoring → rollback automático con diagnóstico si algo falla. Cada step usa lo aprendido en módulos anteriores.
Este no es un ejercicio académico — es un sistema real adaptable a tu proyecto. El entregable es portfolio-worthy: un pipeline funcional, documentado, con failure paths cubiertos, y con análisis de costos. Es lo que demuestra que dominas Claude Code en CI/CD a nivel profesional.
Al completar las 6 cápsulas, vas a tener un pipeline completo funcionando, documentado para tu equipo, optimizado para costos, y con plan de respuesta cuando las cosas salen mal. Ese pipeline es transferible a cualquier proyecto profesional que toques.
Dónde Estamos en la Guía
Phase 1: Pre-Merge Automation (Módulos 1-2)
├── Módulo 1: Claude Code en GitHub Actions ✅
└── Módulo 2: Code Review Automático en PRs ✅
Phase 2: Cross-Platform y Deployment (Módulos 3-4)
├── Módulo 3: GitLab CI/CD y SDK Headless ✅
└── Módulo 4: Deployment Automation ✅
Phase 3: Resiliencia y Proyecto (Módulos 5-6)
├── Módulo 5: Security Scanning y Rollback ✅
└── Módulo 6: Proyecto Integrador ← ESTÁS AQUÍ
→ Pipeline end-to-end, documentación, retrospectiva
Este es el último módulo de la guía. No hay módulo siguiente — la siguiente referencia es la Guía 11 (Security for AI-Generated Code), que cierra el path Agentic Development con foco en seguridad de código generado por AI.
El Cambio de Foco: De Steps a Sistema
Hasta ahora cada módulo trató un step del pipeline. Este módulo cambia el foco al sistema:
MÓDULOS 1-5 (steps individuales):
→ Cómo configurar code review
→ Cómo configurar deployment
→ Cómo configurar rollback
→ Cada uno aislado, con condiciones controladas
MÓDULO 6 (sistema completo):
→ Cómo encajan todos los steps juntos
→ Qué pasa cuando uno falla y cómo se propaga
→ Cómo el sistema entero se documenta y opera
→ Cómo balancear costos en un pipeline de 5+ steps
→ Sin condiciones controladas: la realidad
Es la diferencia entre practicar tiros libres y jugar un partido completo. Los módulos previos son tiros libres. Este es el partido. La integración revela problemas que no aparecen en steps aislados: dependencias entre steps, tiempos de ejecución acumulados, costos sumados, y los puntos donde un fallo en un step debe propagarse o no propagarse.
Lo que hace este proyecto portfolio-worthy
Lo que produces NO ES:
❌ Un workflow YAML que funciona en happy path
❌ Una serie de scripts sin documentación
Lo que produces SÍ ES:
✅ Pipeline completo con happy path Y failure paths
✅ Documentación que un colega del equipo puede usar para
operar el pipeline sin tu ayuda
✅ Retrospectiva con métricas: tiempo por run, costo por run,
comparación vs proceso manual
✅ Plan de optimización: qué cachear, qué ejecutar selectivamente,
dónde están los cuellos de botella
Un empleador, un cliente, o un equipo nuevo pueden leer este entregable y verificar que diseñas y operas pipelines de CI/CD a nivel senior — no que "sabes usar GitHub Actions".
El Pipeline Completo: Vista General
┌─────────────────────────┐
│ Developer abre PR │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ Workflow se dispara │ ← Módulo 1
│ (pull_request.opened) │
└────────────┬────────────┘
│
┌────────────────┴────────────────┐
▼ ▼
┌───────────────────┐ ┌──────────────────┐
│ Code Review │ │ Security Scan │
│ inline en PR │ ← Módulo 2 │ pre-merge │ ← Módulo 5
└─────────┬─────────┘ └────────┬─────────┘
│ │
└──────────────┬─────────────────┘
│
¿Pasaron las gates?
│
┌────────┴────────┐
│ │
▼ ▼
NO SÍ
│ │
▼ ▼
Bloquea merge ┌──────────────────┐
│ Merge a main │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Changelog auto │ ← Módulo 4
│ Readiness check │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Deploy a staging │ ← Módulo 4
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Staging validate │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Approval gate │ ← Módulo 4
│ (human required) │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Deploy a prod │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Monitoring + │ ← Módulo 5
│ rollback trigger │
└──────────────────┘
Cada nodo de este diagrama es un step que ya configuraste en módulos previos. Lo que este proyecto integra es el flujo entre nodos: qué pasa cuando un step falla, cómo se propaga, dónde están las gates humanas.
Prerequisitos
Conocimiento requerido:
- ✅ Módulos 1-5 completados (todas las piezas funcionando individualmente)
- ✅ Acceso a un proyecto donde puedas configurar el pipeline completo
- ✅ Permisos de admin en el repositorio (para configurar environments, secrets, branch protection)
Recomendado:
- ✅ Un proyecto de tamaño realista (no un "hello world")
- ✅ Métricas de monitoring accesibles
- ✅ Acuerdo del equipo en usar el pipeline (no solo proyecto personal)
NO requerido:
- ❌ No necesitas tener Kubernetes/Terraform/etc — el pipeline es agnóstico de hosting
Roadmap del Módulo
Cápsula 01 — Introducción al proyecto (esta cápsula)
Vista general del pipeline completo. Por qué importa la integración. Estructura del proyecto.
Cápsula 02 — Diseño del pipeline end-to-end
Diseñar la arquitectura: qué steps, en qué orden, qué dependencias, qué gates. Decidir trade-offs (rapidez vs cobertura, paralelismo vs costo).
Cápsula 03 — Implementación: stages 1-3 (PR review)
Implementar los stages pre-merge: code review automático, security scanning, validación. Hacer que las gates fallen correctamente.
Cápsula 04 — Implementación: stages 4-6 (deployment)
Implementar los stages post-merge: changelog, readiness, deploy a staging, validación, approval gate, deploy a producción.
Cápsula 05 — Failure paths y observabilidad
Cubrir los caminos donde algo falla: code review encontró problemas, security scan bloqueó, deployment a staging falló, producción detectó issue. Para cada uno: qué pasa, qué se notifica, cómo se recupera.
Cápsula 06 — Documentación, optimización y retrospectiva
Documentar el pipeline para que un colega lo pueda operar. Optimizar costos y velocidad. Producir retrospectiva con métricas reales: cuánto cuesta, cuánto tiempo ahorra, qué mejorarías.
Mapa de progresión
Cápsula 01 (esta) → Vista general
Cápsula 02 → Diseño
Cápsula 03 → Implementar pre-merge
Cápsula 04 → Implementar deployment
Cápsula 05 → Failure paths
Cápsula 06 → Docs + optimización + retrospectiva
Dificultad: ⭐⭐⭐ ──────────▶ ⭐⭐⭐⭐⭐
Qué Lograrás en Este Proyecto
Al completar las 6 cápsulas, tendrás:
- Pipeline funcional end-to-end desde PR hasta producción con todas las gates
- Failure paths cubiertos: qué pasa cuando cada step falla, cómo se notifica, cómo se recupera
- Documentación operacional: README que un colega del equipo puede usar sin tu ayuda
- Análisis de costos: cuánto cuesta cada run, cuánto cuesta al mes, dónde optimizar
- Retrospectiva profesional: tiempo ahorrado vs proceso manual, ROI calculado, mejoras propuestas
- Pipeline transferible: la metodología aplica a cualquier proyecto futuro
Entregables del Proyecto
1. Pipeline funcional
Workflow YAML(s) en GitHub Actions (o equivalente en GitLab CI/CD si usas el SDK del Módulo 3) que ejecuta:
- ✅ Code review automático en PRs (Módulo 2)
- ✅ Security scanning con Claude Code + herramientas (Módulo 5)
- ✅ Tests y linting
- ✅ Generación de changelog (Módulo 4)
- ✅ Readiness validation (Módulo 4)
- ✅ Deploy a staging
- ✅ Staging validation
- ✅ Approval gate antes de producción (Módulo 4)
- ✅ Deploy a producción
- ✅ Monitoring + rollback automático (Módulo 5)
- ✅ Diagnóstico post-rollback (Módulo 5)
2. Documentación
- README.md del pipeline — qué hace, cómo se ejecuta, cómo se opera
- OPERATIONS.md — qué hacer si X falla (un runbook básico)
- CONFIG.md — variables, secrets, environments configurados
3. Retrospectiva
- METRICS.md — tiempo por run, costo por run, comparación con proceso manual
- OPTIMIZATIONS.md — qué mejorarías, en qué orden, qué costo
- LESSONS.md — qué aprendiste construyéndolo
Trampas a Evitar al Cursar Este Módulo
Cinco malentendidos previsibles. Anticípalos antes de empezar.
1. "Solo el happy path es suficiente"
No. Un pipeline que solo funciona cuando todo va bien no está terminado. La cápsula 05 cubre los failure paths — qué pasa cuando code review rechaza, qué pasa cuando staging falla, qué pasa cuando producción detecta error. Sin failure paths, el pipeline no se puede usar en producción real.
2. "Documentación al final si queda tiempo"
No. La documentación es el segundo entregable más valioso del proyecto, después del pipeline mismo. Un pipeline que solo el creador entiende no es adoptable por el equipo. La cápsula 06 desarrolla docs como parte del proceso, no opcional.
3. "Ignorar costos porque 'es solo un proyecto'"
No. El pipeline integrador con Claude Code en 5+ steps puede costar varios dólares por run. Con 50 PRs por semana, son cientos de dólares al mes. Sin análisis de costos y optimización, el equipo va a desactivar el pipeline cuando llegue la factura. La cápsula 06 te enseña a calcular y optimizar (cache, ejecución condicional, parallelismo).
4. "Pipeline largo es pipeline mejor"
Lo opuesto. Si el pipeline tarda 30 minutos por PR, los developers lo perciben como obstáculo y buscan formas de saltarlo. Optimizar para ejecución rápida en happy path (con gates rápidas) es parte del diseño. La cápsula 06 desarrolla las técnicas de optimización.
5. "Saltar la retrospectiva"
La retrospectiva es lo que convierte el proyecto en aprendizaje sistematizado. ¿Cuánto cuesta cada run? ¿Cuánto tiempo ahorra vs review manual? ¿Cuáles son los cuellos de botella? Estas preguntas son lo que diferencia un proyecto académico ("hice un pipeline") de un proyecto profesional ("entregué un pipeline con análisis de ROI"). La cápsula 06 estructura la retrospectiva.
Diagnóstico: ¿Listo para el Proyecto Integrador?
Cinco preguntas para confirmar que tienes lo necesario antes de empezar.
Pregunta 1: ¿Tienes un workflow YAML funcional con secrets management correcto? (Módulo 1)
Si sí: vas listo para la cápsula 02.
Si no: repasa Módulo 1. Es el cimiento técnico de todo el pipeline.
Pregunta 2: ¿Tu bot de code review genera inline comments y opera en suggest-only mode? (Módulo 2)
Si sí: la cápsula 03 puede ejecutar.
Si no: repasa Módulo 2 cápsula 03 (inline comments) y cápsula 04 (suggest-only).
Pregunta 3: ¿Sabes generar un changelog automático y validar readiness pre-deploy? (Módulo 4)
Si sí: la cápsula 04 va a fluir.
Si no: repasa Módulo 4. Sin esto, la mitad post-merge del pipeline queda débil.
Pregunta 4: ¿Tu pipeline tiene rollback automático con diagnóstico configurado? (Módulo 5)
Si sí: la cápsula 05 (failure paths) construye sobre esto.
Si no: repasa Módulo 5. Es el safety net del pipeline.
Pregunta 5: ¿Sabes la diferencia entre security scanning con Claude Code y herramientas como Snyk?
Si sí: la cápsula 03 los integra correctamente.
Si no: repasa Módulo 5 cápsula 03. Confundirlos lleva a duplicar trabajo o saltar capas.
Si dudaste en 2 o más: regresa al módulo correspondiente antes de empezar el proyecto. El módulo 6 no se puede ejecutar bien sin los previos sólidos. Si respondiste todas con confianza, estás listo — empieza con el diseño del pipeline en la cápsula 02.
Cómo Trabajar Este Módulo
- La cápsula 02 es la más estratégica. Diseñar bien antes de implementar te ahorra horas.
- Las cápsulas 03-04 son las más mecánicas. Implementación pieza a pieza, ya tienes todas las técnicas.
- La cápsula 05 es donde el pipeline se vuelve real. Cubrir failure paths es lo que separa un demo de un sistema de producción.
- La cápsula 06 es donde el pipeline se vuelve transferible. Documentación + optimización + retrospectiva.
Tiempo estimado:
Cápsula 01 (esta) → 10 min lectura
Cápsula 02 → 20-30 min de diseño
Cápsula 03 → 30-45 min de implementación
Cápsula 04 → 30-45 min de implementación
Cápsula 05 → 30 min de cobertura de failure paths
Cápsula 06 → 30-45 min de docs + retrospectiva
Total: ~2.5-3.5 horas (proyecto grande)
Evidencia de Éxito Final del Proyecto
Al cierre de toda la guía #10, valida que tu entregable cumple los 8 puntos siguientes:
- ✅ Pipeline funcional end-to-end que cubre desde PR hasta producción con todas las gates
- ✅ Failure paths cubiertos para los 5 modos de fallo principales (code review rechaza, security bloquea, staging falla, approval rechazado, producción detecta error)
- ✅ README del pipeline que un colega usa para operarlo sin tu ayuda
- ✅ Runbook básico (OPERATIONS.md) con qué hacer si X falla
- ✅ Métricas reales (tiempo, costo) por run y comparación con proceso manual
- ✅ Análisis de costos con plan de optimización priorizado
- ✅ Lecciones documentadas — qué aprendiste, qué cambiarías
- ✅ Pipeline corriendo en al menos 3 PRs reales con resultados positivos
Si los 8 puntos están en su lugar, completaste la guía #10 — y tienes un artefacto que demuestra habilidad senior en CI/CD con Claude Code.
Resumen
- Este módulo integra los 5 módulos previos en un pipeline end-to-end
- El cambio de foco es de steps individuales a sistema coordinado
- Failure paths son features, no opcionales
- Documentación es entregable, no afterthought
- Costos se calculan y se optimizan — el pipeline tiene que ser sustentable
- Retrospectiva convierte el proyecto en aprendizaje sistematizado
- El entregable es portfolio-worthy — demuestra habilidad senior en CI/CD con Claude Code
Siguiente cápsula: 02 — Diseño del pipeline end-to-end. Empezamos por el diseño antes de la implementación. Sin diseño claro, las cápsulas 03-04 se vuelven implementación a ciegas con retrabajo costoso.
Lo Que Sigue Después del Módulo
Este es el último módulo de la guía #10 (Claude Code in CI/CD Pipelines). El siguiente paso en el path Agentic Development es la Guía 11 (Security for AI-Generated Code) — la guía final del path. La transición es natural:
- Esta guía: cómo automatizar Claude Code en pipelines
- Guía 11: cómo asegurar que el código generado por AI (en interactivo o pipelines) sea seguro
La guía 11 es 100% tool-agnostic — aplica a cualquier herramienta AI, no solo Claude Code. Es el cierre del path con la perspectiva que diferencia un developer profesional: no solo automatizar, sino automatizar de forma segura.
Recursos para el Proyecto
- GitHub Actions Documentation — Tu plataforma principal
- Claude Code SDK — Para portabilidad cross-platform
- Site Reliability Engineering Book — El libro de Google sobre operación de sistemas
- The Twelve-Factor App — Principios para apps deployables
- Continuous Delivery — Jez Humble — La referencia clásica
- GitHub Actions Pricing — Para calcular costos del pipeline
- DORA Metrics — Las 4 métricas que importan para CI/CD (deployment frequency, lead time, MTTR, change failure rate)