Oberoende distribuerbara tjänster är hela poängen, så varje tjänst behöver sin egen CI/CD-pipeline plus en lågriskig releasestrategi — vanligtvis canary eller blue-green — för att kunna leverera säkert många gånger per dag.
Varje tjänst bygger, testar och distribuerar enligt sitt eget tempo. En ändring i en tjänst utlöser aldrig en fullständig systemrelease.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategi | Hur | Fördelar | Nackdelar |
|---|---|---|---|
| Rolling | Ersätt instanser gradvis | Enkelt, standard | Blandade versioner under kort tid |
| Blue-green | Två miljöer, byt trafikflöde | Omedelbar rollback | 2x infrastruktur |
| Canary | Skicka liten % till ny version | Begränsar skadekring | Kräver bra metriker |
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
Utan bakåtkompatibla scheman bryter canary/blue-green eftersom två versioner körs samtidigt. Designa alltid ändringar för att vara kompatibla mellan versioner.
Frekventa, lågriskiga distributioner är det som gör mikroservices värt komplexiteten — långsamma, riskfyllda releaser skulle radera autonomifördelarna.
Canary och blue-green begränsar effekten av en dålig distribution och möjliggör nästan omedelbar rollback, vilket förvandlar distribution från en skrämmande händelse till en rutinmässig, automatiserad, daglig aktivitet.