Módulo 7: Gitops Beyond Terraform
1. Introducción al Módulo 7: lo que esta guía no es
Descripción
Los seis módulos anteriores construyeron algo real y completo: un pipeline de GitHub Actions que corre fmt, validate y plan en cada Pull Request, aplica automáticamente cuando ese PR se fusiona a main, detecta drift con un job programado, y se detiene solo si un cambio intenta destruir la tabla Shipments. Es tentador, en este punto, sentir que "ya sabes CI/CD" — sin comillas, en general, para cualquier proyecto. Este módulo existe para corregir esa sensación antes de que se instale, no después. Vas a conocer, por contraste y sin construir nada nuevo, tres herramientas de mercado reales (GitLab CI, CircleCI, Jenkins), el GitOps pull-based que usa Kubernetes (ArgoCD, Flux), las estrategias de despliegue de una aplicación (blue/green, canary, rolling), y la frontera exacta entre CI/CD de infraestructura —lo que construiste— y CI/CD de código de aplicación. Vas a ejecutar, de verdad, exactamente una cosa nueva: un pipeline mínimo de tres pasos sobre un script Python trivial, solo para que la diferencia con el pipeline de infraestructura deje de ser una afirmación en prosa y se vuelva algo que viste correr con tus propios ojos.
Conexión con el módulo
Este módulo tiene una estructura distinta a los seis anteriores, y vale la pena que la notes desde ya: en vez de construir una pieza más de andes-cargo-infra/, ubica todo lo que ya construiste dentro de un panorama más grande. Las lecciones 2 a 6 son comparación y honestidad de frontera —herramientas alternativas, el otro GitOps, las estrategias de despliegue, la línea exacta entre infraestructura y aplicación—; ninguna construye nada. La lección 7 es la única manos a la obra genuina del módulo: un pipeline de aplicación de tres pasos, corrido de verdad con act, deliberadamente breve, para que el contraste con ci.yml/apply.yml sea tangible y no solo leído. La lección 8, el proyecto, convierte todo el módulo en un documento real: un ADR (Architecture Decision Record) donde Andes Cargo justifica por escrito su elección de herramienta, exactamente el tipo de documento que un equipo real produce cuando toma esta decisión en un trabajo.
Por qué "ya sé CI/CD" es la trampa exacta que este módulo corrige
Piensa en lo que aprendiste como un mapa de ciudad, cargado en tu teléfono, con cada calle recorrida a pie. Conoces cada cuadra, cada semáforo, cada atajo. El mapa es real y el conocimiento es real — pero un mapa de ciudad, por completo que sea, tiene un borde. Del otro lado de ese borde no hay "nada" — hay una provincia entera, con sus propias rutas, su propio tránsito, sus propias reglas de circulación, que tu mapa actual ni siquiera intenta dibujar. El error no es no conocer la provincia vecina. El error es mirar el borde del mapa y asumir que ahí termina el mundo, en vez de asumir que ahí termina tu mapa.
Los seis módulos anteriores de esta guía son el mapa de una ciudad real y completa: CI/CD de infraestructura, con GitHub Actions, sobre Terraform, con act y LocalStack. Cada calle de esa ciudad la recorriste tú mismo — no es una simplificación ni un resumen. Pero esa ciudad tiene un borde, y del otro lado hay, como mínimo, cuatro territorios enteros que este módulo te va a mostrar en el mapa, sin recorrerlos:
- Otra herramienta de CI, misma ciudad. GitLab CI, CircleCI, Jenkins resuelven el mismo problema (
plan/applysobre un cambio revisado) con sintaxis distinta. Es, literalmente, la misma ciudad, con las calles nombradas distinto — no una provincia nueva. Lección 2. - Otro mecanismo de GitOps, ciudad distinta. ArgoCD y Flux no son "GitHub Actions pero para Kubernetes" — son un tipo de sistema fundamentalmente distinto (un operador que corre dentro del clúster y jala cambios, en vez de un pipeline externo que los empuja). Lecciones 3 y 4.
- El despliegue de una aplicación, un territorio que nunca visitaste. Blue/green, canary, rolling deploys resuelven un problema que esta guía nunca tuvo, porque
terraform applyno tiene "versiones corriendo en paralelo" — cadaapplydeja la infraestructura en un único estado nuevo, no dos coexistiendo mientras se decide cuál se queda. Lección 5. - CI/CD de código, la frontera más importante de las cuatro. Todo lo que construiste corre sobre HCL declarativo. Un pipeline que compila, testea y despliega un artefacto de aplicación (una API en Python, un contenedor) tiene una forma distinta, con sus propios pasos característicos. Lección 6, con una prueba tangible en la lección 7.
Saber dónde está el borde de tu mapa —y qué hay, aunque sea de nombre, del otro lado— es una habilidad tan real como saber leer un terraform plan. Es la diferencia entre alguien que dice "sé CI/CD" sin poder explicar qué le falta, y alguien que dice "sé CI/CD de infraestructura con GitHub Actions; para Kubernetes necesitaría ArgoCD, y para el backend de la app necesitaría un pipeline de test/build/deploy distinto" — la segunda persona suena, en una entrevista real, exactamente como alguien que entiende el panorama completo, no solo su propia esquina.
El mapa de este módulo: las 8 lecciones
MÓDULO 7 — GITOPS MÁS ALLÁ DE TERRAFORM
L1 Introducción (esta) el borde del mapa, por qué importa conocerlo
L2 GitLab CI/CircleCI/Jenkins misma ciudad, sintaxis distinta — NOMBRADO
L3 ArgoCD y Flux otro mecanismo de GitOps — NOMBRADO
L4 Push-based vs. pull-based la distinción técnica real, cierra M1.4
L5 Blue/green, canary, rolling despliegue de app — NOMBRADO
L6 CI/CD de app vs. infraestructura contraste explícito, corto
L7 Manos a la obra: pipeline de app EJECUTADO — 3 steps, Python trivial, act
L8 Proyecto: el ADR de Andes Cargo EJECUTADO (documento) — la decisión, por escrito| # | Lección | Qué se ejecuta/practica |
|---|---|---|
| 1 | Introducción (esta) | Mapa del módulo; por qué importa saber dónde termina esta guía |
| 2 | GitLab CI, CircleCI y Jenkins por contraste | Comparación de sintaxis y modelo; la evidencia de mercado completa (Jenkins 5/13) retomada del Módulo 1 |
| 3 | GitOps para Kubernetes: ArgoCD y Flux, nombrados | Qué son — NOMBRADO, frontera dura a kubernetes-and-eks-in-production-guide |
| 4 | Push-based vs. pull-based | La distinción técnica real, cierra el hilo abierto en el Módulo 1 |
| 5 | Estrategias de despliegue de aplicación, nombradas | Blue/green, canary, rolling — NOMBRADO, frontera a kubernetes-and-eks-in-production-guide/aws-serverless-and-containers-guide |
| 6 | CI/CD de código de aplicación vs. infraestructura | Contraste explícito y corto |
| 7 | Manos a la obra: un pipeline mínimo de aplicación | EJECUTADO: checkout/lint/test sobre un script Python trivial, con act |
| 8 | Proyecto: la decisión de herramienta de Andes Cargo | EJECUTADO (el documento): un ADR corto |
Fíjate en la progresión: primero herramientas que resuelven el mismo problema que ya resolviste (lección 2), después mecanismos que resuelven un problema distinto con el mismo principio de fondo (lecciones 3-4), después un dominio que nunca tocaste (lecciones 5-6), y cierras con una prueba concreta (lección 7) y una decisión documentada (lección 8).
Qué se ejecuta y qué se nombra, sin ambigüedad
Esta guía sostuvo, desde el Módulo 1, la regla de que nada se simula en prosa: si algo aparece como ejecutado, corrió de verdad. Este módulo agrega una capa nueva a esa honestidad, porque por primera vez la mayoría de las lecciones son, a propósito, nombradas, no ejecutadas — y la razón no es una limitación de act (como las cinco excepciones del Módulo 1), es que construir ArgoCD, Flux, o un pipeline de blue/green real está, por diseño, fuera del alcance de esta guía específica.
| Lección | ¿Se ejecuta? | Por qué |
|---|---|---|
| L2 — GitLab CI/CircleCI/Jenkins | No | Instalar y correr las tres herramientas está fuera del alcance $0 y de una sola guía — se muestra su sintaxis real, verificada contra su documentación oficial, sin instalarlas |
| L3 — ArgoCD/Flux | No | Requieren un clúster de Kubernetes — frontera dura a kubernetes-and-eks-in-production-guide |
| L4 — Push vs. pull | Parcial | El push ya lo ejecutaste en los Módulos 3 y 5 (ci.yml, apply.yml); el pull se explica con el mecanismo de ArgoCD/Flux, sin construirlo |
| L5 — Blue/green/canary/rolling | No | Requieren una aplicación con múltiples réplicas corriendo — frontera a kubernetes-and-eks-in-production-guide/aws-serverless-and-containers-guide |
| L6 — CI/CD de app vs. infra | No (es contraste conceptual) | La lección 7 sí ejecuta la mitad "app" de este contraste |
| L7 — Pipeline mínimo de app | Sí | Tres steps (checkout, lint, test) sobre un script Python trivial, corridos con act — la única ejecución de código nuevo en todo el módulo |
| L8 — ADR de Andes Cargo | Sí (como documento) | El ADR en sí es el entregable ejecutado — no corre código, pero es un artefacto real, no una descripción en abstracto |
Nombrar sin construir no es, en este módulo, una laguna — es la frontera declarada del diseño de esta guía completa, la misma lógica que ya viste con OIDC en el Módulo 4 y con conftest en el Módulo 6. La diferencia es de escala: ahí eran piezas puntuales dentro del mismo dominio (Terraform sobre AWS); aquí son dominios enteros (Kubernetes, CI/CD de aplicación) que tienen sus propias guías completas en este mismo ecosistema.
Errores comunes
Pensar que este módulo "no cuenta" porque no construye nada nuevo (de expectativa). Qué pasa: alguien llega a este módulo esperando otro workflow de GitHub Actions con pasos nuevos, y al ver que la mayoría de las lecciones son comparación en prosa, las lee en diagonal o las salta. Por qué pasa: los seis módulos anteriores entrenaron el hábito de "cada lección agrega una pieza al pipeline" — este módulo rompe ese patrón a propósito. Cómo detectarlo: si tu pregunta al abrir una lección de este módulo es "¿qué YAML nuevo voy a escribir?" en vez de "¿qué necesito saber que existe, aunque no lo construya aquí?". Cómo corregirlo: el valor de este módulo es exactamente el que describe esta lección — conocer el borde del mapa. Una persona que puede nombrar ArgoCD, explicar push vs. pull, y ubicar dónde termina esta guía frente a kubernetes-and-eks-in-production-guide demuestra un nivel de comprensión que "sé escribir YAML" por sí solo no demuestra.
Concluir que, como este módulo nombra ArgoCD y blue/green, "ya sabes" usarlos (el error inverso, más peligroso). Qué pasa: alguien lee las lecciones 3 y 5, ve el YAML de ejemplo de ArgoCD o el diagrama de blue/green, y en una entrevista real afirma tener experiencia con esas herramientas. Por qué pasa: leer sobre algo y poder nombrarlo con precisión se siente parecido a saber usarlo, sobre todo cuando el resto de la guía sí fue manos a la obra real. Cómo detectarlo: si no podrías, hoy, instalar ArgoCD contra un clúster y hacer que sincronice un repositorio — eso es "no construido", sin importar qué tan clara sea la explicación que leíste. Cómo corregirlo: cada lección de este módulo marcada NOMBRADO lo dice explícitamente, en el momento exacto en que aparece, precisamente para que esta confusión no ocurra. Nombrar una herramienta con precisión te prepara para reconocerla y aprenderla rápido cuando la necesites de verdad — no reemplaza construir con ella.
Asumir que "GitOps" tiene una sola forma correcta, la que aprendiste en los Módulos 1-6 (conceptual). Qué pasa: alguien, después de seis módulos construyendo un pipeline push-based, concluye que ese es "el" GitOps, y que el pull-based de Kubernetes es una variante menor o incorrecta. Por qué pasa: es natural generalizar a partir de la única implementación que viviste de cerca. Cómo detectarlo: si te sorprende, en la lección 4, que el mecanismo de ArgoCD sea genuinamente distinto —no una versión "con más pasos" de lo que ya conoces—. Cómo corregirlo: el Módulo 1, lección 4, ya adelantó que GitOps se define por cuatro propiedades (declarativo, Git como fuente de verdad, aplicación automática, reconciliación continua), no por un mecanismo específico. Las lecciones 3 y 4 de este módulo completan esa idea con el detalle técnico exacto de las dos formas dominantes de cumplirlas.
Ejercicios
Ejercicio 1 — Nombra los cuatro territorios fuera del mapa. Sin mirar esta lección, escribe de memoria los cuatro dominios que este módulo va a nombrar sin construir, y qué guía del ecosistema los cubre en profundidad.
Ver solución
1. Otras herramientas de CI (GitLab CI, CircleCI, Jenkins) — no tienen una guía dedicada en este ecosistema; se nombran por contraste dentro de esta misma guía. 2. GitOps pull-based de Kubernetes (ArgoCD, Flux) — kubernetes-and-eks-in-production-guide. 3. Estrategias de despliegue de aplicación (blue/green, canary, rolling) — kubernetes-and-eks-in-production-guide y aws-serverless-and-containers-guide. 4. CI/CD de código de aplicación (test, build, deploy de un artefacto) — cicd-python-backend-guide y testing-in-cicd-guide. Si nombraste los cuatro territorios y al menos tres de las cuatro guías, tienes clara la frontera que este módulo traza.
Ejercicio 2 — Distingue "mismo problema" de "problema distinto". De las cuatro herramientas/dominios del ejercicio 1, ¿cuál resuelve exactamente el mismo problema que ya resolviste (con otra sintaxis), y cuáles resuelven un problema genuinamente distinto? Justifica en una frase cada caso.
Ver solución
Mismo problema, otra sintaxis: GitLab CI, CircleCI, Jenkins — los cuatro implementan el patrón plan en cada cambio / revisión / apply automático, solo cambia el archivo de configuración y quién lo mantiene. Problema distinto: GitOps pull-based de Kubernetes resuelve "cómo mantener sincronizado el estado de un clúster" con un mecanismo (operador interno, watch continuo) que no tiene equivalente en el pipeline de esta guía. Las estrategias de despliegue de aplicación resuelven "cómo pasar de una versión de un artefacto corriendo a otra sin downtime", un problema que Terraform ni siquiera plantea, porque apply no tiene el concepto de "dos versiones coexistiendo mientras se decide". CI/CD de aplicación resuelve "cómo construir, testear y empaquetar código fuente antes de desplegarlo", un paso (compilar/testear un artefacto) que Terraform no tiene, porque el HCL no se "compila" en el mismo sentido.
Ejercicio 3 — Aplica la metáfora del mapa a tu propio conocimiento. Antes de seguir con este módulo, escribe (para ti mismo, no hay solución única) una frase que describa el borde de tu propio mapa: algo que sabes hacer con precisión, y algo relacionado que sabes que existe pero no sabes construir todavía. Guarda esa frase — vas a poder compararla con la misma pregunta al cerrar el Módulo 8.
Ver solución
No hay una única respuesta correcta — es un ejercicio de autoevaluación honesta, el mismo tipo de pregunta que un entrevistador técnico real te podría hacer. Un ejemplo de respuesta completa, en el espíritu de esta guía: "Sé escribir un pipeline de GitHub Actions que corre plan en cada PR y apply en cada merge contra Terraform, con secretos gestionados y un guardrail que protege un recurso específico. Sé que existe ArgoCD para hacer algo parecido dentro de un clúster de Kubernetes, pero no sabría, hoy, instalarlo ni configurar una Application real." Lo que importa no es la respuesta específica, es la honestidad de poder trazar la línea exacta entre las dos partes de la frase — exactamente la habilidad que este módulo entero practica.
Resumen y siguiente paso
En esta lección entendiste el propósito completo del Módulo 7: no agregar una pieza más al pipeline de Andes Cargo, sino ubicar ese pipeline —completo y real— dentro de un panorama más amplio de herramientas y dominios que esta guía, por diseño, no construye. Viste el mapa de las 8 lecciones, la tabla exacta de qué se ejecuta (solo la lección 7) y qué se nombra (el resto), y por qué "conocer el borde del mapa" es una habilidad tan real como cualquiera de las que ya practicaste.
Antes de avanzar deberías poder: nombrar los cuatro territorios fuera del mapa de esta guía y su guía correspondiente en el ecosistema; explicar por qué GitLab CI/CircleCI/Jenkins son "la misma ciudad" mientras que ArgoCD/Flux son "otra ciudad"; y distinguir, sin ayuda, entre "puedo nombrarlo con precisión" y "puedo construirlo".
La lección 2 abre la comparación empezando por el territorio más cercano al que ya conoces: otras herramientas de CI que resuelven el mismo problema que ci.yml y apply.yml, con sintaxis distinta — y retoma, completa, la evidencia de mercado de Jenkins que ya viste en el Módulo 1.
Recursos
- GitHub Docs — GitHub Actions — la documentación oficial de la herramienta que usaste en los Módulos 1 a 6, el punto de comparación de todo este módulo.
- nektosact.com — User Guide — documentación oficial de
act, la única herramienta que este módulo vuelve a ejecutar (lección 7). terraform-and-iac-guide(NIEVA) — el proyectoandes-cargo-infra/completo que este módulo contrasta contra otros dominios, sin volver a reescribirlo.src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA, auditoría de mercado, jul-2026) — la fuente de la evidencia de Jenkins que la lección 2 retoma completa.