What Is Feature Flag and What Problem Does It Solve?

什麼是 Feature Flag 以及它解決什麼問題？

@ 技術討論

前言

Feature Flag 功能開關 = 開關用於管理程式中的功能

還記得之前參與某個專案使用 Git Flow 的方式管理產品發布，整個團隊盡力好幾個月打造某項功能，但隨著時間過去它與持續進行中的主支線差距越來越大，最終也要花不少力氣同步兩者的進度，也是在那次問題之後我更認可 Trunk Based Development🔗 流程的概念，其中提到 Feature Flag 是一種很好的技巧用來降低推送功能的風險與控制程度。

為什麼需要 Feature Flag？

有一句話是說：「寫程式和蓋教堂一樣，當完成之後，我們就開始祈禱」。背後隱藏著開發者對程式部屬的不安與恐懼。關於部屬最簡單的模式即是隨時把最新進度部屬上線，但這樣非黑及白的模式也造就一些問題：

  • 同步更新進度：產品更新週期是兩週，但需要建立一個需要三個月才能完成的功能。該如何使用確保每個人都在主線上工作而不會在發佈時暴露一個半成品功能？
  • 部屬靈活性：改動可能會嚴重影響使用者……
    • 災難管理：出事了怎麼即時回朔修復？能不能漸進的推動功能？
    • 調配功能：不同時機（節慶）和用戶（不同等級與種類的用戶）有不同的功能需求，如何管理調配？
    • 即時反饋：新功能需要被實際用戶測試才能得到最真實的反饋。

導入 Feature Flag 可以解決以上問題，透過拆分「部屬」與「發布」改善體驗。

Feature Flag 的實踐

Feature Flag 可以是簡單到是手動改動程式碼，或是一段簡單的判斷邏輯根據環境變數或是依賴外部狀態與服務改變程式行為，重點是調配功能的狀態要如何儲存？

地點難度響應速度改動速度額外花費靈活性
程式碼中簡單快慢無高
環境變數簡單快慢無低
資料庫麻煩慢快無高
現成服務簡單慢快付費高

Feature Flag 是一個簡單易懂的概念，但在企業級規模上管理起來卻頗為困難🔗，和許多最佳實踐🔗可以探討。

總結

開發人員應該自然的十分熟悉 Feature Flag 的概念，因為如今常見的版本控制策略都有提倡 Feature Branch 的概念，只是 Feature Flag 根據現有痛點探討如何更好的改善發布的體驗。隨著專案規模擴大，這一項遲早會需要被探討的問題解方。

可以從現成的服務了解這項策略的成熟型態：

延伸閱讀