Blue-green: dois ambientes, troque o tráfego após o deploy. Rolling: atualize instâncias uma a uma. Canary: envie uma fração do tráfego para a nova versão. Todos exigem load balancer e health checks. Planeje rollback a cada passo.
Blue-green
- Setup: Dois ambientes idênticos (blue e green). Um serve tráfego de produção; o outro fica ocioso ou é usado para staging. Implante a nova versão no lado ocioso.
- Troca: Após testes, aponte o load balancer (ou DNS) para o novo ambiente. Rollback = apontar de volta para o antigo. Rápido e simples mas exige o dobro da capacidade no momento da troca.
- Quando usar: Cutover único e rápido e você pode ter dois ambientes completos.
Rolling
- Setup: Várias instâncias atrás de um load balancer. Atualize uma instância por vez: tire do pool, deploy, health check, devolva ao pool. Repita para cada instância.
- Prós: Não precisa do dobro de capacidade. Rollout gradual; se uma instância falhar no health check, as outras continuam. Funciona bem com grupos de auto-scaling e instâncias imutáveis.
- Contras: Versões antiga e nova rodam ao mesmo tempo; garanta compatibilidade (ex. schema de DB, APIs).
- Quando usar: Muitas instâncias e quer evitar dobro de capacidade. Padrão em Kubernetes e muitos PaaS.
Canary
- Setup: Envie uma pequena fração do tráfego (ex. 5%) para a nova versão. Monitore erros e latência. Se ok, aumente para 50%, depois 100%. Se ruim, desvie e faça rollback.
- Prós: Limita o raio de impacto. Validar em produção com risco mínimo.
- Contras: Mais complexo (regras de roteamento, métricas, automação). Ambas as versões devem rodar; compatibilidade necessária.
- Quando usar: Validar em produção com risco mínimo. Muitas vezes com feature flags.
Requisitos comuns
- Load balancer: Suportar tirar/colocar instâncias na rotação e (para canary) roteamento por percentual ou header.
- Health checks: LB e orquestração devem fazer health check antes de enviar tráfego. Instâncias não saudáveis não devem receber tráfego; dispare rollback se muitas falharem.
- Plano de rollback: A cada passo, saiba como fazer rollback. Teste em staging. Mudanças de DB e schema exigem cuidado (mudanças compatíveis, feature flags).
Resumo
Blue-green: dois ambientes, troque o tráfego após o deploy. Rolling: atualize instâncias uma a uma. Canary: envie uma fração do tráfego para a nova versão. Todos precisam de load balancer e health checks; planeje rollback a cada passo.
