Continuous Delivery

Continuous Delivery es la prima responsable de Continuous Deployment. Cada cambio recorre el mismo pipeline automático de build, test y preparación de release (la espina dorsal de CI/CD). El artefacto que sale es enviable. Que se envíe es decisión de un humano.

Por qué la mayoría se queda en CD en vez de pasar a Continuous Deployment completo: el coste de un mal deploy es lo bastante alto como para que un humano en el loop justifique la latencia. Pasa a Continuous Deployment cuando tu monitorización, cobertura de tests e historia de rollback sean lo bastante buenas como para que el humano deje de aportar señal.

Ejemplo de elegir por servicio, no por empresa: el mismo negocio corre un sitio de marketing y un libro mayor de pagos. El sitio de marketing es un gran encaje para Continuous Deployment completo, donde un mal deploy significa una errata y un rollback es trivial, así que cada build verde puede enviarse desatendido. El libro mayor de pagos se queda en Continuous Delivery con un humano pulsando el botón, porque ahí un mal deploy mueve dinero de forma incorrecta y el humano aporta señal de verdad, no solo latencia. Tratar «¿deberíamos automatizar los deploys?» como una sola decisión para toda la empresa es el error; es un juicio de riesgo por servicio.

Hay una dimensión regulatoria que conviene nombrar. En dominios con requisitos de control de cambios o auditoría (finanzas, salud, cualquier cosa que toque datos personales bajo RGPD), el paso de aprobación humana en Continuous Delivery no es solo gestión de riesgo, es a menudo el control documentado que un auditor espera ver: quién aprobó esta release, contra qué evidencia, cuándo. Los equipos en esos contextos no deberían perseguir Continuous Deployment completo como una medalla de madurez; la puerta manual es una feature de la que depende su historia de compliance. Automatiza todo hasta el botón, luego deja el botón donde lo necesite el rastro de auditoría.

El trade-off honesto: Continuous Delivery te compra la mayor parte de la velocidad de la automatización completa manteniendo un veto humano sobre el paso irreversible, a costa de que ese veto sea un cuello de botella si el humano es lento o falta. El prerrequisito para graduarte más allá es real, no aspiracional: una suite respaldada por TDD tras la que el equipo enviará, un rollback de minutos y no de horas, y una rotación de guardia. Sin esos tres, «Continuous Delivery» es un botón que nadie se atreve a pulsar, y el pipeline es decoración sobre un SDLC por lo demás sano.