Deploy blue-green: troque de sistema sem downtime

Deploy blue-green é uma técnica de release em que você roda dois ambientes de produção completos lado a lado: o blue, que atende os usuários hoje, e o green, que contém a nova versão. Depois que o green é testado, você move o tráfego do blue para o green numa única troca controlada.

Bem feito, os usuários não devem perceber downtime, porque o blue continua rodando o tempo todo. Se o green se comportar mal, você aponta o tráfego de volta. É uma das formas mais simples de substituir um sistema em produção, com uma parte difícil: o banco de dados. A seguir explico como a troca funciona, onde ela se encaixa numa migração e onde não se encaixa.

O que é deploy blue-green?

Você mantém dois ambientes tão idênticos quanto conseguir. O blue está no ar. O green fica ocioso ou recebe só tráfego interno de teste. Você faz o deploy da nova versão no green, roda smoke tests e então vira o roteador para que o green passe a ser o ambiente no ar. O blue vira o seu standby. No próximo release, os papéis se invertem.

O que você precisa antes de tentar

• Uma camada de switch: um load balancer, reverse proxy, API gateway, registro DNS ou recurso da plataforma que decide para onde o tráfego vai.
• Ambientes equivalentes: mesma infraestrutura, mesmo formato de configuração, mesmo tratamento de segredos. Divergência entre blue e green é como as surpresas acontecem.
• Health checks: testes automatizados que provam que o green funciona antes de ele receber usuários reais.
• Monitoramento: taxa de erro, latência e pelo menos uma métrica de negócio, para você saber se a troca causou estrago. Como trabalhei no time de carrinho e checkout da Total Wine & More, sempre acompanho um fluxo de dinheiro durante uma troca, não só métricas técnicas.

Se você não consegue montar o segundo ambiente de forma repetível, resolva isso primeiro. Configuração manual deixa o blue-green lento e arriscado.

Como o tráfego passa do ambiente antigo para o novo?

O tráfego se move onde quer que esteja a sua camada de roteamento. As opções comuns diferem principalmente em quão rápido e quão limpo fazem a troca.

Seja qual for a escolha, pense nas requisições que já estão em andamento. Deixe o blue terminá-las (connection draining) antes de parar de mandar tráfego para ele. Verifique também sticky sessions, caches em memória e conexões de longa duração, como websockets. Um usuário logado no blue não deve ser deslogado pela troca.

Como o deploy blue-green ajuda a substituir um sistema em produção?

Ele cria um momento em que o sistema antigo e o novo existem ao mesmo tempo e você escolhe qual deles os usuários veem. Esse é o formato mais seguro para uma migração, porque a decisão é reversível.

Liderei a migração completa de uma plataforma na avanzzada que se candidata automaticamente a vagas de emprego pelos usuários, movendo toda a arquitetura de uma stack legada para uma nova enquanto as pessoas continuavam usando a plataforma todos os dias. A lição que tirei desse tipo de trabalho: coloque o switch na frente de tudo antes de escrever código novo. Quando você consegue rotear o tráfego, cada passo seguinte vira uma decisão pequena e reversível, em vez de uma noite de lançamento.

Onde se encaixa e onde não se encaixa

• Bom encaixe: substituir um serviço ou aplicação inteira quando o antigo e o novo podem rodar em paralelo.
• Encaixe mais fraco: um sistema grande em que a nova stack ainda não faz tudo. Nesse caso, mova peça por peça e use blue-green por rota ou por serviço.
• Custo: você paga para rodar dois ambientes durante a sobreposição. Na minha experiência, isso geralmente sai mais barato do que uma reescrita big-bang, que precisa manter o sistema antigo rodando em paralelo de qualquer forma.

Uma armadilha é o trabalho em segundo plano. Se os dois ambientes rodam os mesmos jobs agendados ou consumidores de fila, os usuários podem receber emails, cobranças ou ações automáticas duplicadas. Decida qual ambiente é dono dos workers e desligue-os no outro. Quando assumo uma base de código, minha ordem é: primeiro os acessos, depois o build, depois os fluxos de dinheiro, depois os riscos, e um inventário de jobs e consumidores é um dos primeiros riscos que listo.

O que acontece com o banco de dados durante uma troca blue-green?

Essa é a dificuldade real. Duas versões da aplicação geralmente compartilham um banco de dados, então o schema precisa funcionar para as duas ao mesmo tempo.

Opção 1: banco compartilhado, mudanças retrocompatíveis

A abordagem mais comum, e a que uso por padrão, é expand and contract:

1. Expand: adicione novas colunas ou tabelas sem remover nada. O blue continua funcionando.
2. Faça o deploy do green e troque o tráfego. O green usa a nova estrutura e tolera a antiga.
3. Contract: quando tiver certeza de que não vai fazer rollback, remova as colunas antigas num release posterior.

Nunca combine uma mudança destrutiva de schema com a troca de tráfego. Isso elimina o seu rollback.

Opção 2: bancos de dados separados

Quando o novo sistema tem um modelo de dados ou um motor de banco diferente, o green ganha o próprio banco de dados. Aí você precisa manter os dois sincronizados até a troca, usando replicação ou change data capture, e muitas vezes um breve congelamento de escrita no cutover. Dá mais trabalho e traz mais risco, então trato isso como um projeto à parte e ensaio primeiro numa cópia dos dados de produção.

Como fazer rollback se a nova versão falhar?

Fazer rollback significa mandar o tráfego para o blue de novo. Se você se preparou para isso, normalmente leva segundos, e esse é o principal motivo para usar essa técnica.

• Defina os gatilhos com antecedência. Por exemplo: taxa de erro acima de um limite que vocês combinaram, falhas de login ou uma queda numa ação de negócio importante, como checkouts ou envios. Não discuta isso durante um incidente.
• Mantenha o blue rodando e atualizado durante uma janela de observação definida. Desligá-lo logo após a troca elimina sua rede de segurança.
• Proteja os dados. Tudo o que o green escreveu precisa continuar legível pelo blue. É por isso que mudanças de schema retrocompatíveis importam. Com bancos separados, talvez você precise sincronizar os dados de volta.
• Ensaie. Pratique o rollback em staging. Um rollback não testado é um chute.

Observe também os limites. Um rollback não desfaz efeitos colaterais já enviados para o mundo externo, como emails ou pagamentos. Operações idempotentes e bons logs ajudam a limpar isso.

Blue-green ou canário: qual você deve usar?

Os dois reduzem o risco de release, mas abrem mão de coisas diferentes.

• Blue-green: todos os usuários mudam de uma vez, o rollback é uma única troca e a lógica é fácil de entender. Custa um segundo ambiente completo, e um bug escondido atinge todo mundo antes que você perceba.
• Canário: uma pequena parcela dos usuários recebe a nova versão primeiro, então um bug afeta menos pessoas. Exige roteamento ponderado e métricas sólidas para avaliar o resultado, e significa que duas versões atendem usuários por mais tempo.

Minha regra prática, como estimativa e não como padrão: use blue-green quando quiser um cutover limpo e reversível e puder rodar os dois ambientes de forma barata. Use canário quando a mudança for arriscada para o comportamento real dos usuários e você tiver monitoramento para ler os resultados. Combinar os dois funciona bem: valide o green com tráfego de teste e depois mova os usuários em etapas com roteamento ponderado, mantendo o blue pronto até o fim.

Quer uma segunda opinião sobre a sua troca?

Se você está planejando um cutover e tem dúvidas sobre o banco de dados ou o plano de rollback, mande um email para me@filipeeduardo.dev com os detalhes. Terei prazer em trocar ideias e dizer o que eu verificaria primeiro.