Estratégias de deployment em produção: blue-green, canary e rolling updates

Tabela de Conteúdo

Garantir a entrega de novas versões sem impactar usuários é um desafio crítico em DevOps. Diferentes contextos de negócio e infraestrutura exigem abordagens distintas. Neste post, você vai entender três estratégias fundamentais de deployment e quando aplicar cada uma.

Compreendendo o Espectro de Risco

A decisão sobre qual estratégia adotar tem implicações diretas em:

  • RTO (Recovery Time Objective)
  • RPO (Recovery Point Objective)
  • Impacto potencial em usuários

Na prática, cada abordagem fica em um ponto diferente no espectro entre velocidade de atualização e segurança operacional.

Blue-Green Deployment: O Caminho Seguro para Atualizações Críticas

Blue-green mantém dois ambientes de produção idênticos em paralelo. O ambiente “azul” serve 100% do tráfego enquanto o “verde” aguarda em standby.

Como funciona

O processo funciona em fases bem definidas:

  • Deploy completo no verde enquanto o azul continua operacional
  • Testes de smoke, integração e carga no verde sem impactar usuários
  • Troca atômica no load balancer redirecionando 100% do tráfego do azul para o verde

Vantagens

  • Rollback instantâneo: alternar tráfego de volta para o azul leva milissegundos
  • Ambiente anterior intacto: funciona como failsafe

Desvantagens e cuidados

  • Infraestrutura duplicada durante a troca (custo potencialmente ~2x)
  • Banco de dados exige cuidado: durante a transição, ambas as versões precisam suportar o mesmo schema

Rolling Updates: Substituição Gradual com Eficiência de Recursos

Rolling updates tomam a abordagem oposta ao blue-green. Em vez de dois ambientes paralelos, instâncias são substituídas incrementalmente em lotes.

Como funciona

  • Remove uma instância do load balancer
  • Atualiza para a nova versão
  • Valida health checks (só volta ao pool se estiver saudável)
  • Repete em batches até 100% da infraestrutura rodar a nova versão

Vantagens

  • Economia de recursos: não precisa duplicar ambiente
  • Boa integração com Kubernetes via maxSurge (pods extras) e maxUnavailable (pods indisponíveis).

Desvantagens e cuidados

  • Duas versões em paralelo durante o rollout
  • Compatibilidade entre versões é obrigatória (principalmente em aplicações stateful)
  • Rollback mais lento: você reverte gradualmente, não por “troca de chave”

Canary Deployment: Validação em Produção com Exposição Limitada

Canary deployment foca em minimizar risco via gradualismo. O nome vem da história dos mineiros: canários eram levados às minas para detectar gases tóxicos antes que afetassem humanos.

Como funciona

Uma implementação típica começa com uma fração do tráfego (ex: 10%) indo para a nova versão enquanto o restante (ex: 90%) permanece na antiga. A partir daí, você observa métricas como:

  • Taxa de erro
  • Latência (p50, p95, p99)
  • Uso de recursos
  • KPIs de negócio

Se houver divergência (ex: taxa de erro 2x maior na versão nova), você faz rollback rápido: escala a versão nova para zero e retorna 100% para a antiga. Se as métricas permanecerem saudáveis por um período definido (ex: 10 minutos), você aumenta o tráfego gradualmente (25%, 50% …) até chegar em 100%.

Vantagens

  • Falhas afetam apenas um subconjunto de usuários
  • Validação com carga e comportamento real antes do rollout total

Desvantagens e cuidados

  • Exige observabilidade madura: logs, métricas e (idealmente) tracing
  • Coexistência entre versões durante o rollout (inclusive no acesso a dados compartilhados)

Guia Prático de Seleção

Na prática, eu gosto de pensar assim:

  • Blue-Green: quando você quer trocar a versão “de uma vez” e ter um rollback bem rápido. Ex.: sistemas de pagamento, e-commerce em horário de pico, releases com muita coisa mudando.

  • Rolling Update: quando você quer atualizar aos poucos sem dobrar infra. Ex.: serviços stateless, APIs bem horizontais, tudo com health check bem amarrado.

  • Canary: quando você não confia 100% na mudança e quer validar com tráfego real. Ex.: mudança que mexe em regra de negócio, performance, cache, ou algo que só aparece “em produção”.

Dá pra misturar as estratégias também (e isso é comum): canary em alguns serviços, rolling update em outros, e blue-green em partes mais críticas.

Conclusão

Não existe bala de prata.

  • Quer rollback instantâneo? Blue-green.
  • Quer simplicidade e economia? Rolling update.
  • Quer reduzir risco com dados reais? Canary.

Independente da estratégia, o que mais pega em produção é:

  • Health checks decentes
  • Métricas e logs (pra você enxergar erro/latência na hora)
  • Plano de rollback testado

Simples assim! :)

Leitura recomendada