Inicio › Tecnología › Entrega Continua
La entrega continua (Continuous Delivery, CD) es una práctica de ingeniería de software en la qué cada cambio qué pasa las pruebas automatizadas queda empaquetado y listo para desplegarse a producción en cualquier momento, aunque el despliegue final pueda requerir una aprobación manual. Se apoya en un pipeline de integración continua qué compila el código, ejecuta pruebas unitarias, de integración y a veces de rendimiento, y genera un artefacto versionado, como una imagen de contenedor o un paquete instalable, almacenado en un repositorio de artefactos. Se diferencia del despliegue continuo (Continuous Deployment) en qué este último elimina también el paso de aprobación manual y despliega automáticamente cada cambio qué supera el pipeline, mientras qué la entrega continua deja esa decisión final en manos de un humano o de una ventana de despliegue programada.
Es tener el software siempre en un estado en el qué se podría publicar la nueva versión con solo pulsar un botón, porque ya ha pasado todas las pruebas automáticas. No significa qué se publique cada cambio al instante, sino qué está preparado para hacerlo cuando el equipo decida.
Un equipo qué trabaja con entrega continua puede fusionar una rama de código varias veces al día sabiendo qué el pipeline ejecutará automáticamente los tests y generará un artefacto candidato a producción; el responsable de negocio decide entonces si ese artefacto se publica el mismo día o se espera a una ventana de mantenimiento nocturna. Esto reduce el riesgo de despliegues grandes y acumulados, porque cada cambio qué llega a producción es pequeño y ya ha sido validado de forma aislada.
No exactamente: en la entrega continua el artefacto queda listo para desplegar pero alguien decide cuándo hacerlo, mientras qué en el despliegue continuo ese paso de decisión desaparece y cada cambio qué pasa el pipeline llega a producción de forma totalmente automática.
Son el requisito qué hace posible la práctica: sin una batería de tests fiable qué cubra funcionalidad crítica, el equipo no puede confiar en qué un cambio esté listo para producción sin revisión manual extensa, lo qué rompe la promesa de tener el software siempre desplegable.
Si algo falla tras un despliegue frecuente y no existe un mecanismo rápido para revertir a la versión anterior, como un despliegue blue-green o versiones etiquetadas del artefacto, la organización puede sufrir más incidentes en producción qué si desplegara con menos frecuencia pero de forma más controlada.