7. CI vs CD: una primera mirada

Descripción

Al terminar esta lección vas a poder distinguir con claridad dos siglas que casi siempre aparecen pegadas —CI/CD— y que la gente confunde todo el tiempo. La primera ya la conoces a fondo: CI, Integración Continua, es integrar y verificar —correr la suite en cada cambio para mantener la rama principal verde—. La segunda, CD, es lo que viene después de que el CI dio verde: entregar o desplegar ese código ya verificado hacia el siguiente lugar —un ambiente de staging, o directo a producción—. En una frase: el CI comprueba que el código está bien; el CD lo lleva a donde tiene que estar. Uno verifica, el otro envía. Y el orden importa: el CD depende del CI, porque no tiene ningún sentido enviar automáticamente a producción un código que no verificaste.

Vas a ver por qué CD tiene, de hecho, dos significados que conviene no mezclar —entrega continua (Continuous Delivery) y despliegue continuo (Continuous Deployment)—, en qué se diferencian, y por qué esta guía te enseña el CI de los tests a fondo pero solo ubica el CD sin desarrollarlo. Esta es una lección deliberadamente breve: su trabajo no es enseñarte a desplegar —eso es otro mundo, con otras guías—, sino darte un mapa claro para que sepas dónde termina lo que esta guía cubre y dónde empieza lo que no, sin confundir las dos mitades de "CI/CD".

Conexión con el módulo: esta lección cierra el marco conceptual. La 6 te dijo qué protege el CI —la rama principal verde—; esta te muestra qué pasa con esa rama verde después: el CD la toma y la envía. Es la frontera del módulo y casi de la guía: a partir de aquí, todo lo que sigue en la guía (módulos 2 a 8) es sobre el CI de los tests —el primer pipeline, la matriz, la velocidad, las puertas de cobertura, los flaky—; el CD queda nombrado y ubicado, no enseñado. El mini-proyecto de la lección 8 se queda, a propósito, del lado del CI.

La fábrica y la flota de reparto

Piénsalo así. Una fábrica de galletas tiene dos mitades muy distintas. La primera es producción con control de calidad: se amasa, se hornea, y al final de la línea un inspector revisa cada lote —¿están bien cocidas?, ¿tienen el tamaño correcto?—. Si un lote pasa la inspección, recibe el sello de "aprobado" y va al almacén. Si no, se detiene y no sale de la fábrica. Esa mitad garantiza que solo galletas buenas llegan al almacén.

La segunda mitad es logística y reparto: tomar las galletas ya aprobadas del almacén, cargarlas en camiones, y llevarlas a las tiendas. Esta mitad no revisa la calidad de la galleta —eso ya pasó—; su trabajo es mover el producto aprobado desde el almacén hasta donde el cliente lo compra. La logística confía en el sello de la inspección: reparte lo que ya fue aprobado, no lo que "quizá esté bien".

El CI es la primera mitad: producción con control de calidad. Corre la suite en cada cambio y solo deja pasar a main el código que aprueba —el sello verde de la lección 6—. El CD es la segunda mitad: la logística que toma ese código ya aprobado y lo lleva a donde tiene que correr —staging, producción—. Y fíjate en la dependencia, que es la clave: la flota de reparto solo debe cargar galletas con sello. Repartir sin inspección previa es mandar a las tiendas lotes que podrían estar crudos. Por eso el CD se apoya en el CI: primero se verifica (CI), y solo lo verificado se envía (CD). Enseñar a repartir antes de tener control de calidad sería enseñar a distribuir defectos más rápido.

CI = verificar: correr la suite en cada cambio para que solo pase código que funciona (la rama verde). CD = enviar: tomar ese código ya verificado y llevarlo al siguiente lugar (staging o producción). El CD depende del CI —no se envía lo que no se verificó—.

Los dos significados de CD

Aquí hay una sutileza que confunde a mucha gente: CD significa dos cosas distintas según a quién le preguntes, y aunque están emparentadas, no son lo mismo. Conviene tenerlas separadas para no hablar en cruzado.

CD = Entrega continua (Continuous Delivery). El pipeline, después de verificar con el CI, deja el código listo para desplegarse en cualquier momento —empaquetado, aprobado, esperando en el almacén—, pero el último paso, el envío a producción, lo dispara un humano con un clic. La entrega continua automatiza casi todo el camino, y deja la decisión final de "ahora sí, a producción" en manos de una persona. La galleta está en el camión con el motor encendido; alguien da la orden de arrancar.

CD = Despliegue continuo (Continuous Deployment). Va un paso más allá: si el CI da verde, el código se despliega a producción automáticamente, sin intervención humana. No hay clic final; el propio pipeline, tras verificar, envía. El camión arranca solo en cuanto la galleta recibe el sello. Es más automático y más exigente: requiere una confianza enorme en la suite de tests, porque cualquier cosa que los tests no atrapen va derecho a producción sin que un humano la revise.

La relación entre las tres siglas, en una escalera de automatización:

Sigla	Qué automatiza	Quién dispara el envío a producción
CI (Integración Continua)	Verificar en cada cambio	— (no despliega; solo verifica)
CD = Entrega continua	Verificar + dejar listo para desplegar	Un humano, con un clic
CD = Despliegue continuo	Verificar + desplegar	Nadie: automático si el CI da verde

Fíjate en que las tres comparten el mismo cimiento: el CI. La entrega y el despliegue continuos son extensiones que añaden pasos de envío después de que el CI verificó. Por eso "CI/CD" se escribe junto: es un continuo que empieza siempre por verificar, y donde el CD decide cuánto del camino a producción se automatiza. Sin un CI sólido, ninguna de las dos formas de CD es segura —estarías automatizando el reparto de galletas sin control de calidad—.

Por qué esta guía enseña el CI y solo ubica el CD

Una honestidad sobre el alcance, en el espíritu de la guía. Esta guía se llama "Testing en CI/CD", pero su foco real y declarado es el CI de los tests: montar el pipeline que corre tu suite en cada cambio y protege la rama verde. El CD —el despliegue a producción— se nombra para que sepas ubicarlo, pero no se enseña. Hay una razón de fondo para esa frontera, y no es pereza.

Desplegar una aplicación de verdad es un mundo con sus propios problemas, muy lejos de correr una suite de tests: hay que empaquetar la app, gestionar servidores o contenedores, manejar bases de datos y migraciones, secretos y credenciales, estrategias de despliegue sin tiempo de caída, planes de reversión si algo sale mal, monitoreo en producción. Nada de eso es testing, y meterlo aquí diluiría el foco —que es correr tus tests bien en CI—. Además, Reservo, nuestro caso, es lógica pura sin app que desplegar: no hay un servidor Reservo que mandar a producción, así que no habría ni siquiera dónde demostrar el CD honestamente.

Así que la frontera es clara y a propósito: de aquí en adelante, la guía profundiza en el CI de los tests —el módulo 2 monta el primer pipeline, el 3 cierra la brecha de entorno, el 4 prueba en varias versiones, el 5 lo acelera, el 6 le pone puertas de cobertura, el 7 maneja los flaky, y el 8 arma el pipeline completo de Reservo—. El CD queda como lo que es aquí: el paso siguiente, ubicado en el mapa, que otras guías y otros aprendizajes desarrollan cuando tengas una app real que desplegar. Saber que existe y dónde encaja es suficiente para este módulo; dominarlo es otro camino.

Ejemplo trabajado: verificar antes de enviar

La dependencia "el CD se apoya en el CI" no es solo una frase bonita: es un mecanismo concreto, y es el mismo código de salida de la lección 5. Un pipeline de CI/CD encadena la verificación y el envío de modo que el envío solo ocurre si la verificación salió con código 0. En la línea de comandos, esa regla se escribe con &&: verificar && enviar corre enviar únicamente si verificar terminó bien (exit 0). Es la cadena de montaje de la lección 5 —fail fast— aplicada a la frontera CI/CD: si el control de calidad no da el sello, la logística ni arranca.

Simulémoslo con la suite de Reservo como la etapa de verificación (CI) y un echo como el "envío" simbólico (CD). Primero, con la suite en verde:

$ python3 -m pytest && echo "CI verde (exit 0): PROCEDE el despliegue"
============================== 12 passed in 0.02s ==============================
CI verde (exit 0): PROCEDE el despliegue

Qué esperar. La suite pasó (exit 0), así que && deja correr el segundo comando: el "despliegue" procede. El sello verde autorizó el reparto. Ahora, con un test en rojo —el frágil de la lección 2 en un entorno limpio—:

$ env -u RESERVO_PRO_DISCOUNT python3 -m pytest test_env_pricing.py && echo "PROCEDE el despliegue"
============================== 1 failed in 0.03s ==============================
$ echo $?
1

El test falló (exit 1), y el segundo comando —el despliegue— nunca se ejecutó: no aparece el mensaje "PROCEDE". El && cortó la cadena en cuanto la verificación salió con código distinto de cero. Ese es, en miniatura, todo el mecanismo por el que el CD depende del CI: el envío está encadenado detrás de la verificación, y un rojo lo bloquea sin que nadie tenga que acordarse de bloquearlo. La galleta cruda no sube al camión porque el camión solo arranca si llegó el sello. En un pipeline real, ese && es la relación entre las etapas de test y las de despliegue; el principio es idéntico al que ya mediste en la lección 5.

Errores comunes

Usar "CI" y "CD" como si fueran sinónimos. Qué pasa: alguien dice "tenemos CI/CD" para decir "tenemos un pipeline", sin distinguir si ese pipeline solo verifica (CI) o también despliega (CD). Cuando hay que hablar en concreto —"¿esto se va a producción solo?"—, la confusión genera malentendidos costosos. Por qué pasa: las siglas viven pegadas y la gente las trata como una sola cosa. Cómo detectarlo: si no sabrías decir si tu pipeline despliega o solo verifica, estás mezclando las dos. Cómo corregirlo: pregúntate siempre "¿este pipeline verifica o envía?". Verificar en cada cambio es CI; enviar lo verificado a otro lugar es CD. Un pipeline puede hacer solo lo primero (muy común y perfectamente válido), o ambos.

Querer despliegue continuo sin una suite sólida. Qué pasa: un equipo, entusiasmado, configura el despliegue automático a producción (CD = despliegue continuo) pero con una suite de tests pobre, que cubre poco. El resultado es una máquina que manda bugs a producción más rápido, sin humano que los frene. Por qué pasa: el despliegue continuo suena moderno y eficiente, y es fácil olvidar que descansa por completo en la calidad de los tests. Cómo detectarlo: si estás por automatizar el envío a producción pero no confiarías tu sueldo a que la suite atrapa los bugs, no estás listo. Cómo corregirlo: el despliegue continuo es el último paso de una madurez, no el primero. Primero un CI sólido con una suite en la que de verdad confías (todo lo que enseña esta guía); solo entonces tiene sentido dejar que lo verde vaya solo a producción. La entrega continua (con un humano en el último clic) es un punto intermedio mucho más seguro para empezar.

Esperar que esta guía enseñe a desplegar. Qué pasa: alguien llega a "Testing en CI/CD" esperando aprender a mandar su app a producción, y se frustra porque la guía se queda en el CI de los tests. Por qué pasa: la "D" en el título promete despliegue. Cómo detectarlo: si buscas en esta guía cómo empaquetar y desplegar tu app, estás esperando algo que está fuera de su frontera. Cómo corregirlo: ajusta la expectativa a lo declarado —esta guía te hace experto en correr tu suite en CI, que es el cimiento sobre el que cualquier CD se apoya—. Cuando tengas una app real que desplegar y un CI sólido debajo, el despliegue es un aprendizaje aparte que construye sobre esta base. Aquí ganas el cimiento; la construcción de encima es otro proyecto.

Ejercicios

Ejercicio 1 — ¿CI o CD? Para cada acción de un pipeline, di si es CI (verificar) o CD (enviar), y por qué en una frase. (a) Correr pytest sobre el código de un PR. (b) Copiar la app aprobada a los servidores de producción. (c) Bloquear un merge a main porque un test falló. (d) Publicar una nueva versión de la app en la tienda de aplicaciones tras pasar los tests. (e) Construir el entorno limpio e instalar dependencias para correr la suite.

Ver solución

• (a) CI. Correr la suite sobre un cambio es el acto central de verificar. Integración Continua pura.
• (b) CD. Copiar la app a producción es enviar código ya aprobado a su destino. Despliegue.
• (c) CI. Bloquear el merge por un test rojo es proteger la rama verde con la verificación —el torniquete de la lección 6—. CI.
• (d) CD. Publicar la versión en la tienda es el envío del producto verificado al lugar donde el cliente lo obtiene. Despliegue (probablemente disparado tras el CI verde).
• (e) CI. Construir el entorno e instalar dependencias son las etapas 1 y 2 del pipeline de la lección 5, al servicio de correr la suite. Parte del CI.

La lección: la pregunta que clasifica siempre es "¿esto verifica o envía?". Verificar —correr tests, bloquear merges, preparar el entorno para testear— es CI. Enviar —copiar, publicar, desplegar— es CD.

Ejercicio 2 — Entrega vs despliegue. Un equipo tiene un pipeline que: (1) corre la suite en cada PR, (2) cuando se mergea a main, empaqueta la app y la deja lista en un almacén, y (3) espera a que una persona haga clic en "Desplegar" para mandarla a producción. (a) ¿Qué parte es CI y qué parte es CD? (b) ¿Es entrega continua o despliegue continuo? (c) ¿Qué cambiaría para convertirlo en el otro tipo de CD?

Ver solución

• (a) El paso (1) —correr la suite en cada PR— es CI: verificar en cada cambio. Los pasos (2) y (3) —empaquetar, dejar listo y enviar a producción— son CD: mover el código verificado hacia su destino.
• (b) Es entrega continua (Continuous Delivery). La pista es el paso (3): el envío final a producción lo dispara un humano con un clic. El pipeline automatiza casi todo, pero deja la decisión final de "ahora a producción" en manos de una persona.
• (c) Para convertirlo en despliegue continuo (Continuous Deployment), habría que quitar el clic humano del paso (3): que, en cuanto el CI da verde y la app se empaqueta, el pipeline la despliegue a producción automáticamente, sin intervención. Eso exige mucha más confianza en la suite, porque ya no hay un humano revisando antes del envío.

La lección: la única diferencia entre entrega y despliegue continuos es quién aprieta el botón final: un humano (entrega) o nadie/automático (despliegue). Las dos se apoyan igual en un CI sólido debajo.

Ejercicio 3 — Dónde termina esta guía. Un compañero dice: "ya que estamos en CI/CD, en el módulo 8 deberíamos desplegar Reservo a producción automáticamente". Explica por qué eso queda fuera de la frontera de esta guía, usando dos razones distintas de la lección.

Ver solución

Dos razones por las que desplegar Reservo queda fuera de la guía:

1. El foco declarado es el CI de los tests, no el despliegue. La guía enseña a correr tu suite en cada cambio y proteger la rama verde; el despliegue a producción (CD) es un mundo aparte —empaquetar, servidores, bases de datos, secretos, reversión, monitoreo— que no es testing y que diluiría el foco. La guía ubica el CD, no lo enseña.
2. Reservo no tiene una app que desplegar. Reservo es lógica pura sin servidor ni base de datos —a propósito, para aprender testing sin infraestructura de por medio—. No existe "el servicio Reservo" que mandar a producción, así que no habría ni dónde demostrar honestamente el despliegue. El módulo 8 arma el pipeline de CI completo de Reservo (suite, matriz, cobertura, caché), que es el capstone coherente con lo que la guía sí enseña.

(Se acepta también: el despliegue continuo exige una suite en la que confíes plenamente, y construir esa confianza es justo lo que la guía enseña primero; el despliegue viene después de dominar el CI.)

La lección: "CI/CD" en el título no promete enseñar despliegue; promete el cimiento —el CI— sobre el que cualquier CD se apoya. Saber dónde está la frontera evita esperar de la guía algo que, con toda intención, deja para otro camino.

Resumen y siguiente paso

En esta lección separaste las dos mitades de "CI/CD". El CI —que ya dominas— es verificar: correr la suite en cada cambio para que solo pase código que funciona, la rama principal verde. El CD es lo que viene después: enviar ese código ya verificado hacia su destino —staging o producción—. El CI es el control de calidad de la fábrica; el CD es la flota de reparto que solo carga lo que tiene sello. Y el CD depende del CI, porque no se envía lo que no se verificó.

Viste que CD tiene dos sentidos en una escalera de automatización: entrega continua, que deja el código listo y espera un clic humano para el envío final; y despliegue continuo, que envía a producción solo si el CI da verde, sin intervención —más automático y más exigente con la calidad de la suite—. Las tres siglas comparten el mismo cimiento, el CI, y por eso se escriben juntas. Y entendiste la frontera de la guía: aquí se enseña el CI de los tests a fondo, y el CD se ubica pero no se desarrolla, porque desplegar es otro mundo y Reservo, siendo lógica pura, no tiene app que desplegar.

Antes de avanzar deberías poder: distinguir CI de CD en una frase (verificar vs enviar); explicar por qué el CD depende del CI; diferenciar entrega continua de despliegue continuo por "quién aprieta el botón final"; y decir por qué esta guía se queda del lado del CI.

Lo que sigue es juntar todo el módulo en tus manos. En la lección 8, el mini-proyecto, vas a tomar tu propio flujo manual de testing de Reservo y mapear cada paso a la etapa del pipeline que lo automatizaría, identificando el riesgo "en mi máquina" que un entorno limpio borra —y quedando listo, con el problema y el concepto ya claros, para escribir tu primer workflow de verdad en el módulo 2—.

Recursos

• Sobre la entrega continua y el despliegue continuo — documentación de GitHub — la explicación oficial de GitHub sobre qué es el CD y cómo se apoya en el CI. Aclara la distinción entre dejar listo para desplegar y desplegar de verdad.
• Continuous Delivery — Martin Fowler — la definición de referencia de entrega continua: el código siempre listo para desplegarse, con la decisión final del envío en manos humanas. La fuente conceptual de esta lección.
• ContinuousDelivery vs ContinuousDeployment — Martin Fowler — la distinción fina entre delivery (entrega, con clic humano) y deployment (despliegue, automático) que separamos en la tabla. Léela para fijar los dos sentidos de CD.
• Sobre la integración continua — documentación de GitHub — de vuelta al cimiento: por qué el CI es la base sobre la que cualquier CD se apoya. Cierra el círculo de por qué "CI/CD" empieza siempre por verificar.