Estratégias de deploy: blue-green, canary e rolling na prática

Colocar código novo em produção é o momento de maior risco concentrado de qualquer sistema. As três estratégias mais conhecidas — rolling, blue-green e canary — existem para reduzir esse risco, e cada uma reduz um risco diferente, com um custo diferente.

A escolha errada aparece de duas formas: ou você paga complexidade que não precisava, ou descobre no pior momento que não tem como voltar.

O risco que cada uma ataca

Repare que as duas últimas linhas atacam problemas diferentes. Blue-green te dá volta rápida. Canary te dá descoberta antecipada com pouca gente afetada. Não são graus da mesma coisa, e em sistemas críticos as duas se combinam.

Recriar: derrubar e subir

Derruba a versão antiga, sobe a nova. Há indisponibilidade entre as duas.

Não é vergonha nenhuma. É a estratégia certa para serviço interno, processamento em lote, ambiente de homologação e qualquer caso em que alguns segundos ou minutos de pausa não têm consequência. Simplicidade é um recurso escasso e vale gastar onde importa.

Rolling: o padrão, com uma armadilha

Substitui as instâncias aos poucos: sobe uma nova, espera ficar saudável, remove uma antiga, repete. É o padrão do Kubernetes e da maioria dos orquestradores.

Ganha: sem indisponibilidade, sem recurso extra significativo, simples de configurar.

A armadilha: durante a transição, as duas versões rodam ao mesmo tempo, atendendo o mesmo tráfego. Isso exige que as versões sejam compatíveis entre si — e essa exigência é ignorada com frequência até o dia em que causa um incidente difícil de entender.

Compatibilidade aqui significa:

• O esquema do banco atende a versão antiga e a nova.
• Mensagens produzidas por uma versão são consumidas pela outra sem erro.
• Não há mudança incompatível de contrato de API entre serviços.
• Não há estado em memória que dependa de uma versão específica.

E o rollback é lento, porque é o mesmo processo ao contrário, instância por instância. Se a versão nova está causando erro em 100% das requisições, esses minutos custam caro.

Três coisas tornam o rolling confiável: verificação de prontidão correta em cada instância (para não receber tráfego antes de estar pronta), encerramento gracioso (para terminar as requisições em curso antes de morrer) e limite de indisponibilidade configurado para não derrubar capacidade demais de uma vez.

Blue-green: o botão de voltar

Você mantém dois ambientes completos. O azul está em produção; você sobe a versão nova inteira no verde, valida com calma e então redireciona o tráfego de uma vez. Se der problema, redireciona de volta.

Ganha: rollback em segundos, e a possibilidade de validar o ambiente novo completo antes de qualquer usuário tocá-lo. Só uma versão atende tráfego por vez, o que elimina o problema de compatibilidade do rolling.

Paga: dobro de recurso durante a janela, e complexidade no que é compartilhado — porque o banco de dados, quase sempre, é um só.

O problema real é o estado. Se a versão nova aplicou uma migração de esquema e você volta para a antiga, a antiga precisa funcionar com o esquema novo. Se não funcionar, você tem um botão de voltar que não pode apertar — que é a pior situação possível, porque a equipe acredita que tem.

A disciplina que resolve, e que vale para qualquer estratégia:

1. Migração de banco sempre compatível para trás. Adicionar coluna, nunca remover nem renomear no mesmo deploy.
2. Separar a mudança de esquema do deploy de código. Primeiro a migração aditiva, depois o código que a usa, em deploys distintos.
3. Remoção do que ficou obsoleto só várias versões depois, quando não há mais código antigo em lugar nenhum.

É o padrão de expandir e contrair, e é o que faz rollback ser real em vez de teórico.

Também vale lembrar: sessões em memória, conexões longas e trabalhos em andamento não migram sozinhos na virada. Sessão em armazenamento externo resolve a primeira parte.

Canary: descobrir com poucos

Envia uma fatia pequena do tráfego — 1%, 5% — para a versão nova, observa as métricas e aumenta gradualmente se estiver tudo bem. Se piorar, volta a fatia para zero.

Ganha: problemas que só aparecem com tráfego real, dado real e concorrência real são descobertos afetando pouca gente. Nenhuma homologação reproduz produção completamente, e canary aceita isso em vez de fingir o contrário.

Paga: exige roteamento por percentual — ingress com peso, service mesh ou balanceador capaz — e, principalmente, exige observabilidade boa o suficiente para decidir.

Esse último ponto é o que separa canary de verdade de canary de fachada. Se você não consegue comparar taxa de erro, latência e taxa de sucesso de negócio entre as duas versões, você não está fazendo canary — está fazendo rolling com passo pequeno e esperança.

O que precisa estar instrumentado, com a versão como dimensão da métrica:

• Taxa de erro por versão.
• Latência nos percentis altos por versão.
• Métrica de negócio que importa: conversão, sucesso de transação, taxa de login.
• Uso de recurso, para pegar vazamento ou regressão de desempenho.

E os critérios de promoção e de reversão precisam estar escritos antes do deploy. "Se a taxa de erro do canário passar de 1,5x a do estável por 5 minutos, reverte automaticamente." Decidir isso no calor do momento leva a hesitação.

Um detalhe de roteamento: para sistemas com sessão, o canary deve ser consistente por usuário. Alternar a mesma pessoa entre versões a cada requisição produz comportamento errático e reclamações difíceis de diagnosticar.

Como escolher

Um caminho simples que funciona:

1. Serviço interno ou lote? Recriar.
2. Precisa de zero indisponibilidade e as versões são compatíveis? Rolling.
3. Precisa de rollback imediato e tem recurso para o ambiente duplo? Blue-green.
4. É crítico e você quer descobrir com poucos usuários? Canary — desde que a observabilidade exista.
5. É crítico e caro de errar? Canary para descobrir, com capacidade de virada rápida para voltar.

E uma regra que vale mais que a escolha: feature flag desacopla deploy de liberação. Com a funcionalidade nova atrás de uma chave, você entrega o código com rolling simples e liga o recurso para 1% dos usuários depois, sem novo deploy. Voltar atrás é desligar a chave — mais rápido que qualquer estratégia de infraestrutura.

O que vale para todas

• Verificação de saúde e de prontidão que realmente reflitam capacidade de atender, não apenas "o processo está vivo".
• Encerramento gracioso, drenando conexões antes de morrer.
• Migração de banco compatível para trás, sempre.
• Rollback ensaiado. Não basta existir no papel; alguém precisa ter feito, cronometrado.
• Deploy automatizado e reprodutível, nunca comando digitado sob pressão.
• Métricas com a versão como dimensão, ou não há como comparar nada.
• Janela de observação após o deploy, com alguém acompanhando.

Erros comuns

• Rolling com versões incompatíveis convivendo.
• Verificação de prontidão que responde "pronto" antes de a aplicação estar.
• Sem encerramento gracioso, cortando requisições em andamento.
• Blue-green com migração destrutiva de banco, tornando o rollback impossível.
• Canary sem métrica por versão — não há como decidir.
• Critério de reversão não definido antes do deploy.
• Canary que alterna o mesmo usuário entre versões.
• Adotar canary com service mesh inteiro quando uma feature flag resolveria.
• Nunca ter testado o rollback.
• Deploy manual por SSH em produção.
• Sessão em memória, perdida na virada.

Onde a Solvefy/Cloud entra

Implantamos a estratégia adequada a cada serviço — e, com frequência, a recomendação é a mais simples do que o time esperava. Montamos o pipeline com verificação de saúde correta, encerramento gracioso, migração de banco no padrão expandir e contrair, métricas por versão, critérios de promoção e reversão escritos e o rollback ensaiado e cronometrado. Também ajudamos a adotar feature flags, que costumam entregar mais controle com menos infraestrutura.

Seu deploy dá medo? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.