Si has llegado hasta aquí es porque en algún momento has vivido —o te han contado— una escena parecida a esta: viernes por la tarde, alguien compila el proyecto en su portátil, sube los ficheros a un servidor y cruza los dedos. Esta lección es el punto de partida para dejar atrás esa escena. Vamos a definir con precisión qué significan las siglas CI/CD, a distinguir las tres prácticas que se esconden detrás de ellas (porque son tres, no dos) y a fijar el vocabulario que usaremos durante todo el curso. No es una lección de herramientas ni de configuración: es la lección que hace que todo lo demás tenga sentido. Si confundes Entrega Continua con Despliegue Continuo —el error más habitual del sector—, el resto del curso te sonará a ruido. Cuando termines, sabrás nombrar cada pieza del proceso y entenderás por qué el equipo de nuestro proyecto de ejemplo, Reservalia, tiene un problema serio.

1. El problema que CI/CD viene a resolver
2. Qué es la Integración Continua (CI)
3. Qué es la Entrega Continua (Continuous Delivery)
4. Qué es el Despliegue Continuo (Continuous Deployment)
5. Las dos "CD" cara a cara
6. El flujo completo: de commit a producción
7. Vocabulario base del curso
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Durante todo el curso trabajaremos sobre un proyecto ficticio llamado Reservalia, una plataforma SaaS de reservas de cita para pequeños negocios: peluquerías, clínicas dentales, talleres mecánicos. El equipo es pequeño: Marta (tech lead), Diego (desarrollador backend) y Nuria (SRE). En la lección 01-04 lo veremos en detalle; de momento solo nos interesa cómo trabajan hoy:

• Diego compila en su portátil. La versión de Node que tiene instalada no es exactamente la del servidor.
• Sube los ficheros resultantes por SFTP a un único servidor de producción.
• Ejecuta las migraciones de base de datos a mano, pegando SQL en una consola de psql.
• Las pruebas se ejecutan "cuando alguien se acuerda".
• Todo esto ocurre los viernes por la tarde y dura unas 3 horas.
• Resultado: dos incidencias graves en producción el último trimestre.

Este proceso no es "malo" por descuido: es malo por diseño. Cada uno de esos pasos depende de que una persona concreta, en un momento concreto, no se equivoque. Y las personas nos equivocamos.

Hay un segundo problema, menos visible pero igual de caro. Imagina que Marta y Diego trabajan cada uno en su rama durante dos semanas:

• Marta reescribe el sistema de notificaciones por correo.
• Diego cambia el modelo de datos de las citas para soportar reservas recurrentes.

Ninguno de los dos toca el trabajo del otro aparentemente. Pero el día que intentan fusionar ambas ramas, aparecen conflictos en 40 ficheros, la firma de una función que ambos usan ha cambiado, y las pruebas de Marta fallan por un cambio de esquema de Diego. Lo que debería haber sido una tarde se convierte en tres días de "resolver la integración".

Eso es el integration hell (infierno de la integración): el coste de fusionar aumenta de forma no lineal con el tiempo que las ramas viven separadas.

La intuición clave, que se repetirá en todo el curso: si algo duele, hazlo más a menudo. Fusionar duele porque lo haces poco. Desplegar duele porque lo haces poco. La respuesta contraintuitiva de CI/CD es aumentar la frecuencia hasta que cada operación individual sea trivial.

Definición. La Integración Continua es la práctica de que cada miembro del equipo integre su trabajo en la línea principal de desarrollo al menos una vez al día, y de que cada integración sea verificada automáticamente por un proceso de construcción y pruebas que se ejecuta en un entorno limpio y compartido.

Hay tres ideas dentro de esa definición, y las tres son igual de importantes:

1. Integrar a menudo. El código de cada persona vuelve a la rama principal en horas, no en semanas. Si tu rama vive tres semanas, no estás haciendo CI aunque tengas un servidor de CI configurado.
2. Verificar automáticamente. No basta con fusionar: un sistema automático compila, ejecuta las pruebas y comprueba la calidad. Sin verificación automática, integrar a menudo solo significa romper la rama principal más a menudo.
3. En un entorno limpio y compartido. No en el portátil de Diego. En una máquina que parte de cero cada vez, para que "en mi máquina funciona" deje de ser una frase válida.

Conviene desactivar tres malentendidos muy extendidos:

Cuando un equipo adopta CI de verdad, firma un contrato tácito:

• La rama principal siempre está sana. Si la build está roja, arreglarla es la prioridad número uno del equipo, por encima de cualquier funcionalidad.
• Nadie se va a casa con la build rota. Se revierte el cambio y se investiga con calma al día siguiente.
• Cada cambio se verifica antes de integrarse, no después.

Sin ese contrato, la automatización se convierte en un semáforo que todo el mundo ignora. Volveremos sobre esto en el módulo 2.

Definición. La Entrega Continua es la práctica de mantener el software siempre en un estado desplegable, de manera que cualquier versión que haya pasado el pipeline pueda llevarse a producción pulsando un botón, en cualquier momento, con un riesgo conocido.

La Entrega Continua da por supuesta la Integración Continua y añade una capa por encima: no basta con que el código compile y pase los tests; hace falta que exista un artefacto construido, versionado, probado en entornos parecidos a producción y listo para desplegarse.

La frase clave es "pulsando un botón". En Entrega Continua:

• El proceso técnico de desplegar está completamente automatizado.
• La decisión de desplegar sigue siendo humana.

Esa decisión humana no es un fallo del sistema: es una elección deliberada. Puede haber razones perfectamente legítimas para no desplegar automáticamente:

• Una campaña de marketing que arranca el martes y la funcionalidad no debe verse antes.
• Un requisito de cumplimiento normativo que exige aprobación registrada.
• Un equipo que aún no confía lo suficiente en su suite de pruebas.

Lo importante es que, cuando alguien decide desplegar, no hay trabajo manual que hacer: solo autorizar.

Definición. El Despliegue Continuo es la práctica de que todo cambio que supera el pipeline automatizado se despliegue en producción automáticamente, sin intervención humana.

Es la Entrega Continua sin el botón. Se elimina la puerta manual: si el pipeline está verde, el cambio llega a los usuarios. Sin reuniones, sin ventanas de despliegue, sin viernes por la tarde.

Esto suena temerario y, sin una base sólida, lo es. El Despliegue Continuo solo funciona si se apoya en:

• Una suite de pruebas en la que el equipo confía de verdad (módulo 2).
• Estrategias de despliegue progresivo —canary, blue-green— para limitar el radio de impacto (módulo 3).
• Feature flags para separar "desplegar código" de "activar funcionalidad" (módulo 3).
• Rollback automático cuando las métricas se degradan (módulo 3).
• Monitorización que detecte el problema antes que el cliente (módulo 3).

Fíjate en algo importante: el Despliegue Continuo no es el objetivo obligatorio de todo equipo. Es una opción. Muchísimas organizaciones excelentes se quedan deliberadamente en Entrega Continua. Lo que sí es innegociable es la capacidad de desplegar en cualquier momento; usarla automáticamente o no es una decisión de contexto.

Aquí está el núcleo de la lección. Las siglas CI/CD son ambiguas a propósito y eso genera confusión constante en entrevistas, documentación y conversaciones de equipo.

Una forma de recordarlo que funciona muy bien:

• Delivery = "podemos desplegar cuando queramos" → la capacidad está automatizada, la decisión es humana.
• Deployment = "desplegamos siempre que el pipeline lo permite" → también la decisión está automatizada.

Y una relación de inclusión que conviene tener grabada:

Se lee de abajo arriba: no puede haber Despliegue Continuo sin Entrega Continua, ni Entrega Continua sin Integración Continua. Cualquier intento de saltarse un escalón produce un sistema frágil. Si Reservalia intentara mañana desplegar automáticamente a producción sin pruebas fiables, no tendría dos incidencias por trimestre: tendría dos por semana.

Veamos el recorrido que hará un cambio de Diego a lo largo de todo el curso. Este diagrama es el mapa mental del curso entero:

Lee el diagrama identificando dónde encaja cada práctica:

• De A a E (commit → build → test): esto es Integración Continua. Lo construiremos en el módulo 2.
• De F a I (artefacto → registro → dev → staging): esto es Entrega Continua. Módulos 2 y 3.
• El paso J → L sin intervención humana: esto es Despliegue Continuo. Módulo 3.
• M y N (monitorización y rollback): la red de seguridad que hace posible lo anterior. Módulo 3.

Fijemos ahora los términos. Los usaremos sin volver a definirlos, así que merece la pena leer esta sección con calma. Los agrupo por familias.

Un detalle que usaremos mucho: el SHA del commit es la identidad canónica de un cambio. Cuando en el módulo 3 nos preguntemos "¿qué versión exacta hay en producción?", la respuesta correcta nunca será "la última", sino un SHA concreto.

La jerarquía, visualmente:

Sobre los runners hay una distinción que importará mucho más adelante:

• Efímero: se crea limpio para cada job y se destruye al terminar. Garantiza reproducibilidad. Es el modelo por defecto de GitHub Actions.
• Persistente: una máquina que se reutiliza entre ejecuciones. Es más rápido (conserva cachés) pero acumula estado, y ese estado es una fuente clásica de builds que "funcionan solo la segunda vez". Típico de instalaciones antiguas de Jenkins.

Los dos últimos merecen desarrollo, porque son los que más se malinterpretan.

Promoción: construir una vez, desplegar muchas. Es una de las reglas de oro de CI/CD. El artefacto que se prueba en staging debe ser el mismísimo binario que llega a producción, byte a byte. Si reconstruyes para producción, estás desplegando algo que nadie ha probado nunca.

Y lo que no hay que hacer:

Si el artefacto es el mismo en los tres entornos, ¿cómo cambia entonces la configuración? Por fuera: variables de entorno y secretos inyectados en el momento del despliegue. El artefacto no sabe en qué entorno vive.

Build reproducible. Que dos construcciones del mismo commit den el mismo resultado no es automático: hay que ganárselo. Los enemigos habituales son:

• Versiones de herramientas no fijadas (node a secas en vez de [email protected]).
• Dependencias sin fichero de bloqueo, que resuelven a la última versión disponible.
• Instalar con npm install (que puede modificar el lock) en vez de npm ci (que lo respeta estrictamente).
• Marcas de tiempo o rutas absolutas incrustadas en el artefacto.

Este es exactamente el problema de Diego: compila en su portátil, con su versión de Node y sus node_modules acumulados durante meses. Su build no es reproducible, y por eso nadie puede reconstruir lo que hay en producción.

Error 1: creer que "CD" siempre significa lo mismo. Cuando alguien dice "tenemos CI/CD", pregunta siempre: "¿el despliegue a producción lo lanza una persona o el pipeline?". Es la única pregunta que desambigua. En una entrevista de trabajo, distinguir Delivery de Deployment y explicar por qué se elige una u otra te sitúa por delante de la mayoría de candidatos.

Error 2: pensar que CI/CD es una herramienta que se instala. GitHub Actions no te da Integración Continua, igual que comprar unas zapatillas no te da forma física. La herramienta ejecuta; la práctica la sostiene el equipo. Un equipo con ramas de tres semanas y un servidor de CI carísimo no hace CI.

Error 3: reconstruir el artefacto en cada entorno. Si el deploy a producción vuelve a compilar, lo que llega a los usuarios no es lo que se validó en staging. Construye una vez, promociona el mismo artefacto. Lo formalizaremos en la lección 02-06.

Error 4: confundir despliegue con release. Desplegar es poner el código en producción; hacer release es activar la funcionalidad para los usuarios. Con feature flags puedes desplegar el lunes y activar el jueves. Son dos operaciones distintas y separarlas reduce muchísimo el riesgo. Lo veremos en 03-05.

Error 5: usar ramas de larga duración y llamarlo CI. Si tu rama tiene 60 commits y dos semanas de vida, integrarás mal aunque tengas mil tests verdes. La frecuencia de integración es la práctica; los tests son el mecanismo.

Consejo 1: empieza midiendo, no automatizando. Antes de escribir tu primer workflow, apunta cuánto tarda hoy tu despliegue y cuántas veces al mes falla. Sin línea base no podrás demostrar que la inversión ha valido la pena. La lección 01-05 va justo de esto.

Consejo 2: el pipeline es código de producción. Vive en el repositorio, se revisa en pull requests y se versiona igual que el resto. Un .github/workflows/ci.yml editado a mano desde una interfaz web es deuda técnica desde el minuto uno.

Consejo 3: si duele, hazlo más a menudo. Es el principio que resume el curso entero. Los merges duelen porque son raros; los despliegues dan miedo porque son excepcionales. Aumentar la frecuencia obliga a automatizar, y automatizar elimina el dolor.

Para cada situación, indica si describe Integración Continua, Entrega Continua, Despliegue Continuo o ninguna de las tres, y justifica en una frase.

1. El equipo tiene un servidor que ejecuta las pruebas cada noche a las 3:00 sobre la rama main. Las ramas de funcionalidad se fusionan cada tres semanas.
2. Cada pull request dispara build y tests en 6 minutos. Si están verdes, se puede fusionar. Los despliegues siguen siendo manuales por SFTP.
3. Al fusionar a main, el pipeline construye una imagen Docker, la despliega en staging y ejecuta pruebas de humo. Marta pulsa "Deploy to production" cuando lo considera oportuno.
4. Al fusionar a main, el pipeline despliega a producción en un 5 % del tráfico, vigila los errores 10 minutos y, si todo va bien, completa el despliegue. Nadie interviene.
5. Diego compila en su portátil y sube por SFTP los viernes.

El siguiente pseudo-script es el proceso manual de Diego. Identifica al menos cuatro motivos por los que el artefacto resultante no es reproducible, y propón una corrección para cada uno.

Escribe un diagrama mermaid del pipeline objetivo de Reservalia con estas condiciones, usando correctamente los términos trigger, etapa, job, artefacto, entorno y promoción:

• Se dispara al fusionar a main.
• Etapa de verificación con dos jobs en paralelo: test-api y test-web.
• Si ambos pasan, se construye un artefacto etiquetado con el SHA del commit.
• El artefacto se despliega en staging automáticamente.
• Se promociona a prod solo tras aprobación manual de Marta.

Solución al Ejercicio 1

1. Ninguna de las tres. Es una nightly build. Hay automatización de pruebas, pero las ramas viven tres semanas: no hay integración continua, sino integración tardía verificada de noche. La verificación llega hasta 21 días después del cambio que la rompió.
2. Integración Continua. Cada cambio se verifica automáticamente antes de integrarse y el ciclo de feedback es de minutos. No hay Entrega Continua porque no existe un artefacto desplegable ni despliegue automatizado: el despliegue sigue siendo un proceso manual.
3. Entrega Continua. Todo el camino técnico hasta producción está automatizado (build, artefacto, staging, pruebas de humo) y solo queda una puerta manual: la decisión de Marta. Es el ejemplo canónico de Delivery.
4. Despliegue Continuo. No hay intervención humana entre el merge y producción. Además aparece la red de seguridad imprescindible: despliegue progresivo (canary al 5 %) y verificación automática antes de completar.
5. Ninguna de las tres. Es despliegue manual con integración tardía. Es el punto de partida de Reservalia.

Solución al Ejercicio 2

Con cuatro habría bastado; si has encontrado más, mejor señal aún.

Solución al Ejercicio 3

Puntos que debían aparecer y conviene comprobar en tu versión:

• El trigger es un evento del repositorio, no una acción manual.
• test-api y test-web son jobs paralelos dentro de una misma etapa, no etapas distintas.
• Se construye un único artefacto, etiquetado con el SHA (no con la fecha ni con "latest").
• A producción va el mismo artefacto que se validó en staging: eso es promoción, no una reconstrucción.
• La puerta manual sitúa este pipeline en Entrega Continua. Quitando esa puerta, sería Despliegue Continuo.

En esta lección hemos puesto los cimientos del curso:

• El enemigo tiene dos caras: el integration hell (fusionar tarde y de golpe) y el despliegue manual (procesos que dependen de que una persona no se equivoque). Reservalia sufre las dos.
• La Integración Continua es integrar a menudo y verificar automáticamente en un entorno limpio. Es una práctica de equipo antes que una herramienta.
• La Entrega Continua mantiene el software siempre desplegable: el proceso está automatizado y la decisión es humana.
• El Despliegue Continuo elimina esa última puerta manual, y solo es sensato con pruebas fiables, despliegue progresivo, monitorización y rollback.
• Las tres se apilan: no hay Deployment sin Delivery, ni Delivery sin CI.
• Y tenemos un vocabulario común: repositorio, commit, rama, trigger, pipeline, etapa, job, runner, artefacto, entorno, promoción y build reproducible. Dos reglas de oro que repetiremos hasta el final: construir una vez y promocionar el mismo artefacto, y fijar versiones para que la build sea reproducible.

Ahora ya sabes qué es CI/CD. La pregunta lógica de Marta cuando le presente esto a su equipo será otra: "¿y esto qué nos aporta, y qué nos va a costar?". Porque montar un pipeline no es gratis: consume tiempo de configuración, mantenimiento y minutos de ejecución. En la siguiente lección, Beneficios de CI/CD, veremos con honestidad las dos columnas de la balanza: qué gana un equipo como el de Reservalia, cómo se mide cada beneficio y en qué situaciones CI/CD aporta menos de lo que cuesta.