# Blue Green Deployment: o que é e como fazer

> Blue green deployment é uma estratégia de release que mantém dois ambientes de produção idênticos, azul e verde, e alterna o tráfego entre eles após validar a nova versão. O modelo garante rollback quase instantâneo ao reverter o roteamento, mas exige infraestrutura duplicada e sincronização de dados entre os ambientes.

*Digitorack · Apps e Software · 16 de setembro de 2026 · Letícia Sampaio Khoury*

Blue green deployment é um modelo de release que mantém dois ambientes idênticos e troca o tráfego de um para o outro. O ganho é rollback quase instantâneo; o preço é manter infraestrutura duplicada.

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.

---

Fonte (canonical): https://digitorack.com.br/apps-e-software/blue-green-deployment-o-que-e-e-como-fazer/