Blue-green: dos entornos, cambie el tráfico tras el deploy. Rolling: actualice instancias de una en una. Canary: envíe una fracción del tráfico a la nueva versión. Todos requieren balanceador y health checks. Planee rollback en cada paso.
Blue-green
- Setup: Dos entornos idénticos (blue y green). Uno sirve tráfico de producción; el otro está ocioso o se usa para staging. Despliegue la nueva versión en el lado ocioso.
- Cambio: Tras pruebas, apunte el balanceador (o DNS) al nuevo entorno. Rollback = apuntar de nuevo al antiguo. Rápido y simple pero requiere el doble de capacidad en el cambio.
- Cuándo usar: Cutover único y rápido y puede permitirse dos entornos completos.
Rolling
- Setup: Varias instancias detrás de un balanceador. Actualice una instancia a la vez: sáquela del pool, despliegue, health check, devuélvala. Repita para cada instancia.
- Pros: No necesita doble capacidad. Despliegue gradual; si una instancia falla en health check, las demás siguen. Funciona bien con grupos de auto-escalado e instancias inmutables.
- Contras: Versión antigua y nueva corren a la vez; asegure compatibilidad (ej. schema de BD, APIs).
- Cuándo usar: Muchas instancias y quiere evitar doble capacidad. Estándar en Kubernetes y muchos PaaS.
Canary
- Setup: Envíe una pequeña fracción del tráfico (ej. 5%) a la nueva versión. Monitore errores y latencia. Si bien, suba a 50%, luego 100%. Si mal, desvíe y haga rollback.
- Pros: Limita el radio de impacto. Validar en producción con riesgo mínimo.
- Contras: Más complejo (reglas de enrutado, métricas, automatización). Ambas versiones deben correr; compatibilidad necesaria.
- Cuándo usar: Validar en producción con riesgo mínimo. A menudo con feature flags.
Requisitos comunes
- Balanceador: Debe soportar sacar/poner instancias en rotación y (para canary) enrutado por porcentaje o header.
- Health checks: El balanceador y la orquestación deben hacer health check antes de enviar tráfico. Instancias no sanas no deben recibir tráfico; dispare rollback si fallan muchas.
- Plan de rollback: En cada paso sepa cómo hacer rollback. Pruebe en staging. Cambios de BD y schema requieren cuidado (cambios compatibles, feature flags).
Resumen
Blue-green: dos entornos, cambie el tráfico tras el deploy. Rolling: actualice instancias de una en una. Canary: envíe una fracción del tráfico a la nueva versión. Todos requieren balanceador y health checks; planee rollback en cada paso.
