🎯 什麼情境該想到我
當你「想選擇性地開關某個功能、或只開放給特定使用者群，卻不想為此再做一次生產部署」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：提供「不需要生產環境的程式碼部署就能選擇性啟用／停用功能」的機制，同時能控制哪些功能對哪些使用者分群可見（例如內部員工、部分客戶）。
實作方式：
- 用條件式（conditional statement）把應用邏輯或 UI 元素包起來，依「存放在某處的組態設定」決定該功能啟用或停用。
- 組態可以簡單到只是應用程式組態檔（JSON、XML），也可以透過目錄服務（directory service），甚至是專門用來管理 feature toggling 的 web service。
- Facebook 的功能開關服務叫 Gatekeeper：Chat 功能開發期間先只對 Chat 團隊可見，後來對全體內部員工可見，但透過 Gatekeeper 對外部使用者完全隱藏。
功能開關讓你能做的四件事：
- 輕鬆 roll back：在生產環境造成問題或中斷的功能，只要改開關設定就能快速安全地停用。在部署頻率低的時候特別有價值——關掉某一個利害關係人的功能，通常比 roll back 整個發布容易得多。
- 優雅降級（gracefully degrade performance）：當服務遇到極高負載、原本得擴充容量甚至可能整個掛掉時，用開關降低服務品質以換取服務更多使用者——例如減少可存取某功能的客戶數、關閉推薦這類 CPU 密集的功能。
- 透過 SOA 提升韌性：某功能依賴的服務還沒完成時，仍可把功能部署到生產但藏在開關後面，等那個服務可用了再打開；反過來，當依賴的服務故障時就把功能關掉，避免呼叫下游服務，其餘應用照常運作。
- 支撐 hypothesis-driven development 與 A/B testing，讓部署與功能發布解耦，進而推進想要的業務成果。
測試規則：
- 為了確保被開關包住的功能裡的錯誤能被抓到，自動化驗收測試應該在「所有 feature toggle 都開啟」的狀態下執行。
- 功能開關機制本身也要測（書中特別加了驚嘆號提醒）。
原文：「automated acceptance tests should run with all feature toggles on. (We should」（L6749，接 L6750「also test that our feature toggling functionality works correctly too!)」）
原文：「switching off one particular stakeholder’s features is usually much easier」（L6729，接 L6730「than rolling back an entire release.」）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這是 application-based release pattern，實作在應用程式碼裡，必須有 Development 參與——不像藍綠／金絲雀可以純在基礎設施層完成。
- 開關本身是程式碼與組態，會累積複雜度；測試策略必須跟上（全開跑驗收測試、外加測開關機制本身）。
- 只做開關而沒有把「發布決策」交給 product owner，等於白做——請搭配 解耦部署與發布 的責任劃分。
🔗 相關工具
- 解耦部署與發布（功能開關是實現「部署 ≠ 發布」的主要應用型手段）
- 黑啟動（功能開關讓功能先進生產但不可見，才有黑啟動可言）
- A-B測試與假設驅動開發（開關是做實驗與分流的前提）
- 藍綠部署（環境型手段，粒度較粗，兩者互補）
- 工具-部署管線與持續交付（開關讓未完成的功能也能安全地持續部署）
- DevOps手冊