Blue Green Deployment: o que é e como fazer

Blue green deployment é um modelo de release em que dois ambientes idênticos coexistem: o blue, que serve a versão atual, e o green, que recebe a versão nova. Quando o green está validado, o roteador ou balanceador desvia o tráfego. Se algo quebra, o caminho de volta é imediato.

Como funciona a troca entre blue e green?

O time sobe a nova versão no ambiente inativo, roda testes de fumaça e só então muda o roteamento. O detalhe que costuma ser ignorado: banco de dados. Se a migração de schema não for compatível com as duas versões ao mesmo tempo, a troca deixa de ser reversível na prática.

Quanto custa manter dois ambientes?

Manter infraestrutura duplicada é o principal freio de adoção. Em um serviço pequeno, o custo pode ser aceitável; em clusters com GPU ou bancos licenciados, a conta dobra. Uma alternativa é manter o green sob demanda, criado no momento do release, o que reduz o custo fixo mas aumenta o tempo de preparação.

Quando o blue green não resolve?

Ele não elimina risco de dados. Alterações de schema destrutivas, filas com mensagens em formato antigo e sessões em memória local quebram durante a troca. Nesses casos, o padrão canário, que libera a nova versão para uma fração do tráfego, costuma ser mais seguro.

O modelo faz sentido quando o time precisa de rollback rápido e tem orçamento para ambiente duplicado. Para quem não tem, canário ou feature flags entregam parte do benefício com menos custo.

Perguntas frequentes

Blue green deployment é o mesmo que canário?

Não. No blue green a troca é binária: todo o tráfego vai para o green de uma vez. No canário, uma fração pequena de usuários acessa a nova versão antes da liberação total, o que permite detectar falhas com menor exposição.

Qual a principal vantagem do blue green?

O rollback. Como o ambiente antigo permanece no ar e intacto, voltar atrás é só redirecionar o tráfego, sem reconstruir a versão anterior. Isso reduz o tempo de recuperação em caso de falha crítica em produção.

Preciso de Kubernetes para fazer blue green?

Não é obrigatório. O padrão depende de um roteador capaz de trocar o destino do tráfego, o que existe em balanceadores, proxies reversos e serviços gerenciados de nuvem. Kubernetes facilita, mas não é pré-requisito.

Como lidar com o banco de dados na troca?

Aplique migrações compatíveis com as duas versões, em etapas. Adicione colunas antes, migre dados, e só remova o que sobrou depois que o blue for desativado. Migração destrutiva no mesmo release quebra a reversibilidade.

Blue green funciona para aplicações monolíticas?

Funciona, desde que a aplicação seja stateless o suficiente para rodar em dois ambientes simultâneos. Sessões em memória local e arquivos gravados no disco do servidor são os obstáculos mais comuns nesse cenário.