在逐步交付價值時，產品經理與團隊需要確認哪些功能先完成、哪些可以延後，也需要考慮功能的開放時間。例如，活動介紹頁需要配合宣傳日期，即使程式提前完成，也要等到約定時間才能公開。
然而，整合與部署仍有不確定性，如果等到活動當天才進行，遇到問題時可能沒有足夠時間處理，影響功能準時開放。而且，如果活動程式尚未整合，其他開發者又在這段期間修改了相關功能，之後整合時就可能需要處理更多差異，讓開發者之間的距離越來越遠。
功能標誌（Feature Flag）透過設定控制功能是否啟用，也常被稱為功能開關。開發者可以先整合、部署程式，讓功能保持關閉，產品經理再依需要安排開放時間。
這項彈性需要開發者事先設計。除了決定開關控制哪些行為，也要確認設定如何生效、關閉時保留哪些原有功能，以及開啟前需要完成哪些驗證。
依用途，功能標誌可以分成以下四類：
以下分類參考 Martin Fowler 部落格的〈Feature Toggles (aka Feature Flags)〉。
| 類型 | 用途 | 生命週期 |
|---|---|---|
| 發布開關（Release Toggles） | 讓程式先整合、部署，再決定何時開放功能。 | 通常短期保留，不再需要控制開放時即可移除；實際時間依發布安排而定。 |
| 實驗開關（Experiment Toggles） | 將使用者分組，提供不同版本的行為，供 A/B 測試等實驗比較。 | 保留至實驗完成，確認不再需要比較或切回後移除。 |
| 維運開關（Ops Toggles） | 在服務異常或負載過高時，暫停部分功能或改用較簡單的處理方式。 | 多數短期保留；持續用於異常或高負載應變的開關可長期保留。 |
| 權限開關（Permissioning Toggles） | 依使用者所屬群組或資格，決定提供哪些功能，例如內部試用或付費方案。 | 需要依使用者資格控制功能時就保留，例如付費方案的開關可能長期存在。 |
前面提到的活動介紹頁，需要先整合、部署程式，再配合約定日期開放，因此控制頁面開放的開關屬於發布開關。這個開關通常只需暫時保留，等頁面公開後，確認不再需要透過開關控制是否開放，就可以移除開關，保留活動頁面。
假設 Nathan 團隊要新增活動介紹頁，並在首頁加上活動入口。產品經理先和需求方確認開放時間，再和開發者討論開關設計。
到了約定的公開時間，首頁要顯示活動入口，使用者也要能開啟活動介紹頁。宣傳結束後，首頁不再顯示入口，但使用者仍可透過網址閱讀活動介紹。網站其他功能在這段期間仍照常更新。
Elvina 負責首頁入口與活動頁面的顯示，Mandy 負責伺服器處理活動頁面請求的程式。頁面由伺服器產生，活動內容只供閱讀。
如果入口與頁面共用一個開關，關閉首頁入口時就會一起關閉活動頁面，無法符合宣傳結束後仍保留內容的安排。Elvina 與 Mandy 因此設計了活動頁面開關與首頁入口開關，分別控制頁面是否開放、入口是否顯示，兩個開關都預設為關閉。
Mandy 提醒，即使首頁沒有入口，使用者仍可能直接輸入活動網址。因此，處理活動頁面的請求時，也要檢查活動頁面開關。關閉時回傳「找不到頁面」，結束請求；開啟時才回傳活動內容。
首頁入口需要活動頁面能正常開啟，活動頁面卻不必依賴首頁入口。兩人因此約定，只有兩個開關都開啟時，首頁才顯示入口；活動頁面是否提供內容，則只看活動頁面開關。原本的首頁功能在各種設定下都要保留。
下圖整理兩種請求各自要檢查的開關。
開關只能控制經過判斷的程式。例如，Elvina 為了活動頁面修改共用的版面樣式，這份樣式也可能影響首頁，即使活動功能關閉也一樣。因此，設計時仍要確認這次變更會影響哪些既有功能，不能以為關閉活動功能後，相關程式就不會影響其他功能。
提早整合後，團隊可以在共同版本裡驗證已完成的活動程式與首頁是否能一起正常運作。後續有人調整共用樣式時，也能一起確認對兩個頁面的影響，及早處理發現的問題。
產品經理希望部署後還能安排開放時間，開發者就需要確認設定如何提供，以及程式何時讀取新值。
如果程式只在啟動時讀取設定，改完設定後就要重新啟動或重新部署，才會採用新值。要在執行中切換功能，程式就需要重新取得設定。
這個案例假設伺服器每次處理請求都會讀取設定，因此修改設定後，新的請求就會使用新值。測試環境與正式環境可以使用同一份程式成品，搭配不同設定：測試環境開啟活動功能，正式環境先保持關閉。
程式讀取設定後，會將值轉成布林值，表示開啟或關閉。未提供某個開關的設定時，就預設為關閉，避免功能提前開放。
產品經理確認何時公開，Brent 更新正式環境設定，Elvina 與 Mandy 確認首頁入口與活動頁面是否符合預期。這些分工、設定與檢查步驟都要記錄下來，方便接手的人查閱。
活動功能尚未完成時，先驗證已實作的部分，並確認關閉活動功能時，首頁等既有功能仍正常運作。每一步也都要能正常建置與啟動。
活動功能完整後，還要驗證兩個開關的組合。兩人依照前面的開放安排，整理出各種組合的用途：
| 活動頁面開關 | 首頁入口開關 | 用途 |
|---|---|---|
| 關閉 | 關閉 | 尚未公開，或暫時停用。 |
| 開啟 | 關閉 | 頁面已公開，尚未宣傳或宣傳已結束。 |
| 開啟 | 開啟 | 頁面公開，首頁同時宣傳。 |
| 關閉 | 開啟 | 頁面不開放，卻要求顯示入口，不符合目前安排。 |
活動頁面開關關閉、首頁入口開關開啟時，雖然不符合開放安排，仍要驗證程式不會顯示入口；正式環境若出現這組設定，團隊需要修正。
除了四種組合，也要分別確認兩個設定在未提供時，是否都會預設為關閉。驗證要包含使用者實際操作的過程，例如從首頁點選入口後是否能看到完整的活動介紹，以及直接輸入網址時是否得到預期回應。
首頁原有功能與共用樣式等變更，也要按照影響範圍驗證。需要確認的是相關功能如何配合，不是把網站所有互不相關的開關都湊在一起，要求每種組合各跑一遍完整測試。
即使到了約定時間，必要驗證尚未完成的功能也不能直接啟用。
功能標誌讓團隊可以提早整合與部署程式，再依產品安排開放功能。這樣既能及早發現整合問題，也能留下處理部署問題的時間，不必等到功能公開當天，才一起面對整合與部署的問題。
以上述例子來說，活動頁面與首頁入口需要分開控制，才能在宣傳結束後保留頁面內容。確認開關的控制範圍、設定生效方式與預期行為後，接著就要將設計寫進程式，分步整合、驗證與部署。
iThome鐵人賽
看影片追技術