Estratégias de deploy 2026: Blue-Green vs Canary vs Rolling

Não existe uma única melhor estratégia de deploy. Rolling updates são o padrão para serviços stateless porque não custam nada a mais; blue-green é a escolha certa quando você precisa de rollback instantâneo do sistema inteiro; releases canary compensam a complexidade quando um release ruim sairia caro e você tem métricas boas o bastante para pegá-lo. Feature flags, shadow traffic e recreate cobrem os casos restantes. Cada estratégia difere em quatro eixos: quantas versões rodam ao mesmo tempo, quem vê a nova e quando, quão rápido dá para voltar e quanto custa. Este guia cobre cada estratégia, como rodá-la em Kubernetes, serverless e bancos de dados, e como escolher uma.

Rolling deployment: o padrão para serviços stateless

Um rolling update substitui instâncias antigas por novas em lotes. Em qualquer momento, algumas instâncias rodam v1 e outras v2, e o load balancer manda tráfego para as duas. A capacidade fica perto do normal e nenhum ambiente extra é necessário.

No Kubernetes, esse é o comportamento nativo de um Deployment. Dois campos controlam isso: maxSurge (quantos pods extras podem existir acima do número desejado) e maxUnavailable (quantos pods podem ficar fora durante a atualização). Os dois têm 25% como padrão.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # um pod extra por vez
      maxUnavailable: 0    # nunca cair abaixo de 6 pods prontos
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: checkout
          image: registry.example.com/checkout:2.4.0
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8080 }
          lifecycle:
            preStop:
              exec: { command: ["sleep", "5"] }

Três coisas fazem ou quebram um rolling update:

• Readiness probes. O pod novo não pode receber tráfego até conseguir atender. Sem probe, o Kubernetes considera o container pronto no instante em que ele sobe.
• Graceful shutdown. O sleep no preStop dá tempo para o endpoint controller remover o pod do Service antes do SIGTERM chegar. Depois disso, seu processo precisa terminar as requisições em andamento dentro de terminationGracePeriodSeconds.
• Compatibilidade. v1 e v2 atendem requisições lado a lado, então contratos de API, formatos de cache, schemas de mensagem e schema de banco precisam funcionar para as duas.

Rolling tem duas fraquezas: não há gate entre lotes além de "os pods ficaram prontos", então uma versão que sobe bem mas devolve respostas erradas vai até o fim; e o rollback (kubectl rollout undo) é outro rolling update, então demora tanto quanto o rollout demorou.

Blue-green deployment: virada instantânea, rollback instantâneo

Blue-green mantém dois ambientes completos. Blue atende produção; green recebe a nova versão, é testado contra dependências reais e então assume todo o tráfego em uma única virada. Blue fica no ar até você ter confiança, e depois vira o alvo do próximo release.

A virada em si é a decisão de design principal:

Mecanismo de virada	Tempo de cutover	Observações
Target group do load balancer / backend do Ingress	Segundos	Preferido; preciso e reversível
Rota de service mesh (Istio, Linkerd)	Segundos	Também permite um passo canary antes da virada completa
Troca de selector do Service no Kubernetes	Segundos	Simples; funciona sem ferramenta extra
Registro DNS	Minutos a horas	Depende de TTL e cache dos clientes; evite para rollback

No Kubernetes, a versão mínima são dois Deployments (checkout-blue, checkout-green) e um Service cujo selector você troca de version: blue para version: green. O Argo Rollouts formaliza isso com strategy.blueGreen, que gerencia um Service ativo e um de preview, roda análise opcional contra o preview e pode esperar uma promoção manual (autoPromotionEnabled: false).

Blue-green encaixa bem quando:

• Você precisa de rollback do sistema inteiro medido em segundos, por exemplo em pagamentos, venda de ingressos ou cargas reguladas com janelas de mudança explícitas.
• Vários serviços precisam virar juntos e um estado misto v1/v2 não é aceitável.
• Você quer rodar um teste de integração ou de carga completo contra a infraestrutura de produção antes de expor usuários.

Os custos: capacidade dobrada durante a virada, as mesmas regras de banco do rolling (a virada pode ser revertida, então green não pode gravar dados que blue não consiga ler) e o esvaziamento de conexões longas do lado antigo.

Releases canary e progressive delivery

Um canary envia uma fatia pequena do tráfego, geralmente 1–5%, para a nova versão, observa as métricas por uma janela fixa e então aumenta a fatia passo a passo. Se uma métrica estourar o limite em qualquer passo, o tráfego volta automaticamente para a versão estável. O rollout é guiado por evidência, não pelo relógio.

O Kubernetes nativo não faz isso. Um Deployment com duas réplicas de v2 e dezoito de v1 dá mais ou menos 10% de tráfego, mas você não consegue fixar a divisão, e ela se move conforme os pods são reagendados. Divisão precisa exige uma destas opções:

• Argo Rollouts, um substituto do Deployment com um bloco strategy.canary, um plugin de roteamento de tráfego para seu Ingress, Gateway API ou mesh, e recursos AnalysisTemplate que consultam Prometheus, Datadog, New Relic, CloudWatch ou um webhook.
• Flagger, um operator que deixa seu Deployment intocado, cria uma cópia primária e manipula os pesos do mesh ou do Ingress com base em checagens de métricas definidas em um recurso Canary.
• Um mesh ou HTTPRoute da Gateway API com backends ponderados, controlado pelo seu próprio pipeline. Funciona, mas você está reconstruindo o loop de análise por conta própria.

Uma definição de passos canary com Argo Rollouts fica assim:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: checkout-canary
      stableService: checkout-stable
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: checkout-route
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: error-rate-and-latency
        - setWeight: 25
        - pause: { duration: 15m }
        - setWeight: 50
        - pause: {}            # promoção manual a partir daqui

O AnalysisTemplate referenciado acima é onde o trabalho de verdade acontece. Um bom template compara o canary com a versão estável na mesma janela, não com um número fixo: taxa de erro, latência p95 ou p99 e um sinal de negócio, como sucesso no checkout. Defina a condição de falha sobre o delta e exija que a métrica fique ruim por mais de um intervalo antes de abortar, ou o ruído normal vai reprovar releases saudáveis.

Canary é a estratégia mais poderosa e a mais exigente. Você precisa de labels de métrica que distingam canary de estável, tráfego suficiente para que uma fatia de 5% produza números significativos e roteamento sticky se um usuário atingindo as duas versões quebrar alguma coisa. Para serviços de baixo tráfego, use blue-green ou flags.

Feature flags, dark launches, shadow traffic e recreate

Feature flags separam deploy de release. O código sobe apagado, atrás de uma flag desligada, e o time a liga para usuários internos, depois para uma porcentagem, depois para um segmento como um plano ou um país. A infraestrutura roda uma versão; a flag decide o comportamento. É a única estratégia que mira usuários em vez de requisições, e permite que vários times entreguem mudanças independentes no mesmo deploy. O custo é higiene de código: flags precisam ser removidas quando estiverem 100% ligadas, e uma flag avaliada em um hot path precisa de cache local, nunca de chamada de rede. Veja feature flags, estratégias de deploy e testes A/B para os detalhes operacionais.

Shadow (espelhamento de tráfego) envia uma cópia das requisições reais para a nova versão e descarta as respostas. Os usuários veem só a versão estável; o time compara logs, latência e taxas de erro entre as duas. Istio e Envoy suportam espelhamento nativamente; o Argo Rollouts expõe isso como setMirrorRoute. Shadowing é excelente para validar uma reescrita ou uma nova dependência sob carga real, mas só para leituras. Escritas espelhadas duplicariam efeitos colaterais, então a versão shadow precisa do próprio armazenamento ou de um stub idempotente para qualquer coisa que mude estado.

Recreate para todas as instâncias antigas e só depois sobe as novas. Sempre tem downtime, então só é a escolha certa quando duas versões realmente não podem coexistir: um scheduler singleton, um serviço segurando um lock exclusivo, um formato de cache incompatível sem caminho de migração. No Kubernetes, defina strategy.type: Recreate. Faça isso de propósito, com janela de manutenção, não por acidente.

Estratégias de deploy em plataformas serverless e edge

Plataformas serverless dão rolling e canary de graça, mas com controles mais limitados.

• AWS Lambda usa versões de função e aliases. Um alias pode rotear uma fatia ponderada das invocações para uma segunda versão, e o CodeDeploy automatiza a rampa com as configurações Linear (incrementos fixos a cada N minutos), Canary (um passo pequeno, depois tudo) e AllAtOnce, fazendo rollback com base em alarmes do CloudWatch. Provisioned concurrency na nova versão evita cold starts durante a transição.
• Cloud Run guarda todas as revisões e permite dividir o tráfego entre elas por porcentagem ou tag. Fazer deploy com --no-traffic e depois mover gradualmente é um canary; mover 100% de uma vez mantendo a revisão antiga aquecida é blue-green.
• Azure Functions usa deployment slots com swap, que é blue-green por construção.
• Plataformas edge (Cloudflare Workers, Vercel, Netlify) fazem deploy atômico e mantêm os deploys anteriores endereçáveis, então rollback é trocar um ponteiro; o Cloudflare Workers também suporta divisão por porcentagem entre duas versões.

A restrição recorrente no serverless é o estado: qualquer datastore compartilhado por duas versões enfrenta as mesmas regras de compatibilidade do Kubernetes. A plataforma só resolve o lado da computação.

Bancos de dados: a parte que toda estratégia compartilha

Toda estratégia de zero downtime roda duas versões da aplicação contra um banco por algum período, e todo rollback roda a versão antiga contra um schema que a versão nova pode ter alterado. Os dois fatos levam à mesma regra: mudanças de schema precisam ser compatíveis com a versão anterior por pelo menos um release.

O padrão é expand-then-contract:

1. Expand. Adicione a nova coluna, tabela ou índice. Mantenha a antiga. Faça deploy de código que grava nas duas e lê da antiga.
2. Migre. Faça o backfill em lotes, com um job que possa ser pausado e retomado.
3. Vire as leituras. Faça deploy de código que lê da forma nova mas ainda grava nas duas, para que um rollback continue tendo dados válidos.
4. Contract. Quando não for mais possível voltar para o release anterior, pare de gravar na forma antiga e remova-a.

Rode a migração como um passo separado, antes do rollout da aplicação, nunca dentro da inicialização de um pod. No Kubernetes, isso é um Job disparado pelo pipeline ou um pre-step do Argo Rollouts; no serverless, é um estágio do pipeline. Comandos ALTER TABLE longos que tomam locks pertencem a ferramentas como pg-osc, gh-ost ou a criação concorrente de índices do Postgres. O playbook completo, incluindo como lidar com mudanças destrutivas e propriedade entre vários serviços, está em estratégias de migração de banco de dados para ambientes de produção.

A escolha da estratégia afeta o banco de uma forma: quanto mais tempo duas versões coexistem, mais tempo a janela de dual-write fica aberta. Um rolling update de dez minutos tolera uma janela curta; um canary mantido em 50% por um dia, ou uma flag ligada ao longo de semanas, exige que o estado expand seja uma configuração estável e testada.

Tabela comparativa e checklist de decisão

Critério	Rolling	Blue-green	Canary	Feature flags	Shadow	Recreate
Downtime	Nenhum com probes	Nenhum	Nenhum	Nenhum	Nenhum (usuários intocados)	Sim
Velocidade de rollback	Minutos (rollout reverso)	Segundos (virar de volta)	Segundos (peso a 0)	Instantâneo (flag off)	N/A, nada exposto	Minutos mais downtime
Custo extra de infra	Um lote (maxSurge)	Duplicata completa durante a virada	Algumas réplicas	Nenhum	Duplicata para a fatia espelhada	Nenhum
Controle de tráfego	Só pelo número de instâncias	Tudo ou nada	Porcentagem ou header preciso	Por usuário, segmento, plano	Cópia, não roteamento	Nenhum
Complexidade	Baixa; nativo em todo orquestrador	Média; dois ambientes e uma virada	Alta; exige roteador, métricas, análise	Média; serviço de flags e disciplina de limpeza	Alta; exige mesh e isolamento de escrita	Muito baixa
Compatibilidade de banco	Duas versões coexistem brevemente	Duas versões coexistem; virada reversível	Duas versões coexistem por horas ou dias	Uma versão; os dois caminhos da flag precisam ser compatíveis	Shadow não pode gravar	Uma versão; migrações podem quebrar
Melhor para	Serviços stateless, releases pequenos e frequentes	Viradas coordenadas, SLAs de rollback rígidos, janelas reguladas	Serviços de alto tráfego e alto custo de falha com boas métricas	Releases de produto, exposição gradual por segmento, testes A/B	Reescritas, novas dependências, validação de performance	Singletons, upgrades incompatíveis, manutenção agendada

Checklist de decisão

Percorra na ordem. O primeiro "sim" costuma resolver.

• As versões antiga e nova não podem rodar ao mesmo tempo? Recreate, em janela de manutenção. Depois corrija o design para que seja a última vez.
• Você precisa testar contra a infraestrutura de produção antes de qualquer usuário ver a mudança, ou reverter um sistema inteiro em segundos? Blue-green.
• Um release ruim sai caro, e você tem métricas por versão e tráfego suficiente para que uma fatia pequena seja significativa? Canary, com análise automatizada. Sem essas métricas, um canary é um rolling update lento com passos a mais.
• O risco está em um comportamento do produto e não no binário, ou você precisa liberar primeiro para clientes específicos? Feature flags, em cima de qualquer estratégia de infraestrutura que você já use.
• Você está substituindo um serviço ou uma dependência e quer prova de que ele se comporta sob carga real antes de importar? Shadow traffic para leituras, depois uma das opções acima para a virada de verdade.
• Nenhuma das anteriores? Rolling. É o padrão por um motivo.

Duas verificações transversais valem independentemente da resposta:

• Toda estratégia, exceto recreate, exige migrações expand-then-contract. Se o time não consegue se comprometer com isso, nenhum truque de roteamento de tráfego vai tornar o release seguro.
• Readiness probes, graceful shutdown e um rollback que foi de fato ensaiado importam mais que o rótulo da estratégia. Um rolling update bem executado ganha de um canary que ninguém nunca abortou. Conecte o rollback ao mesmo pipeline de CI/CD que faz o deploy, e pratique em staging.
• Estratégias se combinam. Rolling mais flags é o setup SaaS usual; blue-green com um passo canary mantém o rollback rápido e reduz o raio de impacto; shadow seguido de canary é o caminho mais seguro ao migrar sistemas legados peça por peça. Serviços diferentes no mesmo cluster Kubernetes podem usar estratégias diferentes.

Recomendação

Comece com rolling updates e probes bem ajustadas para todo serviço stateless; são de graça e cobrem a maioria dos releases. Adicione feature flags assim que mais de um time entregar no mesmo serviço, para que deploy e release deixem de ser o mesmo evento. Leve um serviço para canary só quando ele tiver tráfego real, métricas por versão e um custo de falha que justifique rodar Argo Rollouts ou Flagger; caso contrário, um canary dá cerimônia sem evidência. Reserve blue-green para viradas coordenadas e sistemas com exigência rígida de rollback, e reserve recreate para o raro singleton. Seja qual for a escolha, trate o banco de dados como a restrição que manda: migrações expand-then-contract são o que torna qualquer uma dessas estratégias segura de reverter. Na Arvucore, costumamos recomendar arrumar primeiro as migrações e o ensaio de rollback, e escolher a estratégia de tráfego depois.