CI/CD: las dos des que no significan lo mismo

Las siglas engañan. CI es una sola práctica; CD son dos, y la diferencia entre ellas no es de madurez técnica sino de quién asume el riesgo. Delivery deja el código listo y hace que una persona pulse el botón. Deployment quita a la persona. Elegir entre las dos no es un problema de herramientas: es decidir si tus tests son la última defensa o si todavía hay un humano detrás de ellos.

01 — Las tres columnas

Qué automatiza cada letra

	CI	CD · Delivery	CD · Deployment
Pregunta que responde	¿Se integra sin romper nada?	¿Está listo para salir?	— sale
Automatiza	Build, test, lint	+ despliegue a staging	+ despliegue a producción
Intervención humana	Ninguna	Sí: aprobar el paso a producción	Ninguna
Qué exige	Que existan tests	Un staging que se parezca a producción	Tests sólidos y monitorización

La confusión habitual es tratar Deployment como la versión avanzada de Delivery, y no lo es necesariamente. Una empresa regulada puede tener un pipeline impecable y elegir Delivery para siempre, porque el gate manual es un requisito legal, no una carencia. El eje no es «cuánto sabemos», es «quién responde si esto sale mal».

02 — El esqueleto

Las cinco etapas que tiene cualquier pipeline

01Trigger Push, pull request, o programado

02Build Dependencias, compilación, artefactos

03Test Unitarios, integración, análisis estático

04Deploy Staging, y producción si es CD

05Notify Estado en el PR, aviso al equipo

Las cinco están en todos los pipelines del mundo. Lo que separa un pipeline de juguete de uno serio no es cuántas etapas tiene, sino qué pasa cuando la tercera falla: si el merge sigue siendo posible con los tests en rojo, el pipeline no protege nada — informa.

// automatizar la señal y no hacerla vinculante es la mitad del trabajo, y es la mitad barata

03 — El caso contrario

Cuándo CI/CD no aporta todavía

Situación	Por qué
No hay tests automatizados	CI sin tests solo verifica que compila
Proyecto de una persona sin usuarios	El coste de configuración supera el beneficio
Librería interna sin versionar	CD no aplica: no hay nada que desplegar
Primeras dos semanas de un proyecto	La arquitectura todavía se mueve demasiado

La primera fila es la importante y la que más se ignora. Un check verde no dice que el código funcione: dice que el proceso terminó sin errores. Si la suite tiene tres tests triviales, ese verde certifica exactamente tres cosas — y da una sensación de seguridad proporcional al color, no a la cobertura.

04 — Cómo se mide

Las cuatro métricas DORA

Métrica	Qué mide	Eje
Deployment Frequency	Cada cuánto llega algo a producción	Velocidad
Lead Time for Changes	Cuánto tarda un commit en llegar a producción	Velocidad
Change Failure Rate	Qué porcentaje de despliegues causa un problema	Estabilidad
Time to Restore Service	Cuánto se tarda en arreglarlo	Estabilidad

Van en dos pares por diseño, y ahí está su gracia: impiden hacer trampa. Se puede desplegar veinte veces al día si da igual romper cosas, y se puede no romper nada nunca con no desplegar. Cualquiera de las cuatro sola se puede optimizar sacrificando otra; las cuatro juntas, no.

Auditoría La guía abre citando que los equipos con CI/CD «despliegan 208 veces más frecuentemente y se recuperan 106 veces más rápido», atribuido a DORA sin año ni informe. ¿De qué edición salen esas dos cifras? ¿Y por qué un múltiplo de tres dígitos, si lo que DORA publica habitualmente son rangos por grupo de rendimiento y no un factor único frente a «los equipos sin estas prácticas»? Antes de repetirla en una entrevista conviene localizar el informe concreto: una cifra citada sin fuente es más frágil que no citar ninguna, porque invita justamente a la pregunta que no puedes responder.

Para hacer

Situar un repositorio tuyo en la escalera

Coge un repositorio real y responde tres preguntas en este orden: ¿tiene CI? ¿ese CI corre tests de verdad, o solo comprueba que las dependencias instalan? ¿un PR con los tests en rojo se puede mergear igualmente?

La tercera es la que decide en qué escalón estás. Las dos primeras dan falso positivo con mucha facilidad — y si la respuesta a la tercera es «sí, se puede mergear», ya sabes cuál es el siguiente commit que tienes que hacer, y no es de código.