Padrões de deploy blue-green e canary em ambientes produtivos

1. Fundamentos dos padrões de deploy modernos

Por que deploy não é mais "subir arquivo via FTP"

O deploy tradicional — subir arquivos via FTP, substituir binários manualmente ou executar scripts em servidores de produção — está obsoleto. Essas práticas introduzem risco de inconsistência, downtime prolongado e rollback complexo. As estratégias modernas de liberação controlada (blue-green, canary, rolling update) automatizam o processo via pipelines CI/CD, garantindo que cada versão passe por validações antes de atingir os usuários.

Risco zero não existe: mitigando impacto com padrões

Todo deploy carrega risco. A diferença está no blast radius — o alcance do impacto em caso de falha. Blue-green e canary reduzem esse raio, permitindo que você defina um downtime budget aceitável. O trade-off é claro: velocidade de entrega vs. segurança. Padrões modernos equilibram ambos.

Pré-requisitos técnicos

Para implementar blue-green e canary, você precisa de:
- Balanceador de carga (NGINX, HAProxy, AWS ALB, Kubernetes Ingress)
- DNS ou IP virtual para roteamento
- Health checks automatizados (liveness/readiness probes)
- Feature flags ou mecanismos de segmentação de tráfego

2. Padrão blue-green: ambientes gêmeos para troca instantânea

Arquitetura básica

Blue-green mantém dois ambientes idênticos: o azul (versão atual) e o verde (nova versão). Apenas um recebe tráfego de produção por vez. O roteamento é feito via load balancer, que alterna o destino.

Desafio crítico: sincronia de banco de dados. Se a nova versão modifica o schema, a versão antiga deve continuar funcionando. Soluções incluem migrações retrocompatíveis ou dual-writes.

Fluxo de deploy passo a passo

  1. Prepare o ambiente verde (inativo) com a nova versão
  2. Execute health checks e smoke tests no ambiente verde
  3. Troque o tráfego do load balancer do azul para o verde
  4. Valide a versão verde em produção
  5. Mantenha o azul por um período de observação (cooldown)
  6. Descarte o ambiente azul ou reutilize para o próximo deploy

Vantagens e limitações

Vantagens: rollback instantâneo (basta reverter o roteamento), zero downtime, deploy previsível.

Limitações: custo dobrado de infraestrutura (dois ambientes completos), problemas com migrações de banco de dados não retrocompatíveis (ex.: remover colunas que a versão antiga ainda usa).

3. Padrão canary: liberação gradual e observabilidade

Conceito

Canary expõe a nova versão a um subconjunto de usuários, aumentando gradualmente o percentual. Percentuais típicos: 1%, 5%, 10%, 50%, 100%. A progressão depende de métricas de saúde.

Segmentação: por usuário (cookie, ID), região geográfica, faixa de IP, ou aleatoriamente com peso.

Implementação com balanceadores de carga

Exemplo de roteamento ponderado com NGINX:

upstream backend {
    server app-v1.example.com weight=90;
    server app-v2.example.com weight=10;
}

Com service mesh (Istio):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-canary
spec:
  hosts:
  - app.example.com
  http:
  - route:
    - destination:
        host: app-v1
        weight: 90
    - destination:
        host: app-v2
        weight: 10

Métricas críticas para promover ou abortar

  • Taxa de erro HTTP (4xx/5xx)
  • Latência percentil 95/99
  • Throughput (requests por segundo)
  • Logs de exceção do backend

Gatilho automático de rollback: se a taxa de erro 5xx aumentar 5% em relação à versão estável, o canary é abortado automaticamente.

4. Comparação direta: blue-green vs. canary

Característica Blue-Green Canary
Risco Baixo (troca total) Muito baixo (gradual)
Velocidade de rollout Instantânea Lenta (horas/dias)
Custo de infraestrutura Alto (2x) Baixo (1x + overhead)
Complexidade de monitoramento Baixa Alta
Rollback Imediato Imediato (abortar progressão)

Quando usar cada padrão:
- Blue-green: releases grandes, mudanças estruturais, compliance rigoroso (ex.: PCI DSS)
- Canary: features arriscadas, testes A/B, validação de performance em produção

Cenário híbrido: blue-green com canary interno — o ambiente azul recebe 10% do tráfego antes da troca total, combinando os dois padrões.

5. Implementação prática com ferramentas comuns

Deploy blue-green com Kubernetes e Ingress Controller

# Criar deployment da versão verde
kubectl apply -f deployment-v2.yaml

# Aguardar health checks
kubectl rollout status deployment/app-v2

# Trocar o service para apontar para o novo deployment
kubectl patch service app -p '{"spec":{"selector":{"version":"v2"}}}'

# Validar e depois remover o deployment antigo
kubectl delete deployment app-v1

Deploy canary com Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: app-canary
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 10m}
      - setWeight: 100
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
      - name: app
        image: app:v2

Automação com CI/CD (GitLab CI)

stages:
  - deploy-canary
  - promote

deploy-canary:
  stage: deploy-canary
  script:
    - kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
    - kubectl annotate deployment/app canary=true
  only:
    - main

promote:
  stage: promote
  script:
    - kubectl annotate deployment/app canary=false
    - kubectl rollout status deployment/app
  when: manual

6. Armadilhas comuns e como evitá-las

Estado compartilhado: banco de dados, cache e sessões

Migrações de banco de dados devem ser retrocompatíveis (expansão antes de contração). Exemplo: adicionar coluna nova, depois migrar dados, depois remover coluna antiga. Cache e sessões devem ser compartilhados entre versões ou invalidados.

Testes insuficientes no ambiente inativo

Sempre execute smoke tests automatizados e synthetic monitoring no ambiente inativo antes da troca. Ferramentas como Checkly, Grafana Synthetic Monitoring ou scripts curl com health checks.

Falsa sensação de segurança

Blue-green não protege contra bugs de lógica que afetam ambas as versões (ex.: erro no banco de dados compartilhado). Canary pode mascarar problemas de escalabilidade se a amostra for pequena — um bug que só aparece com 1000 req/s pode não ser detectado com 1% do tráfego.

7. Estratégias de rollback dentro dos padrões

Rollback em blue-green

Simples reversão de tráfego no load balancer. Tempo de recuperação: segundos. Exemplo com NGINX:

# Reverter para a versão azul
upstream backend {
    server app-v1.example.com weight=100;
    server app-v2.example.com weight=0;
}

Rollback em canary

Abortar a progressão e redirecionar 100% do tráfego para a versão estável. Cuidado com thundering herd ao reverter rapidamente — use circuit breakers ou ramp-up reverso.

Registro de estado e audit trail

Cada deploy deve gerar logs com: versão, timestamp, percentual de tráfego, métricas no momento da troca. Ferramentas como AWS CloudTrail, GitLab Audit Events ou logs estruturados no SIEM.

8. Tendências e evolução dos padrões de deploy

Feature flags como camada adicional

Combinar feature flags com blue-green/canary permite liberar funcionalidades por usuário sem novo deploy. Ferramentas: LaunchDarkly, Unleash, Flagsmith.

Deploy progressivo multi-estágio

Combinação de canary + shadow testing (espelhar tráfego para a nova versão sem afetar usuários) + dark launches (ativar funcionalidades ocultas para teste interno).

Serverless e deploy imutável

Em plataformas serverless (AWS Lambda, Cloud Run), o deploy é imutável — cada versão é uma nova função/container. Blue-green é simplificado (troca de alias), mas canary exige configuração de tráfego ponderado (ex.: Lambda aliases com weights).

Referências