Estratégias de deploy

Estratégia de deploy controla o raio de impacto de uma mudança. O melhor método depende de capacidade, reversibilidade, risco e do quanto a aplicação tolera duas versões ao mesmo tempo — não do nome mais sofisticado.

Estratégia	Protege	Custa	Quando usar
Rolling	mantém parte do serviço	versões coexistem	padrão para serviços compatíveis
Blue/green	troca rápida de tráfego	dobra capacidade	release raro e rollback imediato
Canário	limita exposição inicial	métricas e roteamento	mudança de risco alto
Feature flag	separa deploy de release	governança de flags	alteração gradual de comportamento

Decida e meça antes de promover

Defina métricas de sucesso e falha: taxa de erro, latência, saturação e consumo de error budget. Para canário, comece com tráfego pequeno, defina duração mínima de observação e critérios explícitos de interrupção. Uma redução pontual de tráfego não prova segurança; compare com baseline e volume suficiente. Feature flag precisa de dono, data de expiração, telemetria e remoção do código morto após a decisão.

kubectl rollout status deployment/minha-api --timeout=5m
kubectl rollout history deployment/minha-api
kubectl rollout undo deployment/minha-api --to-revision=REVISAO

Esses comandos só revertem o workload. Antes do deploy, confirme qual digest está ativo, onde está o artefato anterior e se a migration de banco é reversível. Use expand/contract: adicione estrutura compatível, publique código que aceita os dois formatos, migre dados e remova o formato antigo somente em release posterior. Nunca acople uma exclusão irreversível ao mesmo rollout que pode precisar voltar.

Próximo passo: automatize canário e rollback com o guia de Argo Rollouts ou mantenha o estado desejado sob reconciliação em GitOps.