大爆炸式一次換掉全部，等於把每次部署都當賭注。漸進式發布把「部署」和「釋出給使用者」拆開：先給一小撮流量、盯著指標、沒事再放大，有事就秒回滾。把風險從「全站」縮到「金絲雀」。
🧠 Intuition
TIP
部署（deploy）≠ 釋出（release）。新版本可以先上線但不收流量，再用旗標/路由「一格一格」把使用者導過去。回滾就是把路由切回舊版，不必重新部署。
- Blue-Green：同時跑舊(blue)新(green)兩套，流量整批切到 green；回滾＝切回 blue。切換快，但要雙倍資源、且 DB schema 要前後相容。
- Canary：新版只接 1% → 5% → 25% → 100%，每階段觀察 SLI；異常自動停／回滾。資源省，但流程較複雜、要好的指標與自動判讀。
- 兩者的共同前提：可觀測（看得到金絲雀的錯誤率/延遲）+ 可快速回滾。
⚖️ Tradeoffs
Blue-Green — 切換快、資源貴
- 優點：瞬間切換、瞬間回滾；上線前可在 green 完整煙霧測試。
- 代價：要維持兩套等量環境（成本）；資料庫遷移必須向後相容，否則切回 blue 會炸。
- 適合：希望「乾淨整批切換」、且能負擔雙環境的服務。
Canary — 風險最小、流程最重
- 優點：真實流量小範圍驗證，爆炸半徑最小；可綁 error budget 自動 gate。
- 代價：需要分流路由、分版本指標、自動分析（新舊版 SLI 比對）；DB/相依也要相容兩版本並存。
- 適合：高流量、追求最小風險、有成熟可觀測性與自動化的團隊。
🔑 Takeaways
- 把 deploy 與 release 拆開，才能「先上線、後放流量、出事秒回滾」。
- Blue-Green 換得快但要雙倍資源；Canary 風險最小但要分流、分版本指標與自動判讀。
- 兩者都吃可觀測性 + 向後相容的資料遷移；canary gate 常綁 error budget。
No notes yet — jot your takeaways or Q&A here.