Módulo 8: Capstone The Andes Cargo Pipeline
1. Introducción al capstone: el pipeline completo, de punta a punta
Descripción
Siete módulos construyeron, pieza por pieza, un pipeline de CI/CD de infraestructura completo y real: ci.yml calcula un plan en cada Pull Request y lo bloquea si intenta destruir la tabla Shipments; apply.yml aplica exactamente ese plan —nunca uno recalculado— solo cuando ese PR se fusiona a main; drift.yml vigila, con un chequeo programado, que nadie haya tocado la infraestructura por fuera de Terraform. Este último módulo no agrega ni un step nuevo a ninguno de los tres archivos. Lo que hace es lo que ningún módulo anterior tuvo espacio para hacer: correr el pipeline completo, de punta a punta, sobre dos escenarios que juntos prueban la tesis entera de esta guía —un cambio real que el pipeline aprueba y aplica, y un cambio peligroso que el mismo pipeline detiene antes de que llegue a tocar nada—, cerrar con la honestidad final sobre qué parte de todo esto solo se vive con una cuenta de GitHub real, trazar la frontera exacta hacia la seguridad que esta guía nombró pero no construyó, y entregar el repositorio completo como una pieza de portfolio que puedes defender en una entrevista técnica sin dudar.
Conexión con el módulo
Este módulo no introduce ningún mecanismo nuevo — es, a propósito, el único módulo de esta guía que no construye nada. Las lecciones 3 y 4 son el recorrido end-to-end que da título a este capstone: un cambio real cruzando ci.yml → apply.yml, y un intento de destrucción que el guardrail del Módulo 6 detiene antes de que exista la posibilidad de aplicar. Las lecciones 5, 6 y 7 son honestidad de frontera —qué falta, y en qué guía vive—. La lección 8 es el cierre: el mismo repositorio andes-cargo-infra/ que empezaste a preparar en el Módulo 1, ahora completo, documentado, y listo para mostrarse.
Lo que ya tienes, módulo por módulo
Antes de correr nada, vale la pena tener el inventario completo en la cabeza — no como un resumen abstracto, sino como la lista exacta de piezas que vas a ver trabajar juntas en este módulo:
| Módulo | Qué construyó | Vive en |
|---|---|---|
| 1 | act instalado (0.2.89), .actrc pineado, andes-cargo-infra/ inicializado como repositorio Git, LocalStack arrancado en el host | .actrc, .git/ |
| 2 | La anatomía completa de un workflow; pr-event.json (PR #42, feature/add-shipment-tags → main) para simular eventos sin una cuenta de GitHub real; .secrets gitignorado | .github/act-events/pr-event.json, .secrets |
| 3 | ci.yml: fmt → init → validate → conexión a LocalStack → plan → resumen publicado en $GITHUB_STEP_SUMMARY | .github/workflows/ci.yml |
| 4 | Credenciales migradas a secrets.AWS_ACCESS_KEY_ID/secrets.AWS_SECRET_ACCESS_KEY; OIDC mostrado en YAML real, sin ejecutar; Environments dev/production explicados, con act confirmado ignorándolos | .github/workflows/ci.yml (migrado), SECRETS-AND-ENVIRONMENTS.md |
| 5 | apply.yml: needs: + upload-artifact/download-artifact para aplicar el plan exacto, concurrency: contra el doble apply, drift.yml con terraform_wrapper: false | .github/workflows/apply.yml, .github/workflows/drift.yml |
| 6 | git revert como rollback de infraestructura; branch protection explicada (representativa); el guardrail: un grep sobre terraform show -json que bloquea cualquier plan que destruya Shipments, probado con un fixture de state sembrado | .github/workflows/ci.yml (con guardrail), .github/workflows/guardrail-demo.yml, .github/guardrail-fixtures/ |
| 7 | El panorama de mercado (GitLab CI, CircleCI, Jenkins), GitOps pull-based (ArgoCD/Flux, nombrado), la frontera con CI/CD de aplicación, un ADR documentando por qué Andes Cargo eligió GitHub Actions | doc/adr/0001-choosing-cicd-tooling.md |
Nada de esta tabla es teórico — cada fila es un archivo real que corriste con act, contra el mismo LocalStack, con la misma cuenta 000000000000 y la misma región us-east-1 que terraform-and-iac-guide dejó configuradas desde el principio. Lo único que faltaba era verlas todas trabajar juntas, bajo presión, sobre un cambio que sí importa y uno que no debería pasar.
El mapa de este módulo: las 8 lecciones
MÓDULO 8 — CAPSTONE: EL PIPELINE DE ANDES CARGO
L1 Introducción (esta) el inventario completo, qué se entrega
L2 Repaso de arquitectura diagrama completo: ci.yml + apply.yml +
drift.yml + guardrail + red act↔LocalStack
L3 Cambio real, de punta a punta EJECUTADO — un tag nuevo cruza todo el pipeline
L4 Cambio rechazado, de punta a punta EJECUTADO — el guardrail detiene una destrucción
L5 Lo que solo GitHub real muestra REPRESENTATIVO — comentarios de PR, aprobación,
branch protection reales
L6 La seguridad que no se construyó frontera → cloud-security-and-guardrails-guide
L7 Lo que Andes Cargo todavía necesita mapa del ecosistema: EKS, SRE, FinOps
L8 Proyecto: el capstone completo EJECUTADO — el repositorio como portfolio| # | Lección | Qué se ejecuta/practica |
|---|---|---|
| 1 | Introducción (esta) | El inventario completo de los Módulos 1-7; qué se entrega al cerrar esta guía |
| 2 | Repaso de arquitectura: el pipeline completo | Diagrama ASCII completo: ci.yml + apply.yml + drift.yml, el guardrail, y la red act job ↔ host.docker.internal ↔ LocalStack |
| 3 | Recorrido end-to-end: un cambio real | EJECUTADO: un tag nuevo en el bucket, rama → PR simulado → ci.yml → fusión simulada → apply.yml, verificado con awslocal |
| 4 | Recorrido end-to-end: un cambio rechazado | EJECUTADO: un intento de destruir Shipments que el guardrail detiene antes de aplicar |
| 5 | Lo que solo se vive con una cuenta de GitHub real | REPRESENTATIVO: comentarios de PR reales, aprobación de environment real, branch protection real |
| 6 | La seguridad que esta guía no construyó | Frontera explícita: OIDC de punta a punta, SAST/DAST, SBOM/cosign/Trivy, políticas como sistema → cloud-security-and-guardrails-guide |
| 7 | Lo que Andes Cargo todavía necesita | Mapa del ecosistema: EKS + ArgoCD, SRE del despliegue, FinOps de infraestructura |
| 8 | Proyecto final: el pipeline como entregable | EJECUTADO: el repositorio completo como pieza de portfolio defendible en una entrevista |
Fíjate en la forma del módulo: las lecciones 3 y 4 son la prueba técnica —la misma disciplina de "nada se simula en prosa" que sostuvo toda esta guía, aplicada por última vez, con la presión añadida de que ahora todo tiene que funcionar junto, no aislado—. Las lecciones 5, 6 y 7 son honestidad de frontera, la misma que ya viste puntualmente en el Módulo 4 (OIDC) y el Módulo 6 (conftest), ahora consolidada en un solo lugar antes de cerrar la guía. La lección 8 convierte las siete anteriores en un entregable único.
Qué se ejecuta y qué queda representativo en este módulo, sin ambigüedad
Lección ¿Se ejecuta? Por qué
L2 No (es diagrama) Repaso de lo ya construido, sin código nuevo que correr
L3 Sí act pull_request + act push, sobre un cambio real de HCL
L4 Sí act workflow_dispatch, sobre el guardrail del Módulo 6
L5 No Comentarios de PR/aprobación/branch protection son de
GitHub.com real — ya viste por qué act no los alcanza
L6 No Nombra, no construye — la misma frontera del Módulo 4
L7 No Mapa del ecosistema, sin tocar ningún recurso nuevo
L8 Sí La auditoría del repositorio completo, comandos realesCuatro de las ocho lecciones —la mitad— son honestidad de frontera sin ejecución, y eso es intencional, no un relleno de cierre: cerrar una guía completa exige, con el mismo rigor que abrirla, decir con precisión qué queda fuera. Las otras cuatro —2, 3, 4 y 8— son donde este módulo gana su lugar: la lección 2 te da el mapa completo antes de correr nada; las lecciones 3 y 4 son la prueba final, bajo presión, de que cada pieza construida en los siete módulos anteriores sigue funcionando cuando se juntan todas; la lección 8 convierte todo eso en algo que puedes enseñarle a otra persona.
Errores comunes
Esperar que este módulo agregue un noveno step, un cuarto workflow, o una pieza técnica nueva (de expectativa). Qué pasa: alguien, acostumbrado a que cada módulo anterior terminara con al menos un archivo .yml nuevo o extendido, busca ese mismo patrón aquí y no lo encuentra. Cómo detectarlo: si tu pregunta al abrir la lección 2 es "¿qué construyo hoy?" en vez de "¿qué ya construí, y cómo se ve completo?". Cómo corregirlo: este módulo integra y prueba, no construye — la única excepción real es el README.md de portfolio de la lección 8, que documenta, no automatiza nada nuevo.
Saltarse las lecciones 5-7 por parecer "solo teoría" (de alcance, el error más costoso de cerrar mal una guía). Qué pasa: alguien, motivado por la ejecución tangible de las lecciones 3 y 4, avanza directo a la lección 8 sin leer la honestidad de frontera de las lecciones 5, 6 y 7. Por qué pasa: después de ver act correr de verdad, una lección sin comandos se siente menos importante. Cómo corregirlo: en una entrevista técnica real, la pregunta "¿qué le falta a este pipeline?" es tan común como "¿cómo funciona?" — las lecciones 5-7 son, literalmente, el guion completo de esa respuesta, con la frontera exacta hacia cada guía hermana de este ecosistema.
Pensar que "capstone" significa "repetir lo ya hecho, sin nada nuevo que aprender" (conceptual). Qué pasa: alguien asume que las lecciones 3 y 4 son solo una repetición de los proyectos del Módulo 3, el Módulo 5 y el Módulo 6, y las lee en diagonal. Cómo corregirlo: cada proyecto anterior probó una mitad del pipeline por separado (CI solo, CD solo, el guardrail aislado). Las lecciones 3 y 4 de este módulo son la primera vez que ves las tres capas —revisión, aplicación, red de seguridad— actuar en la misma corrida, sobre el mismo cambio, sin ningún atajo — la prueba de integración final, no una repetición.
Ejercicios
Ejercicio 1 — Reconstruye el inventario de los siete módulos, de memoria. Sin mirar la tabla de esta lección, escribe qué construyó cada uno de los Módulos 1 a 7, en una frase por módulo.
Ver solución
M1: act instalado y verificado, andes-cargo-infra/ inicializado como repositorio Git, LocalStack arrancado. M2: la anatomía completa de un workflow, simulación de eventos con act -e (pr-event.json), secretos con .secrets. M3: ci.yml completo — fmt/validate/plan/resumen. M4: secretos migrados a secrets.<NOMBRE>, OIDC mostrado sin ejecutar, Environments explicados. M5: apply.yml con needs:/artefactos/concurrencia, drift.yml programado. M6: rollback con git revert, branch protection explicada, el guardrail real contra la destrucción de Shipments. M7: el panorama de mercado y el ADR de decisión de herramienta. Si reconstruiste los siete sin mirar, tienes el inventario completo internalizado, no solo copiado de una tabla.
Ejercicio 2 — Predice qué pasaría si el Módulo 6 no existiera. Sin el guardrail del Módulo 6, ¿qué detendría, hoy, un Pull Request que intenta destruir la tabla Shipments? Responde con precisión, usando lo que ya sabes de los Módulos 3 y 4.
Ver solución
Nada lo detendría automáticamente. ci.yml, sin el guardrail, calcularía el plan con la destrucción incluida y lo publicaría en el resumen del job —exactamente como calcula cualquier otro plan—, pero el job terminaría en verde de todas formas, porque un plan que destruye algo no es, por sí solo, un error de Terraform. La única defensa, sin el guardrail, sería que una persona revisara el contenido del plan a tiempo y decidiera no aprobar la fusión — es decir, dependería completamente del juicio humano en el momento exacto de la revisión, sin ningún control automatizado de respaldo. Esta es exactamente la razón por la que el Módulo 6 existe: convertir "alguien debería darse cuenta" en "el pipeline no deja que pase, incluso si nadie se da cuenta".
Ejercicio 3 — Anticipa la estructura de las lecciones 3 y 4. Basándote en el patrón de "Qué esperar (literal)" que sostuvo toda esta guía, ¿qué tipo de evidencia esperarías ver en la lección 4 que confirme que el guardrail bloqueó el cambio, más allá de leer la palabra "failed" en algún lado?
Ver solución
Siguiendo el mismo patrón que el Módulo 6, lección 7, la evidencia completa debería incluir: (1) el número exacto del plan (algo como X to add, 1 to destroy, con el 1 to destroy como la señal concreta), (2) el mensaje de error exacto del guardrail, citando el recurso específico (aws_dynamodb_table.shipments), y (3), la pieza más importante para la tesis de este módulo, la confirmación de que ningún step posterior corrió — específicamente, que nunca se subió ningún artefacto llamado terraform-plan, lo que significa que apply.yml, aunque alguien lo disparara a mano, no tendría nada que aplicar. Ver solo "Job failed" sin estas tres piezas no sería suficiente evidencia de que la red de seguridad funcionó por la razón correcta.
Resumen y siguiente paso
En esta lección repasaste el inventario completo de los siete módulos anteriores —cada pieza real, cada archivo que sigue viviendo en andes-cargo-infra/— y viste el mapa de las ocho lecciones que cierran esta guía: dos lecciones de prueba técnica final (3 y 4), tres de honestidad de frontera (5, 6 y 7), y un proyecto que convierte todo en un entregable de portfolio (8), precedidas por esta introducción y un repaso de arquitectura (2).
Antes de avanzar deberías poder: nombrar, sin mirar, qué construyó cada uno de los Módulos 1 a 7; explicar por qué este módulo no agrega ninguna pieza técnica nueva al pipeline; y anticipar, con precisión, qué tipo de evidencia esperarías ver en un recorrido end-to-end exitoso y en uno rechazado.
La lección 2 arma el diagrama completo del pipeline —los tres workflows, el guardrail, y la red que conecta el contenedor de act con el LocalStack del host— antes de correr nada, para que las lecciones 3 y 4 tengan, desde el primer comando, el mapa completo en la cabeza.
Recursos
- nektosact.com — User Guide — referencia completa de
act, la herramienta que este módulo vuelve a usar de punta a punta. - GitHub Docs — GitHub Actions — documentación oficial del motor completo detrás de los tres workflows de Andes Cargo.
- HashiCorp Developer — Automate Terraform with GitHub Actions — el patrón
plan/applyque sostiene el pipeline entero, citado desde el Módulo 3. src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA) — la brecha de mercado que esta guía completa cierra, citada desde el Módulo 1.