METODOLOGÍA

Continuous Delivery

Cada cambio se prepara automáticamente para release. Un humano sigue siendo quien pulsa el botón para enviar a producción.

Última revisión: 2026-05-24 porKevin Riedl wiki ↗

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. 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.

// FAQ

Preguntas frecuentes

Preguntas frecuentes

Delivery: cada cambio queda enviable; un humano pulsa. Deployment: cada cambio verde sale solo. Delivery es el destino estable para la mayoría; Deployment exige un nivel de tests, monitoring y rollback que pocas startups tienen, y forzarlo prematuramente solo envía bugs más rápido.
Cuando tu monitorización detecta los problemas más rápido que el humano que aprueba, y cuando el rollback es lo bastante rápido como para que un mal deploy sea molesto pero no catastrófico. Si todavía descubres regresiones por tickets de usuarios y no por alertas, el humano sigue siendo barato seguro.
El equipo debe ser dueño del pipeline, no solo del código. Feature flags pasan a ser obligatorios, los rollbacks ensayados, las migraciones de DB tienen que ser backward-compatible. La disciplina operativa cambia más que el código de aplicación.