Estratégias de deploy: Blue/Green, Canary e Rolling

1. Introdução às Estratégias de Deploy

1.1. O que são estratégias de deploy e por que são essenciais para a confiabilidade

Estratégias de deploy definem como uma nova versão de software é promovida para produção. Em sistemas modernos, onde a disponibilidade 24/7 é mandatória, o deploy não pode mais ser um evento de parada programada. As estratégias garantem que a transição entre versões ocorra com o mínimo de impacto ao usuário final, mantendo a integridade dos dados e a continuidade do serviço.

1.2. Riscos de deploys tradicionais

Deploys sem estratégia — como substituir todos os servidores de uma vez — expõem a aplicação a:
- Downtime total durante a janela de substituição
- Falhas em cascata se a nova versão contiver bugs críticos
- Regressão de funcionalidades sem possibilidade de rollback rápido
- Perda de sessões e dados em memória quando instâncias são derrubadas abruptamente

1.3. Visão geral das três abordagens

Estratégia Mecanismo Rollback Complexidade
Rolling Substituição gradual de instâncias Médio (reverte gradualmente) Baixa
Blue/Green Troca entre ambientes completos Imediato (reverte roteamento) Média
Canary Liberação percentual com métricas Rápido (corta tráfego da nova versão) Alta

2. Rolling Update: Atualização Gradual e Controlada

2.1. Conceito

O Rolling Update substitui instâncias/pods uma a uma (ou em pequenos lotes), mantendo a capacidade total do sistema durante todo o processo. Enquanto novas instâncias sobem, as antigas são gradualmente descomissionadas.

2.2. Parâmetros-chave

Em Kubernetes, os parâmetros críticos são:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-producao
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # Máximo de pods extras durante o update
      maxUnavailable: 1  # Máximo de pods indisponíveis por vez
  template:
    spec:
      containers:
      - name: app
        image: minhaapp:2.0.0
  • maxSurge: Quantos pods podem ser criados acima do número desejado (ex: 2 significa até 12 pods rodando durante o update)
  • maxUnavailable: Quantos pods podem ficar indisponíveis simultaneamente (ex: 1 significa que no mínimo 9 pods devem estar saudáveis)

2.3. Prós e contras

Prós:
- Implementação nativa no Kubernetes (sem ferramentas extras)
- Sem custo de infraestrutura duplicada
- Ideal para sistemas com múltiplas réplicas

Contras:
- Detecção lenta de falhas (apenas uma fração dos usuários é afetada por vez)
- Rollback demorado (precisa reverter gradualmente)
- Difícil de isolar problemas específicos da nova versão

3. Blue/Green Deploy: Troca Instantânea entre Ambientes

3.1. Conceito

Mantém dois ambientes completos e idênticos:
- Blue: ambiente de produção atual
- Green: novo ambiente com a versão candidata

O tráfego é roteado inteiramente para um deles via load balancer.

3.2. Fluxo de execução

# Passo 1: Deploy da versão 2.0 no ambiente Green
kubectl apply -f deployment-green.yaml

# Passo 2: Validar que o Green está saudável
kubectl get pods -l version=2.0
kubectl exec -it pod-green-xxx -- curl http://localhost:8080/health

# Passo 3: Trocar o Service para apontar para o Green
kubectl patch service app-service -p '{"spec":{"selector":{"version":"2.0"}}}'

# Passo 4: (Opcional) Manter Blue por rollback
# Se precisar reverter, basta trocar o selector de volta para "1.0"

3.3. Prós e contras

Prós:
- Rollback imediato (troca de roteamento em segundos)
- Testes completos no ambiente Green antes de receber tráfego real
- Zero downtime durante a transição

Contras:
- Custo de infraestrutura duplicada (2x servidores, 2x banco de dados)
- Complexidade com estado compartilhado (migrações de banco precisam ser compatíveis)
- Maior consumo de recursos durante a janela de deploy

4. Canary Deploy: Liberação Gradual e Métrica

4.1. Conceito

Libera a nova versão para um subconjunto de usuários (ex: 5%, depois 20%, depois 100%), monitorando métricas em cada etapa. Apenas quando a confiança é alta, o tráfego total é transferido.

4.2. Mecanismos de controle

# Exemplo com Flagger + Istio
apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: app-canary
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  service:
    port: 8080
  analysis:
    interval: 1m           # Verifica a cada 1 minuto
    threshold: 5           # Máximo de falhas antes de abortar
    maxWeight: 50          # Máximo de tráfego no canary (50%)
    stepWeight: 10         # Incremento de 10% por etapa
    metrics:
    - name: request-success-rate
      thresholdRange:
        min: 99            # Mínimo de 99% de sucesso
    - name: request-duration
      thresholdRange:
        max: 500           # Latência máxima de 500ms (P99)

4.3. Prós e contras

Prós:
- Detecção precoce de problemas com impacto limitado
- Validação de performance com tráfego real
- Ideal para testes A/B e validação de métricas de negócio

Contras:
- Alta complexidade de configuração (Service Mesh, métricas, automação)
- Requer ferramentas especializadas (Istio, Flagger, Argo Rollouts)
- Amostra estatística pequena pode esconder bugs raros

5. Comparação Técnica e Casos de Uso

5.1. Tabela comparativa

Característica Rolling Blue/Green Canary
Tempo de rollback Minutos Segundos Segundos
Impacto no usuário Baixo (parcial) Zero Muito baixo
Custo operacional Baixo Alto (2x infra) Médio (ferramentas)
Complexidade de configuração Baixa Média Alta
Detecção de falhas Lenta Pré-deploy Em tempo real

5.2. Quando escolher Rolling

  • Sistemas com muitas réplicas (10+)
  • Aplicações stateless sem estado crítico
  • Equipes pequenas sem orçamento para infraestrutura duplicada

5.3. Quando escolher Blue/Green ou Canary

Blue/Green:
- Sistemas críticos onde rollback imediato é obrigatório (bancos, pagamentos)
- Aplicações com estado que exigem validação completa antes do corte
- Cenários com picos de tráfego previsíveis

Canary:
- Testes A/B e experimentação de funcionalidades
- Validação de performance com tráfego real antes do full release
- Sistemas com Service Mesh já implementado

6. Implementação Prática com Kubernetes

6.1. Rolling Update nativo

# Aplicar uma nova versão
kubectl set image deployment/app app=minhaapp:3.0.0

# Acompanhar o progresso
kubectl rollout status deployment/app

# Reverter para versão anterior
kubectl rollout undo deployment/app

6.2. Blue/Green com Services e labels

# Service que seleciona pelo label "active: true"
apiVersion: v1
kind: Service
metadata:
  name: app-service
spec:
  selector:
    app: minhaapp
    active: "true"
  ports:
  - port: 80
    targetPort: 8080

# Deploy Blue (versão 1.0)
kubectl label deployment app-blue active=true
kubectl label deployment app-green active=false

# Deploy Green (versão 2.0) e depois trocar
kubectl label deployment app-blue active=false
kubectl label deployment app-green active=true

6.3. Canary com Service Mesh (Istio)

# VirtualService para roteamento percentual
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-vs
spec:
  hosts:
  - app
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"   # Apenas usuários com header específico
    route:
    - destination:
        host: app-canary
        subset: v2
      weight: 100
  - route:
    - destination:
        host: app-stable
        subset: v1
      weight: 90
    - destination:
        host: app-canary
        subset: v2
      weight: 10

7. Melhores Práticas e Armadilhas Comuns

7.1. Automatização de health checks

Todo deploy deve incluir:
- Readiness probe: verifica se o pod está pronto para receber tráfego
- Liveness probe: verifica se o pod ainda está saudável
- Testes de integração automatizados antes de liberar tráfego

7.2. Monitoramento de métricas

Métricas essenciais durante o deploy:
- Taxa de erro HTTP (5xx) — deve ficar abaixo de 1%
- Latência P99 — não deve aumentar mais que 10%
- Taxa de sucesso de health checks — 100%

7.3. Armadilhas comuns

  • Esquecer de limpar ambientes Blue/Green antigos: custo desnecessário e risco de confusão
  • Canary com pouca amostra: bugs que afetam 1% dos usuários podem passar despercebidos em um canary de 5%
  • Migrações de banco incompatíveis: Blue/Green e Canary exigem compatibilidade bidirecional de schema
  • Ignorar cache e CDN: mudanças no backend podem não refletir imediatamente se o cache não for invalidado

8. Conclusão e Próximos Passos

8.1. Resumo das estratégias

  • Rolling: simples e barato, mas lento para detectar e reverter falhas
  • Blue/Green: rollback imediato com custo de infraestrutura duplicada
  • Canary: controle granular com métricas, mas alta complexidade

8.2. Como evoluir

Para deploys mais avançados, combine estratégias com:
- Feature flags: libere funcionalidades independentemente do deploy
- Dark launches: execute código novo sem expor ao usuário
- Progressive delivery: integre Canary com automação de métricas de negócio

8.3. Referência aos temas vizinhos

Esta estratégia se conecta diretamente a temas como ConfigMaps para configuração dinâmica, autoscaling para lidar com picos durante o deploy, e namespaces para isolar ambientes Blue/Green.

Referências