Blue-Green Deployment: deploy seguro com troca instantânea de ambiente

O que é Blue-Green e como funciona

Dois ambientes idênticos, um ativo por vez

Blue-Green Deployment é uma estratégia de release que mantém dois ambientes de produção idênticos — blue (versão atual) e green (nova versão). O tráfego de produção flui inteiramente para o blue enquanto o green recebe o deploy e é validado. Quando a validação passa, o tráfego é redirecionado do blue para o green em uma operação atômica. O ambiente blue permanece intacto e ocioso, pronto para receber o tráfego de volta instantaneamente se qualquer problema for detectado no green. Essa separação entre deploy e release elimina o downtime e reduz o risco de grandes lançamentos a zero segundos de interrupção de serviço.

Preparando os dois ambientes — blue e green

Paridade como requisito fundamental

Para que Blue-Green funcione, blue e green devem ser ambientes de produção idênticos: mesmo hardware ou tipo de instância, mesma configuração de rede, mesmas variáveis de ambiente, mesmos serviços de suporte. Qualquer diferença entre os ambientes invalida a premissa de que um teste bem-sucedido no green prediz comportamento igual em produção. Na prática, o ambiente green é atualizado com a nova versão da aplicação e apontado para o mesmo banco de dados de produção — ou uma réplica, dependendo da estratégia de schema migration. O green precisa estar completamente funcional antes da troca do tráfego, incluindo aquecimento de caches e conexões de pool.

Trocando o tráfego — DNS, load balancer, service mesh

Os mecanismos de troca instantânea

A troca de tráfego pode ocorrer em diferentes camadas. No nível de DNS, o TTL do registro é ajustado para um valor baixo (60 segundos) antes do deploy e o IP é atualizado para apontar para o green — simples mas com latência de propagação DNS. No nível de load balancer, grupos de destino são trocados instantaneamente: no AWS ALB, basta atualizar o listener rule para apontar para o target group do green. Service meshes como Istio e Linkerd permitem troca de tráfego com granularidade por header ou percentual, combinando Blue-Green com capacidades de canary. A troca via load balancer é a mais comum por ser instantânea e determinística.

Validação antes da troca — smoke tests

Garantindo que o green está saudável

Antes de trocar o tráfego de produção, o ambiente green é validado com smoke tests — um conjunto reduzido de testes que verificam os fluxos críticos da aplicação em produção sem gerar efeitos colaterais. Os smoke tests acessam o green diretamente via URL interna ou header especial que bypassa o load balancer principal. Eles verificam: endpoints de health check respondendo 200, autenticação funcionando, operações de leitura e escrita no banco executando corretamente, integrações com serviços externos respondendo. Se qualquer smoke test falhar, o deploy é abortado e o green é descartado sem que nenhum usuário real tenha sido afetado.

Rollback imediato — voltando para o ambiente anterior

A principal vantagem do Blue-Green

O rollback em Blue-Green é a operação mais simples possível: redirecionar o tráfego de volta para o blue. Como o blue nunca foi modificado e estava apenas ocioso, a reversão é instantânea e sem risco — a mesma operação atômica que fez a troca original, executada ao contrário. Isso contrasta fortemente com estratégias de deploy in-place, onde o rollback requer um novo deploy da versão anterior, com todos os riscos associados. A janela de manutenção do blue (o período em que ele fica ocioso após a troca) deve ser suficiente para detectar problemas — tipicamente de 30 minutos a algumas horas dependendo do nível de monitoramento.

Banco de dados em Blue-Green — schema migrations

O desafio mais complexo da estratégia

Banco de dados é o ponto mais complexo do Blue-Green, especialmente quando há schema migrations. Se blue e green compartilham o mesmo banco, a migration deve ser compatível com ambas as versões simultaneamente — a nova versão do schema deve ser lida corretamente pela versão antiga do código durante a janela de transição. A técnica de expand-contract resolve isso: primeiro expande o schema adicionando novas colunas sem remover as antigas (deploy do green), depois contrai removendo colunas antigas após garantir que o blue não será mais usado. Migrations destrutivas (DROP COLUMN) nunca devem ocorrer no mesmo deploy da mudança de código correspondente.

Custo duplo de infraestrutura

O trade-off financeiro do Blue-Green

A principal desvantagem do Blue-Green é o custo: dois ambientes de produção completos significam o dobro de servidores, instâncias de banco, caches e outros recursos rodando simultaneamente. Para aplicações de alto tráfego com infraestrutura cara, esse custo pode ser significativo. Estratégias de mitigação incluem: manter o ambiente standby (blue após a troca) em estado minimamente ativo ou desligado exceto durante a janela de observação pós-release; usar spot instances ou preemptible VMs para o ambiente standby; adotar Blue-Green apenas para os componentes críticos e usar rolling deploy para os demais. Cloud providers com cobrança por segundo tornam esse custo mais gerenciável.

Blue-Green em Kubernetes

Implementando com Services e Deployments

No Kubernetes, Blue-Green é implementado com dois Deployments (blue e green) e um Service que aponta para um deles via label selector. O Deployment green recebe o novo código e é aguardado até que todos os pods estejam Running e Ready. Os smoke tests são executados diretamente nos pods green via port-forward ou um Service temporário. A troca é feita atualizando o selector do Service principal (patch service -p '{"spec":{"selector":{"version":"green"}}}') — operação instantânea sem downtime. Ferramentas como Argo Rollouts adicionam automação sobre esse processo, com análise de métricas e rollback automático integrados ao ciclo de vida do Rollout.

Blue-Green vs Canary vs Rolling update

Escolhendo a estratégia certa para cada contexto

Rolling update substitui pods gradualmente sem ambiente paralelo — mais simples e barato, mas sem rollback instantâneo e com período de versões mistas em execução. Canary expõe a nova versão para uma fração pequena do tráfego real, coletando métricas antes de expandir — ideal para validar mudanças com dados reais de produção mas exige que as duas versões sejam compatíveis entre si. Blue-Green garante troca atômica e rollback instantâneo ao custo de infraestrutura dupla — melhor quando o risco do release é alto e o custo de downtime justifica o investimento em ambiente paralelo. Em Kubernetes com Argo Rollouts, é possível combinar Blue-Green com análise automática de métricas para obter o melhor dos dois mundos.

Conclusão

Blue-Green como estratégia de deploy de baixo risco

Continue em: Fundamentos obrigatórios antes de produção.