Estratégias de Deploy: Rolling, Blue-Green e Canary

O problema

Tem deploy que parece seguro só porque o nome parece sofisticado.

O time diz:

• “vamos de canary”
• “blue-green e mais profissional”
• “rolling já basta”

Mas sem modelo mental isso vira escolha por costume, não por risco.

E o problema real de deploy não e a sigla.

E este:

como eu coloco a versão nova em produção sem transformar qualquer erro em incidente gigante?

Modelo mental

Cada estratégia de deploy responde a mesma pergunta de um jeito diferente:

como a versão nova entra no tráfego e como eu recuo se der problema?

Separando de forma simples:

• rolling troca aos poucos as instancias
• blue-green troca de um ambiente completo para outro
• canary expoe primeiro só uma fatia do tráfego

O resto da conversa fica melhor quando você compara:

• velocidade de rollback
• custo operacional
• facilidade de observar problema
• compatibilidade entre versões convivendo

Quebrando o problema

Rolling deploy

No rolling, a versão nova substitui a antiga gradualmente.

Em termos simples:

• algumas instancias antigas saem
• algumas novas entram
• o tráfego vai migrando

Pontos bons:

• costuma ser mais simples
• usa menos infraestrutura extra
• combina bem com plataformas comuns

Pontos de cuidado:

• versão antiga e nova convivem por um tempo
• rollback pode ser menos instantaneo
• migração breaking no banco fica mais sensivel

Blue-green

No blue-green, você mantem dois ambientes equivalentes:

• um ativo
• um pronto para assumir

Quando a nova versão esta no ambiente inativo e parece saudavel, o tráfego troca.

Pontos bons:

• rollback costuma ser rápido
• a troca de tráfego fica mais clara
• o ambiente antigo continua preservado por um tempo

Pontos de cuidado:

• custa mais manter dois lados
• exige disciplina para ambiente realmente equivalente
• estado compartilhado e migracoes continuam pedindo cuidado

Canary

No canary, a nova versão recebe primeiro uma parte pequena do tráfego.

Exemplo:

• 1%
• depois 5%
• depois 25%
• depois 100%

Pontos bons:

• problema aparece com impacto menor
• facilita observar erro, latência e comportamento real
• bom para mudancas arriscadas em larga escala

Pontos de cuidado:

• exige roteamento e observabilidade melhores
• aumenta complexidade de release
• versões convivendo pedem compatibilidade forte

Estratégia de deploy não substitui compatibilidade

Esse ponto derruba muito desenho bonito.

Se a versão nova não consegue conviver minimamente com a antiga, ou se a mudança de banco e breaking sem transição, a estratégia de deploy salva menos do que parece.

Deploy não corrige acoplamento ruim.

Exemplo simples

Imagine uma API com mudança interna grande.

Se o time usa rolling:

• algumas instancias novas entram
• outras antigas continuam atendendo
• se a nova versão aumentar erro, o impacto pode se espalhar enquanto a troca acontece

Se usa blue-green:

• o ambiente novo sobe inteiro
• o tráfego vira quando a validação mínima passa
• se der ruim, voltar costuma ser mais direto

Se usa canary:

• uma fatia pequena do tráfego encontra a versão nova primeiro
• o time mede erro, latência e comportamento
• só depois amplia

Nenhuma e automaticamente melhor.

Cada uma compra um tipo diferente de previsibilidade.

Erros comuns

• Escolher estratégia pelo nome mais famoso.
• Ignorar como rollback vai acontecer na prática.
• Achar que estratégia de deploy resolve migração breaking sozinha.
• Fazer canary sem observabilidade boa.
• Fazer blue-green sem manter os dois lados realmente equivalentes.

Como um senior pensa

Quem tem mais experiência costuma perguntar:

“Qual o pior tipo de falha que essa release pode introduzir, e como essa estratégia limita o alcance dela?”

Essa pergunta e bem melhor do que:

“Qual dessas estratégias e a mais moderna?”

Porque puxa a conversa para risco operacional real.

O que o entrevistador quer ver

Em entrevista, o avaliador quer ver critério.

Você sobe de nivel quando:

• compara as estratégias pelo tipo de risco
• fala de rollback e observabilidade
• menciona convivencia entre versões
• reconhece custo operacional como parte da decisão

Uma resposta forte costuma soar assim:

“Rolling costuma ser mais simples. Blue-green me da troca e rollback mais claros. Canary me ajuda a limitar exposição e observar problema cedo. Eu escolheria olhando custo operacional, compatibilidade e criticidade da release.”

Estratégia de deploy boa não e a mais elegante no slide. E a que reduz o dano do erro mais provavel no seu contexto.