Blue-Green Deploy no Node.js

O Blue-Green Deploy no Node.js mantém dois ambientes equivalentes: um atende o tráfego atual e o outro recebe a nova versão. Depois de validar a versão nova, o roteador troca o destino. Se ocorrer regressão, o tráfego pode voltar rapidamente ao ambiente anterior.

Essa estratégia reduz indisponibilidade e separa implantação de ativação. Porém, exige capacidade duplicada, compatibilidade de banco, sincronização de configuração e cuidado com tarefas em background. Um rollback de tráfego não desfaz automaticamente migrations, mensagens publicadas ou efeitos realizados pela nova versão.

Neste guia, você aprenderá a montar ambientes blue e green, configurar proxy, validar readiness, lidar com banco, sessões, filas, WebSocket, observabilidade, rollback e automação de pipeline.

O que é Blue-Green Deploy?

Blue representa o ambiente ativo e Green a nova versão, embora os nomes possam inverter a cada implantação. A referência de Martin Fowler sobre Blue-Green Deployment descreve o padrão. A documentação oficial de Deployments do Kubernetes apresenta mecanismos de rollout que podem ser combinados com Services separados.

Para proxy reverso, consulte Nginx como Proxy para Node.js. Para readiness, veja Probes Kubernetes em Node.js.

Fluxo básico

1. Blue atende produção.
2. Green recebe a nova versão.
3. Green inicia sem tráfego público.
4. Testes e smoke checks são executados.
5. O roteador muda de Blue para Green.
6. Métricas são observadas.
7. Blue permanece disponível para rollback.
8. Depois da estabilidade, Blue é removido ou preparado para o próximo deploy.

Dois processos no mesmo host

Blue: 127.0.0.1:3001
Green: 127.0.0.1:3002

Nginx aponta para um dos grupos:

upstream node_active {
    server 127.0.0.1:3001;
}

server {
    location / {
        proxy_pass http://node_active;
    }
}

Para trocar, altere o upstream, valide a configuração e recarregue o Nginx.

Configuração por symlink

Uma estratégia é gerar dois arquivos:

/etc/nginx/upstreams/blue.conf
/etc/nginx/upstreams/green.conf

Um symlink active.conf aponta para o ambiente atual. A troca precisa ser atômica e seguida de nginx -t.

Docker Compose

Dois serviços podem executar versões diferentes:

services:
  api-blue:
    image: registry.example.com/api:1.8.0
    ports:
      - "127.0.0.1:3001:3000"

  api-green:
    image: registry.example.com/api:1.9.0
    ports:
      - "127.0.0.1:3002:3000"

O proxy decide qual porta recebe tráfego.

Kubernetes com dois Deployments

Crie:

• api-blue com label version=blue;
• api-green com label version=green;
• um Service com selector para a cor ativa.

spec:
  selector:
    app: api
    version: blue

A troca altera o selector para green.

Evite editar imagem no ambiente ativo

Blue e Green devem ser Deployments imutáveis com tags ou, preferencialmente, digests específicos. Não reutilize latest.

Readiness antes da troca

Green precisa estar pronto:

• configuração validada;
• banco conectado;
• cache essencial carregado;
• servidor aceitando conexões;
• probes passando;
• migrations compatíveis;
• dependências acessíveis.

Smoke tests

Execute testes contra um endereço interno:

curl -f https://green.internal/health/ready
curl -f https://green.internal/api/version

Inclua leitura, escrita idempotente e autenticação de teste sem afetar dados reais.

Teste sintético

Uma conta sintética pode criar e remover um recurso controlado. Use chave de idempotência e identifique os dados para limpeza.

Verificação de versão

app.get('/version', (req, res) => {
  res.json({
    version: process.env.APP_VERSION,
    commit: process.env.GIT_SHA
  });
});

Não exponha detalhes desnecessários publicamente; uma rota interna ou header pode ser suficiente.

Troca atômica

O roteador precisa mudar sem período em que nenhum backend está disponível. Em Kubernetes, a atualização do selector se propaga pelos endpoints; mantenha Blue ativo durante a transição.

DNS não é a melhor chave

Trocar DNS pode sofrer cache e TTL variável. Prefira load balancer, Service ou proxy que controle destino de forma rápida.

Conexões existentes

A troca afeta novas conexões. Requisições e keep-alive já conectados podem continuar no Blue por algum tempo. Blue não deve ser desligado imediatamente.

Tempo de drenagem

Defina uma janela maior que:

• requisição HTTP mais longa;
• timeout do proxy;
• propagação de endpoints;
• keep-alive;
• tarefas em andamento.

Graceful shutdown

Ao remover Blue, marque readiness como falsa, pare de aceitar trabalho e conclua conexões. Consulte Graceful Shutdown no Node.js.

WebSocket

Conexões WebSocket podem durar horas. A troca não as move para Green. Estratégias:

• manter Blue durante uma janela longa;
• enviar aviso de reconexão;
• definir duração máxima;
• usar protocolo de retomada;
• desligar conexões gradualmente.

Consulte WebSocket com Node.js.

Server-Sent Events

SSE também mantém conexões. O cliente deve reconectar usando Last-Event-ID quando o ambiente antigo for encerrado.

Sessões

Sessões não podem existir apenas na memória do Blue. Use cookie assinado, Redis ou banco compartilhado para que Green continue atendendo.

Uploads locais

Arquivos gravados no filesystem do Blue não aparecem no Green. Use object storage ou volume compartilhado com semântica adequada.

Cache local

Caches em memória começam frios no Green. Aqueça apenas dados importantes e limite carga no banco.

Filas e workers

Se Blue e Green executam consumidores ao mesmo tempo, a capacidade duplica e o comportamento novo pode começar antes da troca HTTP.

Separe Deployment de API e worker, ou controle consumo por flag e rollout próprio.

Cron jobs

Dois ambientes podem executar a mesma tarefa agendada. Use um scheduler central, lock distribuído ou mantenha cron desativado no Green até a ativação.

Eventos e compatibilidade

Blue e Green podem consumir mensagens simultaneamente. Schemas precisam ser compatíveis com ambas as versões durante a transição.

Banco compartilhado

Na maioria dos casos, ambos usam o mesmo banco. Isso exige migrations compatíveis com versões anterior e nova.

Expand and contract

1. Adicionar coluna ou tabela sem remover a antiga.
2. Implantar código que aceita ambas.
3. Migrar dados.
4. Trocar tráfego.
5. Confirmar estabilidade.
6. Remover uso antigo em outro deploy.
7. Só depois eliminar schema antigo.

Não renomeie coluna diretamente

Blue pode depender do nome antigo. Adicione a nova coluna, faça escrita compatível, backfill e remova depois.

Migrations antes ou depois?

Migrations aditivas podem ocorrer antes. Mudanças destrutivas devem esperar até Blue não ser mais necessário para rollback.

Rollback de tráfego

Se Green aumenta erros, volte o roteador ao Blue. O rollback precisa ser automatizado e testado.

Rollback não desfaz dados

Green pode ter criado registros em formato novo, enviado mensagens ou chamado provedores. Blue precisa conseguir ler esses efeitos ou a migração precisa incluir estratégia de compatibilidade.

Feature flags

Uma flag permite desativar comportamento novo sem trocar o ambiente. Consulte Feature Flags no Node.js.

Configuração

Blue e Green devem receber o mesmo contrato de configuração, com diferenças apenas quando intencionais. Consulte ConfigMaps e Secrets no Node.js.

Segredos

A nova versão pode exigir outro segredo. Rotacione com período de sobreposição para que Blue e Green funcionem simultaneamente.

Certificados e tokens

Não revogue credenciais do Blue antes de terminar a janela de rollback.

Observabilidade por ambiente

Adicione labels:

• release;
• cor;
• commit;
• ambiente;
• instância.

Compare Green com Blue antes e depois da troca.

Métricas de validação

• taxa de erro;
• latência p95 e p99;
• CPU e memória;
• event loop delay;
• pool de banco;
• fila;
• métrica de negócio;
• erros por release.

Consulte Métricas Prometheus no Node.js.

Logs por release

Inclua versão e cor nos logs. Consulte Logs com Pino no Node.js.

Sentry

Defina release para separar regressões. Consulte Sentry no Node.js.

Janela de observação

Não destrua Blue imediatamente após uma resposta 200. Aguarde tempo suficiente para tarefas assíncronas, caches e métricas revelarem regressões.

Critérios de promoção

O pipeline deve exigir:

• probes saudáveis;
• smoke tests aprovados;
• erro abaixo do limite;
• latência dentro do SLO;
• migrations concluídas;
• aprovação quando necessária.

Automação

Um pipeline pode:

1. construir imagem imutável;
2. implantar no ambiente inativo;
3. esperar readiness;
4. executar testes;
5. trocar o roteador;
6. observar métricas;
7. promover ou reverter;
8. registrar o deploy.

Permissões

O pipeline deve ter apenas acesso necessário para atualizar o ambiente e o roteador. Proteja tokens e exija revisão para produção.

Capacidade duplicada

Blue-Green precisa executar dois ambientes durante a janela. Planeje CPU, memória, conexões de banco e quotas.

Pool de banco

Se cada ambiente abre 100 conexões, durante o deploy haverá 200. Ajuste pool e capacidade. Consulte Pool PostgreSQL no Node.js.

Custos

Ambiente duplicado aumenta custo, mas pode existir apenas durante o deploy. Compare com o custo de indisponibilidade e rollback lento.

Teste do rollback

Em homologação, troque para Green, gere falha controlada e retorne a Blue. Confirme tempo, conexões e dados.

Erros comuns

• Migration destrutiva: Blue não consegue voltar.
• Blue desligado cedo: conexões são interrompidas.
• Workers duplicados: tarefas executam duas vezes.
• Sessão em memória: usuários perdem login.
• Sem métricas por release: regressão fica escondida.
• latest: ambientes não são reproduzíveis.
• Rollback manual não testado: falha durante incidente.

Boas práticas

• Use artefatos imutáveis.
• Valide Green internamente.
• Use readiness.
• Mantenha dados compatíveis.
• Separe workers.
• Drene conexões.
• Monitore por release.
• Automatize a troca.
• Mantenha Blue na janela de rollback.
• Teste rollback regularmente.

Conclusão

O Blue-Green Deploy no Node.js reduz indisponibilidade ao preparar a nova versão em um ambiente separado e trocar o tráfego apenas após validação. A versão anterior permanece disponível para retorno rápido.

A segurança do rollback depende de compatibilidade de dados, sessões externas, workers controlados e drenagem de conexões. Com artefatos imutáveis, smoke tests, métricas por release e migrations expand-and-contract, a estratégia transforma deploy em uma mudança reversível de roteamento, não em uma aposta irreversível.