HEROCTL

Rolling, canary, blue-green y rainbow

Cuatro estrategias de deploy. Cuándo usar cada una, con ejemplos completos y trade-offs honestos.

Deploy·12 min·última revisión 2026-04-26

Toda actualización cambia código en producción. La diferencia entre las 4 estrategias está en cuánto tráfico ve código nuevo, por cuánto tiempo, y qué tan rápido vuelves atrás si algo se rompe.

Comparación rápida

EstrategiaRiesgoCostoVelocidadCuándo usar
Rollingmedio1xmedio90% de los casos
Canarybajo1xlentocambio arriesgado con métricas claras
Blue-greenbajo2xrápidoel rollback debe ser instantáneo
RainbowbajoNxmediomúltiples versiones coexistiendo (B2B)

No existe "la mejor estrategia". Existe la estrategia correcta para cada cambio.

Rolling

La estrategia por defecto. Sustituye réplicas una a la vez (o en pequeños lotes), esperando que cada nueva quede saludable antes de tocar la próxima.

Cómo funciona

Imagina 4 réplicas corriendo v1. Rolling con max_parallel: 1:

  1. Mata 1 réplica v1, sube 1 v2. Espera saludable.
  2. Mata 1 v1 más, sube 1 v2. Espera saludable.
  3. Repite hasta que las 4 sean v2.

En cualquier momento, hay mezcla de v1 y v2 sirviendo. Para cambios retro-compatibles, ok. Para cambios de schema o contrato de API, peligroso.

Spec YAML

job: api-vendas
tasks:
  - name: web
    image: minhaempresa/api-vendas:1.5.0
    count: 4
    update:
      strategy: rolling
      max_parallel: 1
      min_healthy_time: 30s
      healthy_deadline: 300s
      auto_revert: true

Parámetros importantes:

  • max_parallel — cuántas cambiar al mismo tiempo. 1 es más lento y más seguro.
  • min_healthy_time — cuánto tiempo la nueva debe quedar saludable antes de avanzar. 30s atrapa la mayoría de los crashes tardíos.
  • healthy_deadline — después de eso, considera falla.
  • auto_revert — vuelve solo si falla.

Trade-offs

Costo extra cero. La ventana de mezcla entre versiones es el punto débil. Si v2 tiene bug que solo aparece con tráfego real, parte de los usuarios sufre antes del rollback.

Nota: rolling es la elección correcta cuando tus cambios son pequeños, retro-compatibles y la app soporta versiones diferentes activas al mismo tiempo.

Canary

En lugar de cambiar réplicas, inyecta una cantidad pequeña de nuevas y direcciona una porción del tráfico a ellas. Observas métricas. Si todo bien, aumenta la porción. Si las métricas se degradan, revierte.

Cómo funciona

Con count: 10 y canary configurado para 5% / 25% / 50% / 100%:

  1. Sube 1 réplica v2 al lado de las 10 v1. Rutea 5% del tráfico hacia ella.
  2. Espera 5 min recolectando métricas (latencia, errores, CPU).
  3. Si las métricas están dentro del baseline, sube más réplicas v2 y rutea 25%.
  4. Repite en 50% y 100%.
  5. Si en cualquier paso las métricas empeoran, revierte automáticamente.

Spec YAML

job: api-vendas
tasks:
  - name: web
    image: minhaempresa/api-vendas:1.5.0
    count: 10
    update:
      strategy: canary
      stages:
        - percent: 5
          duration: 5m
        - percent: 25
          duration: 10m
        - percent: 50
          duration: 10m
        - percent: 100
      analysis:
        success_rate_min: 99.5
        latency_p95_max: 250ms
        error_rate_max: 0.5
        baseline: previous_version
      auto_revert: true

El bloque analysis define qué cuenta como "ok". Si la versión nueva tiene latency_p95 de 300ms mientras la anterior tenía 200ms, el sistema revierte solo antes de llegar a 100%.

Trade-offs

Más lento (40 min para promover totalmente vs. 5 min del rolling). Exige métricas confiables y baseline claro. Si tu aplicación no tiene métricas de negocio bien definidas, canary se vuelve teatro.

Nota: usa canary cuando el costo de una versión mala en producción sea alto y tengas instrumentación para detectar regresión sin depender de tickets de usuario.

Blue-green

Dos entornos paralelos. "Blue" recibe 100% del tráfico con la versión actual. "Green" sube con la versión nueva, vacío. Cuando está saludable, switch instantáneo del tráfico de blue a green.

Cómo funciona

  1. Estado inicial: blue (v1) recibe 100%. Green no existe.
  2. Sube green con v2, misma cantidad de réplicas.
  3. Aguarda a que green quede saludable (sin tráfico, pero con health check pasando).
  4. Switch: el ingress pasa a apuntar a green. Blue sigue vivo, sin tráfico.
  5. Período de observación (15 min, por ejemplo).
  6. Si ok, descarta blue. Si algo se rompe, switch de vuelta en segundos.

Spec YAML

job: api-vendas
tasks:
  - name: web
    image: minhaempresa/api-vendas:1.5.0
    count: 4
    update:
      strategy: blue-green
      promote_after: 15m
      auto_promote: false
      auto_revert: true

Con auto_promote: false, el switch necesita comando manual:

heroctl deploy promote dep-2026-04-26-005

Para revertir:

heroctl deploy abort dep-2026-04-26-005
# tráfego volta para blue em 1-2 segundos

Trade-offs

El costo se duplica durante la ventana de validación (4 + 4 réplicas en lugar de 4). Para apps con mucha memoria o GPU, eso pesa. En compensación, el rollback es el más rápido de las 4 estrategias y no hay mezcla de versiones en producción en ningún momento.

Atención: blue-green no resuelve cambio de schema de base. Si la nueva versión necesita columna nueva, sigue siendo responsabilidad de la aplicación hacer la migración compatible con las dos versiones durante la ventana.

Rainbow

Varias versiones coexistiendo de forma permanente, cada una sirviendo a un conjunto específico de usuarios. No es estrategia de actualización sino modelo de operación.

Cuándo tiene sentido

Solo para B2B con clientes que necesitan versión fija por contrato. Ejemplos:

  • ERP donde el cliente A pidió quedarse trabado en v3.2 hasta auditar.
  • API que cobra por SLA y el cliente premium tiene derecho a cambiar de versión bajo demanda.
  • Plataforma multi-tenant con customización pesada por cliente.

En SaaS B2C o productos de masa, rainbow es desperdicio.

Cómo funciona

Varias versiones del mismo job corriendo al mismo tiempo, cada una con tag distinto. El ruteo por header, subdominio o claim del token decide qué versión atiende cada request.

Spec YAML

job: api-vendas
versions:
  - tag: v3.2
    image: minhaempresa/api-vendas:3.2.7
    count: 2
    routing:
      tenants: [acme, contoso]

  - tag: v4.0
    image: minhaempresa/api-vendas:4.0.1
    count: 4
    routing:
      tenants: [default]

  - tag: v4.1-beta
    image: minhaempresa/api-vendas:4.1.0-rc3
    count: 1
    routing:
      tenants: [internal-test]

La regla de routing.tenants se evalúa en cada request. El ingress direcciona por el claim tenant_id del token.

Trade-offs

Costo proporcional al número de versiones vivas. La operación se vuelve compleja: cada bug fix debe ser portado a todas las versiones soportadas. Vuélvete rainbow solo con contratos o regulación que lo justifiquen.

Atención: rainbow es fácil de iniciar y difícil de salir. Antes de adoptarlo, pregunta si 2 versiones "verdes" y una ventana de migración definida no resuelven el caso.

Cómo elegir

En orden de pregunta:

  1. ¿El cambio es retro-compatible? Si sí, rolling resuelve.
  2. ¿Existe métrica clara para detectar regresión en 5 min? Si sí, canary.
  3. ¿El rollback debe ser instantáneo? Si sí, blue-green.
  4. ¿Varios clientes pagan para quedarse en versión fija? Ahí, rainbow.

En la duda entre canary y blue-green, elige la que combine con tu madurez de observabilidad. Canary sin métricas se vuelve burocracia. Blue-green sin capacidad doblada se rompe en el momento equivocado.

Próximo paso: referencia completa del CLI con los comandos deploy promote, deploy abort y deploy pause usados aquí.

#deploy#rolling#canary#blue-green#estrategias
Volver al índice