Estratégias de Deploy: Blue-Green, Canary e Rolling Updates na Prática · mrmsoares

Um deploy que derruba 100% dos usuários por 30 segundos custa diferente de um que derruba 1% por 5 minutos. A diferença entre essas duas situações não é sorte: é estratégia de deploy.

Blue-Green, Canary e Rolling Updates resolvem o mesmo problema (colocar código novo em produção sem destruir a experiência do usuário), mas cada uma faz trade-offs diferentes entre complexidade de infra, velocidade de rollback e custo de recursos. Escolher errado não significa que o deploy vai falhar. Significa que você vai gastar infra demais, ou descobrir bugs tarde demais, ou levar minutos para reverter o que poderia levar segundos.

Como cada estratégia funciona por baixo

Antes de comparar, a mecânica precisa estar clara.

Blue-Green mantém dois ambientes idênticos (blue e green). Apenas um recebe tráfego de produção. O deploy acontece no ambiente ocioso. Quando os health checks passam, o roteador (load balancer, DNS, ingress) troca o ponteiro de tráfego de blue para green. Rollback é trocar o ponteiro de volta.

Canary direciona uma fração pequena do tráfego (1%, 5%, 10%) para a versão nova. Métricas de erro, latência e saturação são observadas. Se estiverem saudáveis, o percentual sobe progressivamente até 100%. Se degradarem, o tráfego volta para a versão anterior.

Rolling Update substitui instâncias da versão antiga pela nova em lotes. Se você tem 10 pods, atualiza 2 por vez. Durante o processo, versões antiga e nova coexistem. O Kubernetes usa essa estratégia como padrão.

Blue-Green:
  [LB] ──► [Blue v1] ✓ tráfego ativo
           [Green v2]   ocioso, recebendo deploy
  (troca)
  [LB] ──► [Green v2] ✓ tráfego ativo
           [Blue v1]   ocioso, pronto para rollback

Canary:
  [LB] ──► 95% [v1]
       ──►  5% [v2]  ← observando métricas
  (progressão)
  [LB] ──► 50% [v1]
       ──► 50% [v2]
  (fim)
  [LB] ──► 100% [v2]

Rolling Update:
  [pod1-v1] [pod2-v1] [pod3-v1] [pod4-v1]
  [pod1-v2] [pod2-v2] [pod3-v1] [pod4-v1]  ← 2 atualizados
  [pod1-v2] [pod2-v2] [pod3-v2] [pod4-v2]  ← todos atualizados

Tabela comparativa: critérios que importam na decisão

Critério	Blue-Green	Canary	Rolling Update
Velocidade de rollback	Segundos (troca de ponteiro)	Segundos (redireciona tráfego)	Minutos (precisa recriar pods antigos)
Custo de infra	Alto (ambiente duplicado 100%)	Médio (poucos pods extras)	Baixo (reutiliza os mesmos recursos)
Risco de exposição a bugs	Tudo ou nada: 0% ou 100%	Gradual: 1% → 5% → 25% → 100%	Parcial: depende do tamanho do lote
Complexidade de configuração	Média (dois ambientes + roteamento)	Alta (observabilidade + regras de peso)	Baixa (padrão do Kubernetes)
Coexistência de versões	Não (uma versão recebe tráfego)	Sim (duas versões simultâneas)	Sim (duas versões simultâneas)
Compatibilidade de banco	Precisa de migrations compatíveis com ambas	Precisa de migrations compatíveis com ambas	Precisa de migrations compatíveis com ambas
Melhor para	Aplicações com rollback crítico (fintech, saúde)	Validação gradual com métricas (SaaS, e-commerce)	Workloads stateless com baixo risco (APIs internas)

Rolling Update com Kubernetes: a configuração padrão que você já usa

O Kubernetes aplica Rolling Update por padrão. Mas o padrão sem ajuste é perigoso: maxUnavailable: 25% e maxSurge: 25% significam que, em um deployment com 4 réplicas, 1 pod fica indisponível e 1 pod extra é criado simultaneamente. Em serviços com poucos pods, isso pode derrubar 25% da capacidade durante o deploy.

# deployment-rolling.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-pedidos
  namespace: production
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # maxUnavailable 0 garante que nenhum pod sai antes do novo estar Ready
      maxUnavailable: 0
      # maxSurge 2 cria no máximo 2 pods extras durante o rollout
      maxSurge: 2
  selector:
    matchLabels:
      app: api-ped

---

Leia o artigo completo em [https://www.vivodecodigo.com.br/infra/estrategias-deploy-blue-green-canary-rolling-updates](https://www.vivodecodigo.com.br/infra/estrategias-deploy-blue-green-canary-rolling-updates)

Estava falando com o claude sobre canary essa semana, vou deixar uns trechos da conversa que ajudam a entender o canary:

(Sim, é uma cópia de IA, leia se quiser, o texto está bom)

Canary é, no fundo, um rolling com um cérebro analítico em cima — e essa única diferença reorganiza tudo. Onde o rolling avança baseado só em "a réplica está saudável?", o canary avança baseado em "as métricas da versão nova estão tão boas quanto as da antiga, sob tráfego real?".

Rolling assume que saúde = correção. Canary não confia nisso — ele mede o comportamento real antes de comprometer. É essa desconfiança institucionalizada que custa caro em infra e devolve em segurança.

Canary não impõe exigências só na aplicação; impõe na sua plataforma de observabilidade e roteamento. Faltando qualquer um destes, você tem "canary no nome" — que é pior que rolling honesto, porque dá falsa sensação de segurança.

Observabilidade com métricas etiquetadas por versão. Inegociável. Você tem que conseguir comparar "erro da v2" contra "erro da v1" lado a lado. Isso exige que toda métrica carregue um label de versão (version=v2) e que você tenha o baseline pra comparar. Sem isso, o canary está cego — você roteou 5% e não tem como saber se aquilo está bem ou mal.

Critérios de sucesso definidos (SLOs). Antes de começar você precisa saber o que torna um canary "bom". Tipicamente um conjunto: taxa de erro (5xx), latência em percentis (p95/p99, não média — média esconde cauda), saturação (CPU/memória), e — o mais esquecido — métricas de negócio (taxa de checkout concluído, conversão, sucesso de pagamento). Um bug que não levanta erro HTTP mas derruba a conversão só é pego por métrica de negócio.

Volume de tráfego suficiente. Canary é estatística. 5% de um serviço com pouco tráfego = poucos requests = ruído demais pra concluir qualquer coisa. Se a v2 atende 12 requests em 10 minutos, "0 erros" não significa nada. Serviços de baixo volume são péssimos candidatos a canary — não há significância estatística pra extrair sinal.

Os detalhes profundos que quebram na prática

Comparação de métricas é estatisticamente traiçoeira. Com pouco tráfego no canary, ruído vira "sinal": um pico aleatório de latência em 8 requests dispara um falso negativo e aborta um deploy bom; ou erros raros não aparecem na amostra pequena e um deploy ruim passa (falso positivo de saúde). Canary honesto exige amostra grande o bastante pra significância — o que reforça o requisito de volume.

O baseline injusto — o erro mais sutil e mais comum. A tentação é comparar o canary (réplicas novas, frias: pool de conexão vazio, JIT não aquecido, cache local zerado) contra a v1 estável que roda há dias, quentinha. Quase toda diferença que você vê aí é de temperatura, não de código — e o canary aborta por um problema que não existe. A correção idiomática (que o Kayenta do Spinnaker faz por padrão): suba também uma cópia nova da v1 — o "baseline" — e compare canary novo contra baseline novo, ambos igualmente frios. Aí a diferença restante é de código, que é o que você quer medir.

Escolher as métricas erradas = canary que aprova o desastre. Se você só monitora taxa de erro 5xx, um bug que retorna 200 OK com o preço errado da joia, ou que derruba a conversão do checkout, passa limpo pelo gate. Canary só é tão bom quanto as métricas que você escolheu — precisa cobrir sistema (erro, latência, saturação) e negócio (a métrica que de fato importa pro Ourivus: pedido concluído, pagamento aprovado).

Acredito que o mais importante aqui são as métricas de negócio.

Como o autor disse:

Canary direciona uma fração pequena do tráfego (1%, 5%, 10%) para a versão nova. Métricas de erro, latência e saturação são observadas

Isso é um "rolling chamado de canary"

olhar apenas tráfego e taxa de sucesso não tem nenhuma inteligência

Canary tem que olhar conversão, saúde do negócio, não apenas taxa de erro de requests