Blue-Green Deployment

O Blue-Green Deployment é a estratégia que mantém dois ambientes de produção completos e equivalentes, um ativo recebendo o tráfego real e outro inativo aguardando a próxima versão. A publicação consiste em instalar a versão nova no ambiente inativo, validá-la, e transferir todo o tráfego para ele por meio de um switch no roteamento, em geral um load balancer ou um registro DNS. O ambiente antigo permanece preservado, o que transforma o rollback em uma operação de segundos, bastando apontar o tráfego de volta. Essa característica faz do blue-green a estratégia preferida para sistemas com requisitos severos de disponibilidade e com necessidade de reversão quase instantânea. O custo dessa segurança é direto: o dobro de infraestrutura durante a janela do deploy, além da disciplina para manter os dois ambientes verdadeiramente idênticos.

Conceito e problema que resolve

O problema que o blue-green ataca é o intervalo de risco entre publicar uma versão e descobrir que ela está errada. No rolling update, a versão ruim se espalha pela frota gradualmente e a reversão leva minutos; em sistemas onde cada minuto de erro gera prejuízo financeiro ou regulatório, esse tempo é inaceitável. O blue-green isola o risco: a versão nova roda em um ambiente separado, é exercitada com testes reais antes de receber clientes, e o tráfego só muda quando a confiança está estabelecida.

Os dois nomes da estratégia descrevem o estado alternado. O ambiente blue está ativo servindo a versão atual, e o green fica em pé de igualdade física, mas sem tráfego. No deploy seguinte, os papéis invertem: a versão nova entra no blue, o switch muda o tráfego para lá, e o green passa a ser o ambiente de espera. A alternância contínua garante que nenhum ambiente vire geladeira com dependências desatualizadas.

Funcionamento interno do ciclo de deploy

O ciclo completo tem etapas bem definidas, e a ordem delas é o que garante a segurança da estratégia.

• Provisionamento e sincronização do ambiente inativo, com mesma topologia, mesma capacidade e mesma configuração do ativo; divergência aqui é a raiz da maioria dos incidentes de blue-green.
• Instalação da versão nova no ambiente inativo, porém com o banco de dados compartilhado, o que exige compatibilidade de schema imediata entre as versões.
• Aquecimento do ambiente novo, com caches pré-carregados, pools de conexão abertos, compilações JIT estimuladas e auto scaling já com métricas de referência.
• Verificação de fumaça contra o ambiente inativo por endpoint interno, sem expor tráfego real, cobrindo os fluxos críticos ponta a ponta.
• Switch de tráfego no roteador, em geral alterando o target group do load balancer, com confluência de sessões antigas respeitada pelo grace period.
• Observação pós-switch com ambiente antigo ainda de pé, pronto para reversão imediata durante a janela de burn-in.
• Desativação do ambiente antigo, apenas depois de decorrido o período de confiança, encerrando os recursos para conter o custo.

O switch é o único evento de risco concentrado, e é justamente por isso que tudo antes dele é verificação e tudo depois dele é prudência. Em arquiteturas bem executadas, o switch em si é trivial: um comando no roteador, sem nenhum processo da aplicação envolvido.

Mecanismos de switch de tráfego

O switch pode acontecer em camadas diferentes da pilha, e a camada escolhida define a granularidade e a velocidade da operação. No load balancer, o switch é a alteração do target group associado ao listener, com efeito em segundos e sem propagação. No DNS, o switch é a troca do registro apontando para o IP do ambiente, com efeito condicionado ao TTL: um TTL de 3600 segundos significa que resolvers podem servir o endereço antigo por até uma hora, o que torna TTLs baixos, na casa de 60 segundos, pré-requisito do modelo. Em Kubernetes, o switch é a alteração do selector de um Service, ou a troca de rótulos nos Pods, e o roteamento interno converge quase instantaneamente. Em service mesh, o switch é um VirtualService com peso de roteamento, que inclusive permite transição por rampa em vez de corte seco.

A escolha tem consequências operacionais. Switch por DNS é simples, mas impreciso, porque resolvers intermediários ignoram TTLs ou mantêm caches próprios. Switch por load balancer é preciso e reversível, mas exige que os dois ambientes sejam registráveis no mesmo roteador. A prática recomendada combina ambos: load balancer como mecanismo primário de switch, e DNS apenas na fronteira externa, com TTL curto.

Verificação de fumaça antes do switch

A verificação de fumaça é o gate que autoriza o switch, e ela precisa rodar contra o ambiente novo com tráfego sintético controlado. Cobrir os fluxos de negócio críticos é obrigatório: autenticação, checkout, pagamento, emissores de documentos, tudo que parado gera incidente. Além dos testes funcionais, uma dose de tráfego real espelhado, quando a plataforma oferece espelhamento de requisições, expõe problemas de performance que testes sintéticos não capturam.

# Blue-green no AWS CodeDeploy: roteamento por target group e reversão rápida
Resources:
  ECSDeploymentGroup:
    Type: AWS::CodeDeploy::DeploymentGroup
    Properties:
      ApplicationName: pagamentos-app
      ServiceRoleArn: !GetAtt CodeDeployRole.Arn
      EC2TagFilters:
        - Key: env
          Value: blue-green   # instâncias dos dois ambientes registradas
      BlueGreenDeploymentConfiguration:
        TerminateBlueInstancesOnDeploymentSuccess:
          Action: KEEP_ALIVE          # mantém o ambiente azul após o switch
          TerminationWaitTimeInMinutes: 0
        DeploymentReadyOption:
          Action: STOP_DEPLOYMENT     # pausa no switch para gate manual
          WaitTimeInMinutes: 60
      TrafficRouting:
        TimeBasedCanary:
          Type: TIMEBASED_CANARY      # alternativa: ALL_AT_ONCE puro
          Percentage: 100
          IntervalInMinutes: 0
      GreenFleetProvisioningOption:
        Action: DISCOVER_EXISTING     # ambiente verde já provisionado

O perfil clássico de operação mantém o ambiente azul vivo por horas ou dias após o switch, como apólice de seguro. Só então a execução encerra ou congela os recursos antigos. A política de pausa no switch, como a Action STOP_DEPLOYMENT do exemplo, permite que um humano ou um sistema de análise aprove a virada, o que eleva a confiança em deploys de alto impacto.

Em Kubernetes, a implementação comum usa dois Deployments com rótulos de cor e um Service cujo selector é alternado pelo pipeline.

# Blue-green em Kubernetes: Service aponta para a cor ativa
apiVersion: v1
kind: Service
metadata:
  name: pagamentos
spec:
  selector:
    app: pagamentos
    slot: blue       # o pipeline altera este rótulo para green no switch
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: pagamentos-green          # Deployment da versão nova, ainda frio
spec:
  replicas: 6                     # mesma capacidade do ambiente azul
  selector:
    matchLabels:
      app: pagamentos
      slot: green
  template:
    metadata:
      labels:
        app: pagamentos
        slot: green
    spec:
      containers:
        - name: api
          image: registry.internal/pagamentos:v2.5.0
          readinessProbe:
            httpGet:
              path: /healthz/ready
              port: 8080

O switch é a edição de um único campo, o slot do selector, seguida da conferência dos endpoints do Service. A reversão é a mesma edição apontando de volta, com efeito imediato. O custo do modelo aparece nos replicas duplicados: enquanto o verde existe, o cluster paga duas frotas, e a capacidade do cluster precisa comportar o pico de ambos os ambientes somados.

O banco de dados como ponto de acoplamento

O ponto mais delicado do blue-green é que os ambientes são dois, mas o banco de dados costuma ser um. Ambas as versões escrevem no mesmo schema no momento do switch, e o rollback traz de volta código antigo sobre dados já modificados pelo código novo. A consequência prática é que a disciplina de compatibilidade não é opcional: a migração precisa ser aditiva, o código novo precisa tolerar ausência de dados novos, e o código antigo precisa tolerar presença deles.

• Migração destrutiva no deploy encerra o direito de rollback, porque os dados não voltam com o switch.
• Colunas obrigatórias novas precisam de default ou nulidade temporária, já que o ambiente antigo não as preenche.
• Novos campos em payloads de eventos e filas precisam ser ignoráveis pelo consumidor antigo.
• O ideal a longo prazo é dissociar de vez, com banco por ambiente durante o deploy e sincronização por replicação ou CDC, porém o custo e a complexidade só se justificam em sistemas de altíssima criticidade.

O regime expand and contract, usado pelo rolling update, se aplica integralmente aqui, com a diferença de que a janela de coexistência do blue-green é mais curta e a concentração da transição é maior. Depois do switch, ainda existem requisições em curso na versão antiga, o que exige drenagem ou tolerância a alguns segundos de composição mista.

Rollback em segundos e aquecimento

O rollback do blue-green é o reverso imediato do switch: apontar o tráfego de volta ao ambiente antigo, que permanece íntegro e aquecido. Em comparação, o rolling update reverte onda por onda, e o canary reverte por ajuste de peso, ambos na casa dos minutos. Essa diferença é o argumento central da estratégia para sistemas onde cada segundo de erro tem preço, como plataformas de pagamento, leilões e processamento regulatório.

O aquecimento do ambiente verde é o requisito mais negligenciado. Um ambiente recém-ativado sofre o frio de caches vazios, pools de conexão por estabelecer, instâncias escalando e conexões TLS novas em todas as chamadas de saída. Transferir tráfego cheio para um ambiente frio produz uma rajada de latência que falso-motiva o rollback. As contramedidas são pré-carregar caches com consultas quentes, abrir pools antecipadamente, pré-aquecer instâncias e fazer o switch com rampa de alguns minutos em vez de corte seco, quando a plataforma permite roteamento por porcentagem.

Aplicação prática e comparação

O blue-green se aplica melhor quando o custo do rollback lento supera o custo da infraestrutura duplicada, e quando o sistema permite coexistência controlada de versões no momento do switch. Em Kubernetes, a implementação usual combina dois Deployments e a alternância de selector de um Service, ou dois target groups atrás de um load balancer gerenciado por pipeline. A tabela resume o posicionamento frente às demais estratégias.

Erros comuns e boas práticas

Os fracassos do blue-green quase nunca estão no switch, e sim na preparação dos ambientes e no banco.

• Ambientes que divergem silenciosamente em configuração, versão de dependência ou capacidade, fazendo o switch mover o tráfego para algo que não é equivalente; infraestrutura como código e mesma receita de provisionamento eliminam o problema na raiz.
• Aquecimento ignorado, transformando o primeiro minuto pós-switch em um incidente de latência autoprovocado.
• Migração destrutiva ou restritiva junto do deploy, invalidando o rollback que é a razão de existir da estratégia.
• Encerramento apressado do ambiente antigo, antes do burn-in, deixando a reversão dependente de reprovisionamento demorado.
• Tráfego em sessões persistentes sem drenagem, cortando requisições de clientes conectados ao ambiente desativado.
• Gate de fumaça inexistente ou fraco, aprovando o switch com base só nos testes de unidade do pipeline.

Entre as boas práticas, automatize todo o ciclo no pipeline, do provisionamento do verde ao registro do switch, com verificação de fumaça obrigatória e política de pausa explícita. Mantenha o ambiente antigo de pé por uma janela de observação definida em contrato, e só então encerre. Trate o schema como contrato entre ambientes com expand and contract, e meça o custo da duplicação para decidir periodicamente se o perfil do serviço ainda justifica o modelo; serviços com deploys triviais se saem melhor com rolling update, e serviços que exigem exposição gradual real evoluem para canary.