Estratégias de release e rollback

As estratégias

• Rolling: substitui instâncias poucas por vez. Simples e o padrão na maioria dos orquestradores; versões antigas e novas rodam lado a lado por um tempo.
• Blue/green: mantém dois ambientes completos e troca o tráfego do antigo (blue) para o novo (green) de uma vez. O rollback é voltar a chave; custa o dobro de capacidade durante a troca.
• Canary: envia uma pequena parcela do tráfego para a nova versão, observa as métricas e depois amplia. Limita o raio de impacto de um release ruim.
• Feature flags: entregam o código desativado e o ativam por usuário, percentual ou ambiente. Separam deploy de release e dão um botão instantâneo de desligar.
• Shadow traffic: copia requisições reais para a nova versão sem devolver suas respostas, para comparar o comportamento com segurança.

Rollback é uma decisão de design

• Mantenha o artefato anterior pronto para deploy e faça deploy por versão imutável ou digest.
• Torne as mudanças de banco de dados retrocompatíveis (expand, migrate, contract), para que o código antigo continue funcionando com o novo schema.
• Decida com antecedência qual métrica dispara um rollback e automatize-o onde puder.
• Pratique o rollback: um rollback não testado é uma esperança.

Exemplo: um rollout canary

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 6
  selector:
    matchLabels: { app: api }
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: { duration: 5m }
        - setWeight: 50
        - pause: { duration: 10m }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api@sha256:<digest>

Escolhendo