¿Qué es Continuous Delivery (CD)?

Continuous Delivery mantiene el software listo para lanzar en cualquier momento con un pipeline automático. Diferencia con Continuous Deployment y carga.

¿Qué es Continuous Delivery (CD)?

Continuous Delivery (entrega continua) es una disciplina de desarrollo de software en la que cada cambio se compila, prueba y promueve de forma automática, de modo que el software pueda pasar a producción en cualquier momento. Martin Fowler lo define así: el software "can be released to production at any time". Si se lanza y cuándo sigue siendo una decisión de las personas o del negocio. La práctica se apoya en la integración continua y suele usar un pipeline de despliegue.

Continuous Delivery frente a Continuous Deployment

Ambos se abrevian como "CD", y de ahí la confusión. La distinción de Fowler: en Continuous Deployment cada cambio que pasa por el pipeline se pone en producción automáticamente. Con Continuous Delivery podrías desplegar a menudo, pero puedes decidir no hacerlo, por ejemplo porque el negocio prefiere un ritmo de lanzamientos más lento. Continuous Deployment es, por tanto, Continuous Delivery más un último paso automático. A la inversa no se cumple.

Cómo funciona un pipeline de entrega

Un cambio avanza por etapas, y un fallo en cualquiera lo detiene:

  1. Commit y build. Un merge a la rama principal dispara una compilación que genera un único artefacto, por ejemplo una imagen de contenedor.
  2. Pruebas rápidas. Las pruebas unitarias y los análisis estáticos dan respuesta en minutos.
  3. Despliegue en un entorno similar a producción. Se promueve el mismo artefacto, nunca se recompila, para que lo que se probó sea lo que se lanza.
  4. Comprobaciones más lentas. Aquí se ejecutan pruebas de integración, de extremo a extremo y de regresión, y también una prueba de carga.
  5. Lanzamiento. Lo pulsa una persona (delivery) o lo hace el pipeline (deployment).

Dos técnicas hacen más seguros los lanzamientos frecuentes: los feature flags separan el despliegue del código de la activación de una función, y un despliegue gradual limita cuántos usuarios ven primero un cambio.

Ejemplo

Un equipo hace merge de una pull request a las 10:00. A las 10:15 el pipeline ha construido una imagen, ha pasado las pruebas unitarias y la ha desplegado en staging, donde también pasan la suite de extremo a extremo y una prueba de carga corta. La versión queda marcada como lanzable. El responsable de producto espera al anuncio de marketing y la lanza el jueves con un clic. Si el pipeline la hubiera lanzado a las 10:15 sin ese paso, sería Continuous Deployment.

Errores frecuentes

  • Llamar "CD" al servidor de builds. Sin pruebas automáticas ni un paso de lanzamiento repetible, el software no es lanzable a demanda.
  • Recompilar por entorno. Un artefacto distinto en producción y en staging anula el sentido del pipeline.
  • Ramas de larga vida. Integrar poco a poco hace que cada lanzamiento sea grande y arriesgado.
  • Preparar los entornos a mano. Un staging que se desvía de producción esconde problemas hasta el día del lanzamiento. La infraestructura como código ayuda.
  • Olvidar el rendimiento. Las pruebas funcionales pasan mientras un cambio hace la aplicación lenta bajo carga.

Continuous Delivery, pruebas de carga y monitorización

Una versión lanzable debería también aguantar el tráfico. La página de pruebas de carga de LoadFocus describe una GitHub Action que ejecuta una prueba de carga, lee el veredicto de aprobado o suspenso y puede bloquear un despliegue si se supera un umbral. Tras el lanzamiento, la monitorización de APIs indica si producción se comporta como predijo el pipeline. Para consejos prácticos sobre pipelines, consulta nuestras buenas prácticas de CI/CD (en inglés) y la guía de despliegues canary (en inglés).

Preguntas frecuentes

¿Continuous Delivery es lo mismo que Continuous Deployment?

No. Continuous Delivery mantiene cada cambio en estado lanzable y deja la decisión de lanzar a las personas. Continuous Deployment lanza automáticamente cada cambio que supera el pipeline.

¿Necesito integración continua antes?

En la práctica, sí. Continuous Delivery se apoya en la integración continua: los cambios deben integrarse y probarse con frecuencia antes de avanzar por las etapas siguientes.

¿Continuous Delivery significa lanzar varias veces al día?

No. Significa que puedes lanzar en cualquier momento. Con qué frecuencia lo hagas es una decisión de negocio.

¿Dónde encajan las pruebas de carga en el pipeline?

Tras desplegar en un entorno similar a producción, como una de las comprobaciones más lentas. Un umbral de tiempo de respuesta o de tasa de errores puede hacer fallar la compilación antes del lanzamiento.

¿Qué tan rápido es tu sitio web?

Mejora su velocidad y SEO sin problemas con nuestra Prueba de Velocidad gratuita.

Prueba de velocidad de sitio web gratis

Analice la velocidad de carga de su sitio web y mejore su rendimiento con nuestro comprobador de velocidad de página gratuito.