introducción
blue/green despliega dos versiones de la app: una activa (blue) y otra nueva (green). el balanceador enruta tráfico a una u otra; si algo falla, vuelves a blue instantáneamente.
ventaja: cero downtime, rollback fácil y una forma segura de validar la versión nueva con tráfico real antes de convertirla en la productiva.

ambas versiones desplegadas

paso de green a blue
green recibe tráfico de forma controlada. si todo está ok, se convierte en la versión activa.

canary: mueve el % de tráfico
prueba la versión green con una pequeña fracción del tráfico antes de conmutar totalmente.
balanceador de carga (canary)
Blue (actual)
Green (candidata)
mueve el slider para redirigir una fracción del tráfico hacia green.
“ejemplo real” por etapas




beneficios
- cero downtime: el balanceador decide a qué versión enviar tráfico.
- rollback en segundos: vuelve a la versión previa (blue).
- ideal para staging con usuarios reales (canary/traffic shifting opcional).

tips prácticos
- inmutabilidad: cada release es una imagen nueva (infra + app).
- estado fuera del pod: DBs/colas gestionadas; usa migraciones backward-compatible.
- feature flags: habilita capacidades de forma gradual.
- observabilidad: compara métricas de blue vs. green antes de conmutar.