A Estratégia de Deploy Importa Menos do Que Você Pensa
A maioria dos times de engenharia gasta semanas debatendo qual estratégia de deploy adotar — Rolling, Blue/Green, Canary — como se a escolha fosse o fator decisivo entre um deploy tranquilo e uma sexta-feira às 3h da manhã apagando incêndio em produção.
Não é.
A estratégia é o envelope. O que determina se o deploy vai funcionar ou explodir são os parâmetros: readiness delay, warmup time, connection draining, batch size. Detalhes que a maioria dos times configura no automático — ou pior, deixa no valor padrão.
Este guia cobre todas as estratégias principais, cada uma com uma simulação interativa que você pode ajustar e quebrar. Mas o ponto não é escolher a “melhor” — é entender por que nenhuma delas te salva sozinha.
Importante: a estratégia sozinha não garante zero downtime. Ajustes de readiness/health-check, warmup e connection draining podem derrubar requests mesmo em Rolling, Blue/Green ou Canary se forem configurados cedo ou curtos demais.
Recreate
A versão antiga (v1) é completamente desligada antes da nova versão (v2) iniciar. Sem sobreposição, sem coexistência. Para tudo, inicia de novo.
Como funciona:
- Para todas as instâncias v1
- Aguarda o desligamento completo
- Inicia todas as instâncias v2
- Retoma o tráfego
Onde faz sentido:
Quando você não pode ter duas versões rodando simultaneamente — talvez por mudanças no esquema do banco, restrições de licença ou processos stateful que não suportam versões concorrentes.
| Prós | Contras |
|---|---|
| Simplicidade máxima | Causa downtime |
| Sem conflitos de versão | Usuários perdem acesso durante o deploy |
| Transição de estado limpa | Rollback requer re-deploy |
configuração de deploy✓ seguro
Rolling
A versão B substitui a versão A gradualmente, instância por instância (ou em lotes), até que todo o ambiente esteja atualizado.
Como funciona:
- Remove uma (ou um lote de) instância(s) v1 do load balancer
- Substitui por v2
- Roteia tráfego para as novas instâncias
- Repete até todas serem v2
O detalhe: Sua aplicação (especialmente o banco de dados) precisa suportar duas versões diferentes rodando simultaneamente. Contratos de API, esquemas de banco, feature flags — tudo precisa ser retrocompatível durante a janela de transição.
Também entram em jogo parâmetros como batch size, máximo indisponível e mínimo de instâncias ativas. Se você deixar instâncias demais saírem ao mesmo tempo, pode criar gargalo ou até downtime mesmo com rolling update.
| Prós | Contras |
|---|---|
| Zero downtime | Processo de deploy lento |
| Padrão da indústria | Exige retrocompatibilidade |
| Baixo custo de infra | Rollback lento |
configuração de deploy✓ seguro
parâmetros da estratégia
Blue/Green
A versão B (Green) é implantada em um ambiente isolado mas idêntico e paralelo à versão A (Blue). Após testes no Green, o tráfego é alternado instantaneamente no load balancer de A para B.
Como funciona:
- Implanta v2 no ambiente Green (Blue continua servindo tráfego)
- Roda smoke tests no Green
- Alterna o load balancer de Blue → Green
- Se algo quebrar, volta instantaneamente
A parte cara: Você paga por infraestrutura dobrada durante todo o processo. E mudanças no esquema do banco são um pesadelo — ambos os ambientes precisam funcionar com a mesma camada de dados.
| Prós | Contras |
|---|---|
| Zero downtime | Custo de infra dobrado |
| Rollback instantâneo | Migrações de BD são complexas |
| Teste completo pré-produção | Sincronização entre ambientes |
configuração de deploy✓ seguro
Canary
A versão B é liberada para um pequeno subconjunto de usuários (ex: 5%). Se as métricas de saúde (taxa de erros, latência, CPU) estiverem normais, o tráfego é gradualmente aumentado em etapas até atingir 100%.
Como funciona:
- Implanta v2 ao lado de v1
- Roteia 5% do tráfego para v2
- Monitora métricas (erros, latência, saturação)
- Se saudável, aumenta para 25% → 50% → 100%
- Se as métricas degradarem, volta para 0%
É assim que a maioria dos sistemas em larga escala fazem deploy hoje. Limita o raio de explosão — se v2 tem um bug, apenas 5% dos usuários são afetados antes de você detectar.
| Prós | Contras |
|---|---|
| Teste real em produção | Alta complexidade |
| Raio de explosão limitado | Exige ferramentas de observabilidade |
| Confiança baseada em dados | Tempo total de deploy longo |
configuração de deploy✓ seguro
parâmetros da estratégia
Canary ≠ A/B Testing: A infraestrutura é parecida — dividir tráfego entre versões — mas os objetivos são opostos. Canary valida a saúde técnica da nova versão (taxa de erros, latência, saturação). A/B testing valida uma hipótese de produto (qual variante converte mais, engaja mais, retém mais). Canary é decisão de engenharia; A/B é decisão de produto. Frequentemente rodam na mesma infraestrutura, mas respondem perguntas completamente diferentes.
Shadow
A versão B roda em paralelo e recebe uma cópia (espelho) de todo o tráfego indo para a versão A. As respostas da versão B são monitoradas pelos devs mas ignoradas pelos usuários finais — eles sempre veem a resposta de v1.
Como funciona:
- Implanta v2 ao lado de v1
- Espelha todas as requisições para ambas
- Usuários recebem respostas apenas de v1
- Compara respostas, latência e comportamento de v2
- Quando confiante, promove v2 via outra estratégia
Detalhe crítico: Você precisa fazer mock de efeitos colaterais externos. Se v2 processa uma requisição de pagamento espelhada, ela não deve realmente cobrar o cartão do usuário. Mesmo para emails, webhooks e qualquer operação de escrita em bancos compartilhados.
| Prós | Contras |
|---|---|
| Zero risco ao usuário | Muito complexo e caro |
| Teste com carga real | Precisa mockar todos os efeitos colaterais |
| Captura regressões antes da produção | Infraestrutura dobrada |
configuração de deploy✓ seguro
Isso não é sobre ferramentas
As simulações acima mostram um load balancer distribuindo tráfego para instâncias. Mas esse é só um nível de abstração.
Os mesmos padrões se aplicam em escalas completamente diferentes:
| Nível | ”Load Balancer" | "Instância” | Exemplo |
|---|---|---|---|
| Processo | Gerenciador de processos | Worker/thread | PM2, Gunicorn, Puma |
| Container | Service mesh / Ingress | Container | Kubernetes, ECS, Docker Swarm |
| Instância | ALB / Nginx / HAProxy | VM ou servidor | AWS EC2, GCP Compute, bare metal |
| Região | DNS / Global LB | Região inteira | Route 53, Cloudflare, GCP GLB |
Um “Canary deploy” pode significar:
- rotear 10% dos threads para o novo código dentro de uma mesma máquina
- rotear 10% dos pods para a nova versão dentro de um cluster Kubernetes
- rotear 10% do tráfego global para uma região inteira rodando a nova versão
A mecânica é a mesma. O que muda é o raio de impacto — quanto do sistema é afetado se der errado.
Nas simulações, usamos “instâncias” e “load balancer” como vocabulário genérico. Substitua mentalmente pelo nível de abstração que faz sentido para o seu contexto.
A configuração importa mais que a estratégia
A diferença entre um deploy seguro e um desastre são 3 segundos de readiness delay.
Aqui está a tese central deste artigo: a crença de que escolher Rolling ou Canary automaticamente protege contra downtime é perigosa. Não protege. Com configurações agressivas, até a estratégia mais “segura” derruba requests.
Considere estes cenários:
Rolling com readinessDelay = 0:
Você remove uma instância v1, sobe v2, e o load balancer roteia tráfego imediatamente — antes da aplicação estar de fato pronta. Resultado: erros 502 durante a janela de inicialização. Multiplique isso por cada lote e você tem uma cascata de degradação silenciosa.
Blue/Green com warmupTime = 0:
O tráfego alterna instantaneamente para o ambiente Green, mas o Green ainda está fazendo warmup do pool de conexões, JIT, ou cache. Nos primeiros segundos, a latência explode e timeouts começam a aparecer. O “rollback instantâneo” ajuda — mas os requests daquela janela já foram perdidos.
Canary com bootTime muito curto:
O pod canário entra no pool antes de conseguir responder corretamente. Mesmo sendo apenas 5% do tráfego, se o seu sistema tem milhões de requests por dia, 5% é muito request falhando.
A boa notícia: você pode testar isso agora mesmo. Volte nas simulações acima, ajuste os parâmetros de segurança (readiness delay, warmup, drain time) para valores agressivos e observe o que acontece com os requests. Essa é a melhor forma de internalizar por que a configuração importa mais do que a escolha da estratégia.
Tabela Comparativa
| Estratégia | Downtime? | Velocidade do Rollback | Custo de Infra | Complexidade |
|---|---|---|---|---|
| Recreate | Sim | Lento | Baixo | Baixa |
| Rolling | Não | Lento | Baixo | Média |
| Blue/Green | Não | Instantâneo | Alto (2x) | Média-Alta |
| Canary | Não | Rápido | Médio | Alta |
| Shadow | Não | N/A (sem impacto em prod) | Alto (2x) | Muito Alta |
O elefante na sala: migrações de banco de dados
Toda estratégia de deploy que mantém duas versões rodando simultaneamente (Rolling, Blue/Green, Canary) esbarra no mesmo problema: o banco de dados precisa ser compatível com ambas as versões.
Adicionar uma coluna? v1 precisa funcionar com ela existindo. Renomear um campo? v1 vai quebrar se a coluna antiga sumir. Remover uma tabela? Impossível antes de v1 sair completamente do ar.
A solução padrão é o padrão expand-contract (ou “parallel change”):
Fase 1 — Expand: adicione a nova estrutura (coluna, tabela, índice) sem remover a antiga. Deploy v2 que escreve em ambas. Nesse ponto, v1 e v2 coexistem sem conflitos.
Fase 2 — Migrate: backfill dados da estrutura antiga para a nova. Garanta que a nova estrutura é a fonte de verdade.
Fase 3 — Contract: remova a estrutura antiga. Isso só é seguro quando v1 não existe mais em nenhum lugar.
Na prática, cada fase é um deploy separado. Uma “simples” renomeação de coluna vira três deploys sequenciais. É exatamente por isso que equipes maduras investem em feature flags e migrações reversíveis — porque o deploy em si é só uma parte da história.
O espectro de deploy
As cinco estratégias não são opções isoladas — elas formam um espectro. Da esquerda para a direita, cresce a complexidade operacional e o custo de infraestrutura, mas diminui o risco para o usuário final.
Simples
Menor custo / Maior risco
Complexo
Maior custo / Menor risco
Recreate
Downtime total
Rolling
Atualização gradual
Blue/Green
Cópia exata, dobra o custo
Canary
Roteamento percentual
Shadow
Tráfego espelhado
Nenhuma estratégia é universalmente melhor. O ponto certo depende do tamanho do time, da criticidade do serviço e da maturidade da sua observabilidade.
Qual usar?
Comece simples. Se você tem um time pequeno com um único serviço, Rolling updates vão te atender bem. Conforme seu sistema cresce em complexidade e base de usuários, evolua para Canary releases.
Blue/Green brilha quando você precisa de garantias de rollback instantâneo — crítico para sistemas financeiros ou de saúde onde até segundos de serviço degradado importam.
Shadow deploys são para refatorações grandes — trocar bancos de dados, reescrever serviços core, ou migrar para uma nova arquitetura. O investimento em infraestrutura e mocking vale a pena quando as apostas são as mais altas.
Como os melhores times combinam estratégias
Na prática, equipes maduras não usam uma estratégia só. O pipeline típico combina várias, cada uma otimizada para um tipo de mudança:
| Tipo de mudança | Estratégia | Por quê |
|---|---|---|
| Feature nova (código) | Canary → promoção gradual | Limita o raio de impacto; rollback rápido por métricas |
| Hotfix crítico | Rolling com lote de 1 | Velocidade + validação sequencial |
| Migração de banco | Blue/Green + expand-contract | Rollback instantâneo se a migração falhar |
| Reescrita de serviço core | Shadow → Canary | Valida com tráfego real sem risco, depois promove gradualmente |
| Mudança de infraestrutura | Blue/Green regional | Alterna regiões inteiras com fallback imediato |
Um pipeline real pode ser:
- Dev faz push → CI roda testes
- Deploy automático em Canary 5% em produção
- Monitoramento automático por 10 minutos (error rate, p99 latência, saturação)
- Se saudável: promoção gradual 25% → 50% → 100%
- Se degradar: rollback automático para v1
- Para migrações de banco: Blue/Green separado, com a fase expand deployada dias antes via Canary
A estratégia importa menos do que você pensa. A execução importa mais do que você imagina. O segredo não é escolher a estratégia “certa” — é ter a maturidade operacional para que qualquer estratégia funcione.