Módulo 1: Why Cicd And Gitops
3. CI, CD y CD: tres cosas, una sigla
Descripción
"CI/CD" es, probablemente, el término más usado y menos definido con precisión de toda la infraestructura moderna. Casi todo el mundo lo dice de corrido, como si fuera una sola idea. No lo es: son tres conceptos distintos, dos de los cuales comparten literalmente la misma sigla ("CD") con significados diferentes. Esta lección te da las tres definiciones exactas, sin ambigüedad, y te muestra dónde cae cada pieza de la guía que estás por construir.
Conexión con el módulo
Esta lección es puramente conceptual, y es la más importante de todo el módulo para lo que viene después: cada workflow que vas a escribir desde el Módulo 2 en adelante es, específicamente, CI o específicamente CD —y vas a poder nombrarlo con precisión, no solo llamarlo "parte del pipeline"—. La lección 4 construye sobre esta, agregando GitOps como el principio que hace posible automatizar la parte de CD sin perder control.
Analogía: la cinta de montaje
Imagina una fábrica con una cinta de montaje. Cada pieza que entra pasa por una serie de estaciones automáticas: una revisa las dimensiones, otra revisa que no haya defectos visibles, otra prueba que la pieza encaje con las demás. Ninguna persona inspecciona a mano cada pieza individual —eso sería demasiado lento para el volumen que maneja la fábrica—, pero la cinta sí se detiene sola si una pieza falla alguna de esas estaciones. Eso, exactamente eso, es integración continua: cada cambio pasa por los mismos controles automáticos, y el cambio no avanza si algo falla.
Ahora, al final de esa cinta, hay dos fábricas posibles. En la primera, las piezas que pasaron todos los controles quedan apiladas en un almacén, listas para salir — pero una persona tiene que firmar la orden de despacho antes de que el camión se vaya. Eso es entrega continua: siempre lista, con un gate humano explícito antes de que algo salga de la puerta. En la segunda fábrica, las piezas que pasan todos los controles suben directo al camión de reparto, sin que nadie firme nada — el propio hecho de haber pasado la cinta es la autorización. Eso es despliegue continuo: se despliega solo, sin intervención humana en el último paso.
Las tres definiciones, sin ambigüedad
CI — Integración Continua (Continuous Integration)
Qué responde: ¿este cambio rompe algo?
Qué hace: cada vez que alguien propone un cambio —típicamente, cada push a una rama o cada actualización de un pull request—, un proceso automático corre validaciones: formato, sintaxis, pruebas, y —en el caso específico de esta guía— terraform plan. El resultado de CI es una señal de sí/no: el cambio pasó los controles, o no.
Quién decide correrlo: nadie — corre solo, automáticamente, en cada cambio. No hay ningún botón que apretar para que CI se ejecute.
En esta guía: el Módulo 3 completo construye la mitad de CI del pipeline de Andes Cargo: terraform fmt -check, terraform validate y terraform plan, corridos automáticamente en cada Pull Request, con el plan como el artefacto que un humano va a leer antes de aprobar la fusión.
CD — Entrega Continua (Continuous Delivery)
Qué responde: ¿este cambio está listo para desplegarse, y quién dice que sí?
Qué hace: una vez que CI confirma que el cambio no rompe nada, el sistema garantiza que ese cambio podría desplegarse en cualquier momento —está construido, probado, empaquetado, listo— pero desplegarlo de verdad requiere una acción humana explícita: aprobar un Environment, apretar un botón, fusionar un PR a una rama protegida. La automatización termina justo antes de la línea que un humano tiene que cruzar a propósito.
Quién decide correrlo: un humano, en el momento exacto que elige, con un gesto explícito y registrado.
En esta guía: el patrón de Environments con required reviewers del Módulo 4 (lección 6) es, específicamente, entrega continua — el cambio está listo, pero una persona tiene que aprobarlo antes de que el apply corra contra ese ambiente. Se describe con el camino de clics real; bajo act, esa protección específica no se puede demostrar en vivo (razón técnica exacta en esa lección), pero el mecanismo es exactamente este.
CD — Despliegue Continuo (Continuous Deployment)
Qué responde: ¿este cambio ya está en producción?
Qué hace: exactamente lo mismo que entrega continua, con una diferencia decisiva: no hay ningún gate humano en el último paso. Todo cambio que pasa CI se despliega automáticamente, sin que nadie apruebe ese despliegue específico de forma manual.
Quién decide correrlo: nadie, en el momento del despliegue — la decisión ya se tomó de antemano, al diseñar el pipeline así. (Sí hubo, casi siempre, una decisión humana en un punto anterior: fusionar el PR a main. Eso importa, y esta guía es explícita al respecto — ver la sección siguiente.)
En esta guía: apply.yml, construido en el Módulo 5, dispara terraform apply automáticamente en cada push a main, sin ningún botón adicional que apretar después de la fusión. Es, técnicamente, despliegue continuo de infraestructura.
La tabla que resuelve la confusión de una vez
| CI | CD (entrega) | CD (despliegue) | |
|---|---|---|---|
| Nombre completo | Integración continua | Entrega continua | Despliegue continuo |
| Responde | ¿Rompe algo? | ¿Está listo, y quién dice que sí? | ¿Ya está en vivo? |
| Corre en | Cada push/PR | Después de CI, siempre lista | Después de CI, sin esperar |
| Gate humano al final | No aplica (es la validación en sí) | Sí, explícito | No |
| En esta guía | ci.yml — Módulo 3 | Environments con aprobación — Módulo 4 | apply.yml — Módulo 5 |
La confusión que casi todo el mundo comete: decir "hacemos CD" sin especificar cuál de las dos. Un equipo que dice "tenemos entrega continua" y otro que dice "tenemos despliegue continuo" pueden estar describiendo procesos radicalmente distintos —uno con un botón humano al final, otro sin ninguno— y la sigla, sola, no lo distingue. Desde esta lección en adelante, esta guía nunca usa "CD" sin aclarar cuál de las dos.
Dónde cae, exactamente, el pipeline que vas a construir
sequenceDiagram
participant Dev as Desarrollador/a
participant PR as Pull Request
participant CI as ci.yml (CI)
participant Main as Rama main
participant CD as apply.yml (CD-despliegue)
Dev->>PR: git push a feature/add-shipment-tags
PR->>CI: dispara automáticamente
CI->>CI: fmt + validate + plan
CI-->>PR: plan publicado como evidencia
Note over PR: Un humano lee el plan y aprueba el PR (CD-entrega, aquí)
PR->>Main: merge
Main->>CD: dispara automáticamente (push a main)
CD->>CD: terraform apply
Note over CD: Sin botón adicional — despliegue continuo, a partir de este punto
Fíjate en algo importante, que vas a volver a ver en la lección 5 del Módulo 6: la revisión humana de esta guía no desaparece al llegar a apply.yml — vive en el paso anterior, la aprobación del Pull Request. Eso es, con precisión técnica, lo que hace que el pipeline de Andes Cargo sea seguro sin depender de un botón adicional después de la fusión: el gate humano existe, solo que está ubicado en la revisión del plan, no en un segundo clic después de fusionado. El Módulo 4 (lección 6) agrega, opcionalmente, un segundo gate —un Environment con aprobación— para el caso donde una organización quiere revisión explícita también en ese punto, convirtiendo esa parte específica del flujo en entrega continua en vez de despliegue continuo puro.
Errores comunes
Usar "CD" sin especificar cuál, y no darse cuenta (el más común, por lejos). Qué pasa: alguien dice "vamos a hacer CD para este proyecto" sin aclarar si el pipeline se detiene en un gate humano o despliega solo. Por qué pasa: en el uso cotidiano, casi nadie distingue las dos —la sigla es idéntica, y el contexto rara vez obliga a aclarar—. Cómo detectarlo: si en una conversación sobre CI/CD no puedes responder con certeza "¿hay un botón humano antes de que esto llegue a producción, o no?". Cómo corregirlo: usa siempre el nombre completo la primera vez que lo mencionas en una conversación técnica ("entrega continua" o "despliegue continuo"), exactamente como hace esta guía desde esta lección en adelante.
Pensar que CI termina cuando el código "compila" (de alcance, en el contexto de esta guía). Qué pasa: alguien asume que, como no hay código de aplicación en andes-cargo-infra/ (es HCL, no Python o Java), no aplica el concepto de CI. Por qué pasa: CI se asocia, casi siempre, con pruebas de software tradicional. Cómo detectarlo: si crees que el Módulo 3 de esta guía "no es CI de verdad" porque valida HCL en vez de código de aplicación. Cómo corregirlo: CI es un concepto agnóstico de qué se está validando — es la práctica de correr validaciones automáticas en cada cambio, antes de fusionar. terraform fmt -check, terraform validate y terraform plan cumplen exactamente esa función para infraestructura, tal como un test suite la cumple para una aplicación.
Creer que "despliegue continuo" significa "sin ninguna revisión humana en absoluto" (conceptual, corregido arriba). Qué pasa: alguien concluye que, como apply.yml no tiene un botón después del merge, nadie revisó el cambio antes de que se aplicara. Por qué pasa: es fácil perder de vista que el gate humano puede vivir en un punto anterior del flujo. Cómo detectarlo: si tu resumen del pipeline de esta guía es "nadie revisa nada, todo es automático". Cómo corregirlo: la revisión existe — vive en la aprobación del Pull Request, sobre el plan exacto que después se aplica (Módulo 5, needs + artefactos garantizan que sea el mismo). Despliegue continuo describe dónde vive el gate (antes de fusionar, no después), no que el gate haya desaparecido.
Ejercicios
Ejercicio 1 — Clasifica tres escenarios reales. Para cada uno, decide si describe CI, CD-entrega o CD-despliegue: (a) un equipo corre pruebas automáticas en cada Pull Request, y nadie puede fusionar si fallan; (b) un equipo tiene un botón en su herramienta interna que un gerente de producto aprieta para lanzar la versión nueva a los usuarios; (c) un equipo fusiona a main y, treinta segundos después, la versión nueva ya está sirviendo tráfico real, sin que nadie la haya aprobado de forma separada.
Ver solución
(a) CI — la validación corre en cada cambio, y bloquea la fusión si falla; no hay todavía ninguna noción de "desplegar", solo de "este cambio es válido". (b) CD-entrega — el sistema dejó todo listo, pero un humano (el gerente de producto) tiene que apretar el botón explícitamente para que salga a producción; ese botón es el gate. (c) CD-despliegue — no hay ningún gate humano después de la fusión; el propio merge es, en los hechos, la autorización de despliegue.
Ejercicio 2 — Ubica el gate humano del pipeline de esta guía. Sin mirar el diagrama de esta lección, explica en dos o tres frases dónde vive exactamente la revisión humana en el pipeline de Andes Cargo que vas a construir, y por qué eso hace que apply.yml pueda correr sin un botón adicional de forma segura.
Ver solución
La revisión humana vive en la aprobación del Pull Request: antes de fusionar a main, una persona lee el plan que ci.yml publicó (Módulo 3) y decide si aprueba ese cambio específico. Como apply.yml (Módulo 5) está diseñado para aplicar exactamente ese mismo plan —no uno recalculado después de la fusión—, el hecho de que no haya un botón adicional después del merge no significa que nadie revisó nada: significa que el punto de revisión es la fusión misma, no un paso posterior. Esto es lo que permite llamar a esta parte del flujo "despliegue continuo" sin sacrificar el control humano sobre qué se aplica.
Ejercicio 3 — Diseña el pipeline inverso. Imagina que Andes Cargo decide que quiere agregar un segundo gate humano, específicamente antes de que apply.yml corra contra el ambiente de producción (no solo en la aprobación del PR). ¿Qué mecanismo de GitHub Actions, nombrado ya en esta guía aunque no construido todavía, resolvería exactamente eso? ¿En qué clasificación (CI, CD-entrega, CD-despliegue) caería esa parte específica del flujo después del cambio?
Ver solución
El mecanismo es un Environment con required reviewers, adelantado en esta lección y construido con detalle en el Módulo 4 (lección 6): se configura el apply.yml para que el job que corre terraform apply esté asociado a un Environment llamado, por ejemplo, prod, y ese Environment tiene configurado que uno o más revisores específicos deben aprobar antes de que el job continúe. Con ese cambio, la parte de "aplicar contra producción" deja de ser despliegue continuo puro y pasa a ser entrega continua: el cambio sigue estando siempre listo apenas se fusiona, pero ahora hay un segundo gate humano explícito, separado de la aprobación del PR, antes de que el apply real ocurra.
Resumen y siguiente paso
En esta lección definiste con precisión las tres cosas que comparten la sigla "CI/CD": integración continua (validar cada cambio, sin gate humano porque es la validación en sí), entrega continua (siempre lista, con un gate humano explícito antes del despliegue), y despliegue continuo (se despliega solo, sin botón adicional). Viste dónde cae cada pieza del pipeline que vas a construir en esta guía: ci.yml es CI (Módulo 3), los Environments con aprobación son entrega continua (Módulo 4), y apply.yml disparado por push a main es despliegue continuo de infraestructura (Módulo 5) — con el gate humano real viviendo en la aprobación del Pull Request, no ausente.
Antes de avanzar deberías poder: nombrar las tres definiciones sin confundirlas; explicar por qué "CD" sin aclarar cuál es una fuente común de malentendidos; y ubicar, sin ayuda, en qué módulo de esta guía se construye cada una de las tres piezas.
La lección 4 agrega la pieza que falta para que todo esto funcione sin que un humano tenga que ejecutar manualmente cada paso: GitOps — el principio de que Git, no la memoria de nadie, es la única fuente de verdad de qué infraestructura debería existir.
Recursos
- GitHub Docs — About continuous integration — la definición oficial de GitHub para CI, base de esta lección.
- Martin Fowler — Continuous Delivery — una de las fuentes más citadas de la industria sobre la distinción exacta entre entrega continua y despliegue continuo.
- AWS — What is CI/CD? — la explicación oficial de AWS, con el mismo vocabulario de tres piezas usado en esta lección.
src/paths/aws-cloud-ecosystem/VALIDACION.md(NIEVA) — la evidencia de mercado que confirma CI/CD como el faltante más citado del ecosistema, motivo de esta guía.