Blue-Green Deployment

Blue-Green Deployment é uma estratégia de implantação baseada na manutenção de dois ambientes de produção idênticos. Apenas um ambiente atende tráfego em determinado momento, enquanto o outro permanece disponível para receber uma nova versão da aplicação.

O objetivo é reduzir indisponibilidade, minimizar risco de rollback e simplificar atualizações em produção.

Os ambientes normalmente são identificados como:

• Blue: versão atualmente em produção.
• Green: nova versão candidata à substituição.

Após validação da nova versão, o roteamento de tráfego é alterado do ambiente ativo para o ambiente atualizado.

Arquitetura

A estratégia exige duplicação da infraestrutura da aplicação:

                ┌─────────────┐
                │ Load Balancer │
                └──────┬──────┘
                       │
         ┌─────────────┴─────────────┐
         │                           │
 ┌───────────────┐           ┌───────────────┐
 │ Ambiente Blue │           │ Ambiente Green│
 │ Versão Atual  │           │ Nova Versão   │
 └───────────────┘           └───────────────┘

O balanceador de carga, proxy reverso ou controlador de ingress define qual ambiente recebe tráfego.

A troca pode ocorrer por:

• Alteração de DNS.
• Troca de upstream no proxy.
• Atualização de regras no load balancer.
• Alteração de Service no Kubernetes.
• Feature flags de roteamento.

Fluxo de Implantação

1. Ambiente Blue ativo

O ambiente Blue atende 100% do tráfego.

2. Implantação no Green

A nova versão é implantada no ambiente Green sem impacto para usuários.

Etapas comuns:

• Build da aplicação.
• Execução de testes automatizados.
• Migração de banco compatível.
• Health checks.
• Smoke tests.

3. Validação

O ambiente Green é validado funcionalmente e operacionalmente.

Exemplos:

• Métricas.
• Logs.
• Telemetria.
• Testes sintéticos.
• Verificação manual.

4. Troca de tráfego

O roteamento é alterado para o ambiente Green.

A mudança pode ser imediata ou gradual.

5. Rollback

Caso ocorram falhas, o tráfego retorna rapidamente ao ambiente Blue.

O rollback normalmente consiste apenas em restaurar o roteamento anterior.

Banco de Dados

O principal desafio em Blue-Green Deployment normalmente é o banco de dados.

Aplicações stateless são relativamente simples de alternar. Já alterações incompatíveis de schema podem impedir rollback.

Boas práticas:

• Aplicar migrações retrocompatíveis.
• Evitar remoção imediata de colunas.
• Implementar estratégia expand-and-contract.
• Separar deployment de aplicação e migration.
• Versionar schema.

Exemplo de migração problemática:

ALTER TABLE usuarios DROP COLUMN telefone;

Caso o rollback da aplicação ocorra, a versão antiga pode depender da coluna removida.

Exemplo compatível:

ALTER TABLE usuarios ADD COLUMN telefone_novo VARCHAR(20);

A aplicação passa a utilizar gradualmente a nova estrutura antes da remoção definitiva.

Blue-Green Deployment no Kubernetes

No Kubernetes, a estratégia normalmente utiliza:

• Deployments separados.
• Labels distintas.
• Services apontando para o ambiente ativo.

Exemplo simplificado:

Deployment Blue

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sistema
      version: blue

Deployment Green

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sistema
      version: green

Service ativo

apiVersion: v1
kind: Service
metadata:
  name: sistema
spec:
  selector:
    app: sistema
    version: blue

A troca ocorre alterando o selector para:

version: green

Integração com CI/CD

Pipelines normalmente executam:

1. Build.
2. Testes automatizados.
3. Publicação da imagem.
4. Deploy no ambiente inativo.
5. Validação automatizada.
6. Alteração de roteamento.
7. Monitoramento pós-deploy.

Ferramentas comuns:

• Jenkins.
• GitLab CI/CD.
• GitHub Actions.
• Argo CD.
• Flux CD.
• Spinnaker.

Vantagens

Redução de indisponibilidade

A troca entre ambientes ocorre rapidamente.

Rollback simplificado

A reversão normalmente exige apenas alteração de roteamento.

Validação segura

A nova versão pode ser testada em ambiente idêntico ao de produção.

Menor risco operacional

A implantação não modifica diretamente o ambiente ativo.

Desvantagens

Custo elevado

A estratégia exige duplicação parcial ou total da infraestrutura.

Complexidade de banco de dados

Mudanças incompatíveis dificultam rollback.

Consumo de recursos

Dois ambientes completos permanecem ativos simultaneamente.

Sincronização de estado

Aplicações stateful podem exigir mecanismos adicionais de replicação.

Comparação com Outras Estratégias

Casos de Uso

Blue-Green Deployment é adequado para:

• Sistemas com baixa tolerância a indisponibilidade.
• Aplicações stateless.
• Ambientes com automação madura.
• Plataformas com necessidade frequente de rollback rápido.

É menos indicado quando:

• Infraestrutura duplicada é inviável.
• Banco de dados possui forte acoplamento com versões.
• Aplicações mantêm estado local persistente.

Conclusão

Blue-Green Deployment reduz risco operacional ao separar implantação e exposição de tráfego. A estratégia simplifica rollback, minimiza indisponibilidade e melhora previsibilidade de releases.

Sua adoção exige automação consistente, observabilidade adequada e atenção especial à compatibilidade de banco de dados.