¿Qué es Continuous Delivery (CD)?

¿Qué es Continuous Delivery (CD)?

Continuous Delivery es la práctica de ingeniería de software en la que cada cambio de código progresa automáticamente a través de pasos de build, test y validación hasta alcanzar un estado listo para producción — y puede desplegarse a producción en cualquier momento con un solo clic o comando. CD es la extensión natural de Continuous Integration (CI): CI asegura que cada commit se construye y prueba; CD asegura que cada commit que pasa también se empaqueta, despliega a staging, valida y está listo para enviarse.

La distinción crucial que cada equipo debe entender: Continuous Delivery ≠ Continuous Deployment. Continuous Delivery significa que el cambio está listo para enviarse; los humanos deciden cuándo. Continuous Deployment significa que el cambio realmente se envía automáticamente con CI verde. La mayoría de los equipos empresariales practican CD (release bajo demanda); menos practican Continuous Deployment (promoción automatizada a producción). Ambos se abrevian a "CD" causando confusión constante en entrevistas y discusiones de arquitectura.

La anatomía del pipeline CD

Un pipeline CD típico tiene estas etapas, cada una controlando la siguiente:

1. Source. Disparador en push a main / merge de PR. Hacer pull del source, calcular metadatos del commit.
2. Build. Compilar código, instalar dependencias, construir imágenes de contenedor. Cachear agresivamente (caché npm, caché de capa Docker, caché Gradle).
3. Tests unitarios. Ejecutar en paralelo; apuntar a menos de 5 minutos. Fail-fast en el primer test roto.
4. Análisis estático. Linters, verificadores de tipos, escáneres de seguridad (Snyk, Dependabot, SonarQube).
5. Tests de integración. Levantar dependencias (bases de datos, servicios mock), ejecutar suite de integración. 5-15 minutos típico.
6. Creación de artefacto. Construir imagen de contenedor, firmarla, empujarla al registro. O construir binarios/paquetes estáticos.
7. Deploy a staging. Auto-deploy a un entorno staging que refleje producción.
8. Smoke tests / E2E. Validación de ruta crítica contra staging. Algunos equipos ejecutan también una prueba de carga aquí.
9. Gate de producción. Aprobación manual (CD) o promoción automática (Continuous Deployment).
10. Deploy de producción. Blue/green, canary o despliegue rolling. Monitorear métricas post-deploy.
11. Validación post-deploy. Smoke tests en producción. Auto-rollback en regresión.

Las cuatro estrategias de despliegue que CD habilita

• Blue/green. Desplegar nueva versión ("green") junto a la vieja ("blue"); cambiar tráfico instantáneamente. Rollback fácil (volver a cambiar). Duplica la infraestructura durante la transición.
• Canary. Desplegar a un % pequeño del tráfico primero (1-5%); monitorear; aumentar gradualmente. Atrapa regresiones antes del rollout completo. Predeterminado de la industria para sistemas de alto tráfico.
• Rolling. Reemplazar instancias una a la vez. No se necesita lógica de división de tráfico; rollout más lento. Predeterminado en Kubernetes y la mayoría de servicios gestionados de plataformas cloud.
• Feature flags / dark launching. Desplegar código en oscuro, habilitar por usuario/cohorte vía servicio de flags. Desacopla deploy de release. Ver feature flags.

Lo que hace que CD funcione en la práctica

Patrones que comparten los pipelines CD maduros:

• Desarrollo basado en trunk. Ramas de corta duración (1-2 días máx) fusionadas a main. Sin ramas de feature de larga duración que diverjan durante semanas.
• Tests automatizados completos. Si no puedes confiar en tu suite de tests, no puedes confiar en CD. Apunta a 80%+ de cobertura de ruta crítica.
• Artefactos inmutables. El mismo artefacto se despliega a staging y producción. Sin rebuilds entre entornos — demasiado arriesgado.
• Configuración externalizada. Config por entorno en variables de entorno / servicio de config, no horneada en imágenes.
• Disciplina de migración de base de datos. Las migraciones son compatibles hacia adelante; el código viejo sigue funcionando con el nuevo esquema durante al menos un ciclo de deploy (patrón expand-contract).
• Observabilidad. Métricas, logs, traces en producción. Auto-rollback se dispara en regresión de tasa de error / latencia.
• Pipeline rápido. Los deploys toman <15 minutos. Pipelines lentos significan menos releases más grandes — exactamente el modo de fallo que CD pretende prevenir.

Herramientas comunes de pipeline CD

• GitHub Actions — dominante para proyectos en GitHub. Ecosistema marketplace; YAML .github/workflows.
• GitLab CI/CD — primera clase para GitLab. .gitlab-ci.yml; registro de contenedores integrado.
• CircleCI, Buildkite, Jenkins — servicios CI de terceros. Jenkins es legacy pero ubicuo en empresas.
• Argo CD, Flux — controladores GitOps para Kubernetes. Deploys basados en pull sincronizados desde Git.
• Spinnaker, Harness, Octopus — plataformas completas de orquestación de despliegue. Multi-cloud, pipelines complejos.
• AWS CodePipeline, Azure Pipelines, Google Cloud Build — pipelines nativos de proveedor cloud.

Anti-patrones comunes de CD

• El "gate manual para siempre". El pipeline CD termina en staging porque nadie confía en los deploys a producción. O arregla el problema de confianza (mejores tests, observabilidad, rollback) o admite que no tienes CD.
• Entornos basados en ramas. Código diferente en staging vs. producción ("esta rama despliega a staging"). El drift se acumula; staging pasa pero producción falla. Envía solo desde main.
• Deploys que requieren coordinación fuera de banda. Alguien tiene que actualizar un archivo de config en otro repo; otro equipo tiene que rebotar un servicio. CD no sobrevive esto.
• Tests de integración exhaustivos en producción. Los smoke tests deberían ser baratos y rápidos. Si tu validación post-deploy toma 30 minutos, los deploys se acumulan.
• Sin simulacro de rollback. La primera vez que ejercitas la ruta de rollback es durante una caída real. Practica rollbacks regularmente.
• Tests CI pasando pero no ejecutándose en el artefacto de deploy. Fácil hacer drift entre lo que prueba CI y lo que se envía. Construye una vez, prueba el artefacto, despliega el artefacto — los mismos bytes en todo.

FAQ: Continuous Delivery

¿Cuál es la diferencia entre CI, CD y Continuous Deployment?

CI (Continuous Integration): cada commit construye + prueba. CD (Continuous Delivery): cada commit también alcanza un estado desplegable, listo para enviarse bajo demanda. Continuous Deployment: cada commit que pasa auto-envía a producción. CD es necesario para Continuous Deployment pero no es lo mismo.

¿Necesito Kubernetes para CD?

No. CD funciona con VMs, contenedores, serverless, incluso PHP desplegado por FTP. Kubernetes hace algunos patrones más fáciles (rolling updates) pero no es requerido.

¿Cuánto debe tomar un pipeline CD?

Benchmarks de la industria (DORA, Accelerate): los equipos elite despliegan en <1 hora desde el commit. Equipos de alto rendimiento: 1-24 horas. Pipelines >24 horas indican problemas con infraestructura de tests, dependencias o complejidad organizacional.

¿Puede funcionar CD en industrias reguladas?

Sí — fintech, salud, gobierno todos ejecutan CD. El pipeline CD se convierte en el rastro auditable (cada cambio se construye, prueba, firma, despliega vía pasos reproducibles con logs completos). A menudo más auditable que procesos de deploy manuales.

¿Qué hay sobre los cambios de base de datos?

La parte más difícil. Usa migraciones expand-contract (añadir nueva columna → desplegar código que escribe a ambas → migrar datos viejos → desplegar código que lee la nueva columna → eliminar columna vieja), feature flags y herramientas como Flyway o Liquibase para versionar migraciones junto al código.

¿Cómo mido la calidad del pipeline CD?

Las cuatro métricas clave de DORA: frecuencia de despliegue, tiempo de plomo para cambios, tasa de fallo de cambios, tiempo medio de restauración. Rastrea estas a lo largo del tiempo. Más rápido + más seguro = mejor CD.

¿Qué hay sobre microservicios CD?

Cada servicio tiene su propio pipeline; los deploys son independientes. Coordina cambios de API rompedores vía expand-contract o versionado. Evita monolitos distribuidos donde N servicios deben desplegarse juntos.

Cómo se relaciona LoadFocus con los pipelines CD

El paso más-saltado en los pipelines CD es la validación de rendimiento. Los tests funcionales pasan; la latencia regresa 50% en el tráfico de producción. Las pruebas de carga de API LoadFocus se integran en pipelines CI/CD vía llamadas API — falla el build si la latencia p95 excede tu umbral. La monitorización sintética valida que los Core Web Vitals se mantienen saludables después de cada deploy, atrapando regresiones de frontend antes de que los usuarios noten.