工具-低風險發布模式

🎯 什麼情境該想到我

當你「不敢上線」——每次發布都得挑深夜、出事只能硬著頭皮往前修，你想讓發布變成可以隨時做、隨時退的動作時。

⚙️ 怎麼用

1. 先把兩件事拆開（這是所有模式的前提）：
   • 部署 deployment ＝把某個版本裝到某個環境。一次部署可以完全不伴隨任何功能發布。
   • 發布 release ＝讓某功能對全部或一部分客戶可用（例如只開給 5% 的人）。
   • 架構要求：發布功能不應該需要改應用程式碼。
2. 拆開之後責任也拆開：Dev 與 Ops 對「快速頻繁部署的成功」負責，產品負責人對「發布的業務成果」負責。剩下的只有 release risk。
3. 選模式——兩大類：
   • 環境型（通常完全不用改應用程式）：藍綠部署（兩套環境切流量，回滾＝把流量切回去）、金絲雀發布（逐級晉升到越來越關鍵的環境，每級都監控）、叢集免疫系統（指標偏離預期範圍就自動回滾）
   • 應用型（改應用、但更細緻）：功能開關（用組態開關功能，可回滾、可優雅降級、可做 A/B）、黑啟動（功能全部部署但對使用者不可見，用真實生產流量測）
4. 判準：先問「要不要改應用程式」。不想動程式就從環境型下手，藍綠最容易套用到既有系統；需要對「誰看得到」做細緻控制才進到功能開關與黑啟動。
5. 能隨選部署之後，「多快把新功能開給客戶」就變成業務與行銷決策，不再是技術決策——這是這整套做法真正的回報。

原文：「as we become able to deploy on demand, how quickly we expose new functionality to customers becomes a business and marketing decision, not a technical decision.」

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意

• 資料庫是藍綠部署最容易破功的地方。書中偏好的解法是把資料庫變更與應用變更解耦：只做加法變更、絕不變動既有資料庫物件，且應用程式不對「生產環境會是哪個資料庫版本」做任何假設。用「兩個資料庫互切」的做法時，回滾會遺失切換後未遷移的交易。

🔗 相關工具

• 工具-部署管線與持續交付 —— 前提條件，沒有可靠的自動化管線，這些模式無從施展
• 工具-遙測與監控 —— 必要配套，金絲雀與叢集免疫系統都靠指標決定推進還是回滾
• 工具-三步工作法 —— 上位框架，落在第一步「流動」
• 解耦部署與發布 —— 型錄條目，含 Jez Humble 對持續交付與持續部署的正式定義