Rolling, canary, blue-green e rainbow

Toda atualização troca código em produção. A diferença entre as 4 estratégias está em quanto tráfego vê código novo, por quanto tempo, e quão rápido você volta atrás se algo quebra.

Comparação rápida

Não existe "melhor estratégia". Existe a estratégia certa para cada mudança.

Rolling

A estratégia padrão. Substitui réplicas uma de cada vez (ou em pequenos lotes), esperando cada nova ficar saudável antes de mexer na próxima.

Como funciona

Imagine 4 réplicas rodando v1. Rolling com max_parallel: 1:

1. Mata 1 réplica v1, sobe 1 v2. Espera saudável.
2. Mata mais 1 v1, sobe 1 v2. Espera saudável.
3. Repete até as 4 serem v2.

Em qualquer momento, há mistura de v1 e v2 servindo. Para mudanças retro-compatíveis, ok. Para mudanças de schema ou contrato de API, perigoso.

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 — quantas trocar ao mesmo tempo. 1 é mais lento e mais seguro.
• min_healthy_time — quanto tempo a nova precisa ficar saudável antes de avançar. 30s pega a maioria dos crashes tardios.
• healthy_deadline — depois disso, considera falha.
• auto_revert — volta sozinho se falhar.

Trade-offs

Custo extra zero. A janela de mistura entre versões é o ponto fraco. Se v2 tem bug que só aparece com tráfego real, parte dos usuários sofre antes do rollback.

Nota: rolling é a escolha certa quando suas mudanças são pequenas, retro-compatíveis e o app suporta versões diferentes ativas ao mesmo tempo.

Canary

Em vez de trocar réplicas, rolling injeta uma quantidade pequena de novas e direciona uma fatia do tráfego para elas. Você observa métricas. Se tudo bem, aumenta a fatia. Se métricas degradam, reverte.

Como funciona

Com count: 10 e canary configurado para 5% / 25% / 50% / 100%:

1. Sobe 1 réplica v2 ao lado das 10 v1. Roteia 5% do tráfego para ela.
2. Espera 5 min coletando métricas (latência, erros, CPU).
3. Se métricas dentro do baseline, sobe mais réplicas v2 e roteia 25%.
4. Repete em 50% e 100%.
5. Se em qualquer passo as métricas pioram, reverte automaticamente.

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

O bloco analysis define o que conta como "ok". Se a versão nova tem latency_p95 de 300ms enquanto a anterior tinha 200ms, o sistema reverte sozinho antes de chegar a 100%.

Trade-offs

Mais lento (40 min para promover totalmente vs. 5 min do rolling). Exige métricas confiáveis e baseline claro. Se sua aplicação não tem métricas de negócio bem definidas, canary vira teatro.

Nota: use canary quando o custo de uma versão ruim em produção é alto e você tem instrumentação para detectar regressão sem depender de tickets de usuário.

Blue-green

Dois ambientes paralelos. "Blue" recebe 100% do tráfego com versão atual. "Green" sobe com a versão nova, vazio. Quando saudável, switch instantâneo do tráfego de blue para green.

Como funciona

1. Estado inicial: blue (v1) recebe 100%. Green não existe.
2. Sobe green com v2, mesma quantidade de réplicas.
3. Aguarda green ficar saudável (sem tráfego, mas com health check passando).
4. Switch: ingresso passa a apontar para green. Blue continua vivo, sem tráfego.
5. Período de observação (15 min, por exemplo).
6. Se ok, descarta blue. Se algo quebra, switch de volta em 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

Com auto_promote: false, o switch precisa de comando manual:

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

Para reverter:

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

Trade-offs

Custo dobra durante a janela de validação (4 + 4 réplicas em vez de 4). Para apps com muita memória ou GPU, isso pesa. Em compensação, rollback é o mais rápido das 4 estratégias e não há mistura de versões em produção em nenhum momento.

Atenção: blue-green não resolve mudança de schema de banco. Se a nova versão precisa de coluna nova, ainda é responsabilidade da aplicação fazer a migração compatível com as duas versões durante a janela.

Rainbow

Várias versões coexistindo de forma permanente, cada uma servindo um conjunto específico de usuários. Não é estratégia de atualização e sim modelo de operação.

Quando faz sentido

Apenas para B2B com clientes que precisam de versão fixa por contrato. Exemplos:

• ERP onde o cliente A pediu para ficar travado em v3.2 até auditar.
• API que cobra por SLA e cliente premium tem direito a mudar de versão sob demanda.
• Plataforma multi-tenant com customização pesada por cliente.

Em SaaS B2C ou produtos de massa, rainbow é desperdício.

Como funciona

Várias versões do mesmo job rodando ao mesmo tempo, cada uma com tag distinta. Roteamento por header, subdomínio ou claim do token decide qual versão atende cada requisição.

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]

A regra de routing.tenants é avaliada em cada requisição. O ingresso direciona pelo claim tenant_id do token.

Trade-offs

Custo proporcional ao número de versões vivas. Operação fica complexa: cada bug fix precisa ser portado para todas as versões suportadas. Vire rainbow só com contratos ou regulação que justifiquem.

Atenção: rainbow é fácil de iniciar e difícil de sair. Antes de adotar, pergunte se 2 versões "verdes" e uma janela de migração definida não resolvem o caso.

Como escolher

Em ordem de pergunta:

1. A mudança é retro-compatível? Se sim, rolling resolve.
2. Existe métrica clara para detectar regressão em 5 min? Se sim, canary.
3. Rollback precisa ser instantâneo? Se sim, blue-green.
4. Vários clientes pagam para ficar em versão fixa? Aí, rainbow.

Na dúvida entre canary e blue-green, escolha a que combina com sua maturidade de observabilidade. Canary sem métricas viraja burocracia. Blue-green sem capacidade dobrada quebra na hora errada.

Próximo passo: referência completa do CLI com os comandos deploy promote, deploy abort e deploy pause usados aqui.