A implantação independente é o ponto central, então cada serviço precisa de seu próprio pipeline CI/CD mais uma estratégia de lançamento de baixo risco — normalmente canary ou blue-green — para enviar com segurança muitas vezes ao dia.
Cada serviço constrói, testa e implanta em seu próprio ritmo. Uma mudança em um serviço nunca ativa um lançamento de sistema completo.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Estratégia | Como | Vantagem | Desvantagem |
|---|---|---|---|
| Rolling | Substituir instâncias gradualmente | Simples, padrão | Versões mistas brevemente |
| Blue-green | Dois ambientes, alternar tráfego | Rollback instantâneo | 2x infraestrutura |
| Canary | Enviar pequeno % para nova versão | Limita raio de explosão | Precisa de boas métricas |
v1 ████████████████ 95% ← watch error rate / latency
v2 █ 5% ← promote if healthy, roll back if not
└─ automated check on SLOs decides promote vs abort
[ Blue v1 ] ◀─ live ──┐
[ Green v2 ] ◀─ idle ├─ flip router ─▶ Green is live; Blue is instant rollback
Sem esquemas compatíveis com versões anteriores, canary/blue-green quebram porque duas versões executam simultaneamente. Sempre projete mudanças para serem compatíveis entre versões.
Implantações frequentes e de baixo risco são o que torna os microsserviços dignos da complexidade — lançamentos lentos e arriscados anulariam o benefício da autonomia.
Canary e blue-green limitam o raio de explosão de uma implantação ruim e oferecem rollback quase instantâneo, transformando implantação de um evento assustador em uma atividade rotineira, automatizada e diária.