Estratégias de Deploy — blue-green, canary, rolling e feature flags

Em 2012, o Amazon Prime Video sofreu um incidente durante um deploy que derrubou o serviço por 49 minutos. A causa era um simples bug introduzido na versão nova que não havia sido detectado nos testes — e o deploy havia substituído todas as instâncias de uma vez. O rollback demorou porque o processo de deploy era lento. Se o deploy tivesse sido incremental — enviando tráfego progressivamente para a nova versão enquanto monitorava erros — o impacto teria sido limitado a uma fração dos usuários por poucos minutos antes da detecção.

A estratégia de deploy determina o perfil de risco de uma entrega: quanta superfície de usuários é exposta ao novo código e por quanto tempo antes que problemas possam ser detectados e revertidos. Não existe estratégia universalmente correta — cada uma tem trade-offs que dependem do contexto: tipo de mudança, volume de tráfego, tolerância a risco, e capacidade de rollback.

Rolling deploy — o padrão default do Kubernetes

Rolling deploy é o comportamento padrão de um Kubernetes Deployment: substituir gradualmente pods da versão antiga por pods da nova versão, mantendo um número mínimo de pods disponíveis durante o processo.

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2          # criar até 2 pods além do desejado durante o update
      maxUnavailable: 0    # nunca remover um pod antes de ter um novo pronto

Com maxUnavailable: 0 e maxSurge: 2, o processo é: criar 2 novos pods (versão nova) → esperar ficarem prontos → remover 2 pods antigos → repetir até substituir todos. Em nenhum momento o sistema fica abaixo de 10 pods disponíveis.

O problema do rolling deploy: durante a transição, ambas as versões estão em produção simultaneamente. Se a nova versão introduz uma mudança incompatível no formato de resposta de uma API, usuários terão respostas inconsistentes dependendo de qual pod serviu a request. Mudanças backward-incompatíveis exigem uma das outras estratégias.

Blue-green — switch instantâneo

Blue-green mantém dois ambientes idênticos: blue (produção atual) e green (nova versão). O deploy é atomicamente feito mudando o switch de tráfego de blue para green:

                    ┌──────────────┐
               ┌────│ Load Balancer │────┐
               │    └──────────────┘    │
        100% →─┤                        ├─→ 0%
               │                        │
          ┌────▼────┐            ┌───────▼─────┐
          │  Blue   │            │    Green    │
          │(v1.0)   │            │  (v1.1)     │
          │ 10 pods │            │  10 pods    │
          └─────────┘            └─────────────┘
                     (switch → green)
          ┌──────────┐           ┌─────────────┐
          │  Blue    │           │    Green    │
          │(v1.0)    │      ←────│  (v1.1)     │
          │ mantido  │  0% traffic  100% traffic
          └──────────┘           └─────────────┘

O rollback em blue-green é instantâneo: basta apontar o load balancer de volta para blue. Isso é único — outras estratégias não oferecem rollback instantâneo com versão anterior completamente preservada.

Em Kubernetes, blue-green pode ser implementado com dois Deployments e alterando o selector do Service:

# Deployment blue (produção atual)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: meu-app-blue
spec:
  template:
    metadata:
      labels:
        app: meu-app
        version: blue

---
# Deployment green (nova versão)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: meu-app-green
spec:
  template:
    metadata:
      labels:
        app: meu-app
        version: green

---
# Service — aponta para blue ou green
apiVersion: v1
kind: Service
metadata:
  name: meu-app
spec:
  selector:
    app: meu-app
    version: blue    # ← mudar para "green" para o switch

O custo de blue-green é o dobro da infraestrutura durante o período de transição. Para sistemas grandes, isso pode ser proibitivo. Em cloud com auto-scaling, o custo é temporário — mas para databases ou sistemas stateful com custo fixo alto, blue-green pode não ser viável.

Canary deploy — exposição progressiva com dados

Canary deploy expõe a nova versão para uma fração do tráfego, monitorando métricas antes de expandir. O nome vem dos canários usados em minas de carvão — se o canário morre, há problema.

                    ┌──────────────┐
                    │ Load Balancer│
                    └──────┬───────┘
                           │
              90% ─────────┼────────── 10%
               ↓           │           ↓
          ┌─────────┐      │      ┌──────────┐
          │Stable   │      │      │ Canary   │
          │(v1.0)   │      │      │ (v1.1)   │
          │ 9 pods  │      │      │ 1 pod    │
          └─────────┘      │      └──────────┘
                           │
                    Monitorar:
                    - Error rate
                    - Latência p99
                    - Métricas de negócio

Em Kubernetes com Argo Rollouts (ou NGINX/Istio para controle de tráfego), o processo é automatizado com progressive delivery:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: meu-app
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10     # 10% do tráfego para a nova versão
        - pause: {duration: 10m}   # esperar 10 minutos
        - analysis:         # verificar métricas automaticamente
            templates:
              - templateName: success-rate
        - setWeight: 50     # 50% se análise passou
        - pause: {duration: 20m}
        - analysis:
            templates:
              - templateName: success-rate
        - setWeight: 100    # 100% — promoção completa

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 5m
      successCondition: result[0] >= 0.99   # 99% de sucesso
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{status!~"5..",app="meu-app",version="canary"}[5m]))
            /
            sum(rate(http_requests_total{app="meu-app",version="canary"}[5m]))

O Argo Rollouts reverte automaticamente se a análise falhar — sem intervenção humana. O canário detectou o problema antes de atingir 100% dos usuários.

Feature flags — deploy desacoplado de release

Feature flags (ver Conceito 04) são a estratégia ortogonal a todas as outras: você pode fazer um rolling deploy de código novo, mas a feature nova está desabilitada — o "deploy" e o "release" são eventos separados.

Esse desacoplamento resolve um problema fundamental: qualquer uma das estratégias acima muda a versão do código para todos os usuários ao mesmo tempo (ou progressivamente). Feature flags permitem rollout por segmento:

• Habilitar para 1% dos usuários por 24h → sem problemas → 10% → 100%
• Habilitar apenas para beta testers ou usuários premium
• Habilitar apenas em uma região geográfica
• Habilitar instantaneamente ou reverter sem nenhum deploy

A combinação de canary deploy + feature flags é o estado da arte: o canary deploy garante que o código novo não tem regressões técnicas (erros, latência), e o feature flag controla a exposição de negócio da nova funcionalidade.

Database migrations sem downtime — expand-contract

O maior desafio de deploy sem downtime é banco de dados: migrations que renomeiam colunas, mudam tipos, ou removem campos são backward-incompatíveis com a versão anterior da aplicação.

O padrão expand-contract (também chamado de parallel change) resolve isso em três fases:

Fase 1 — Expand (deploy 1): adicionar a nova coluna, manter a antiga. A nova versão escreve em ambas, lê da antiga.

-- Migration: adicionar coluna nova, manter antiga
ALTER TABLE users ADD COLUMN full_name VARCHAR(500);

-- Application code v2 (durante Expand)
-- Escreve em ambas:
UPDATE users SET name = $1, full_name = $2 WHERE id = $3

-- Lê da antiga (compatível com v1 ainda em pods durante rolling deploy):
SELECT name FROM users WHERE id = $1

Fase 2 — Migrate (script ou deploy 2): preencher a nova coluna com dados da antiga para todos os registros existentes. A nova versão agora lê da nova coluna.

-- Backfill em batches para não causar lock
DO $$
DECLARE
  batch_size INT := 1000;
  offset_val INT := 0;
BEGIN
  LOOP
    UPDATE users
    SET full_name = name
    WHERE id IN (
      SELECT id FROM users
      WHERE full_name IS NULL
      LIMIT batch_size
      OFFSET offset_val
    );
    EXIT WHEN NOT FOUND;
    offset_val := offset_val + batch_size;
    PERFORM pg_sleep(0.1);   -- não exaurir I/O
  END LOOP;
END $$;

Fase 3 — Contract (deploy 3): remover a coluna antiga após confirmar que nenhum pod da versão anterior está rodando.

-- Só fazer isso após confirmar que todos os pods são v3
ALTER TABLE users DROP COLUMN name;

O expand-contract transforma uma migration backward-incompatível em três mudanças backward-compatíveis. O custo é o tempo (3 deploys em vez de 1) e o espaço temporário de manter duas colunas. Para tabelas muito grandes, a fase de backfill pode levar horas — nesse caso, ferramentas como pg_repack ou Percona Online Schema Change ajudam a fazer a mudança sem locks prolongados.

Comparação de estratégias

Decisões de engenharia

Perguntas de entrevista

Exercícios práticos