Uafhængig deploybarhed er hele pointen, så hver service har brug for sin egen CI/CD-pipeline plus en lav-risiko-releasestrategi — typisk canary eller blue-green — for at kunne shippe sikkert mange gange om dagen.
Hver service bygger, tester og deployer på sit eget tempo. En ændring til en service udløser aldrig en fuld systemrelease.
commit ─▶ build ─▶ unit + contract tests ─▶ image ─▶ deploy (one service)
| Strategi | Hvordan | Fordel | Ulempe |
|---|---|---|---|
| Rolling | Erstat instanser gradvist | Simpel, default | Blandede versioner kort tid |
| Blue-green | To miljøer, skift trafik | Øjeblikkelig rollback | 2x infra |
| Canary | Send lille % til ny version | Begrænser skadesomfang | Kræver gode metrics |
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
Uden backward-kompatible schemas bryder canary/blue-green, fordi to versioner køres samtidigt. Design altid ændringer til at være kompatible på tværs af versioner.
Hyppige, lav-risiko-deployments er det, der gør microservices værd kompleksiteten — langsomme, risikable releases ville slette autonomifordelen.
Canary og blue-green begrænser skadesomfanget ved et dårligt deploy og giver næsten øjeblikkelig rollback, hvilket omdanner deployment fra en skræmmende begivenhed til en rutinemæssig, automatiseret, daglig aktivitet.