透過Azure App Configuration實現Feature Toggle
Feature Toggle有很多名稱，也常被叫做 Feature Flag, Feature Switch…但不管他叫什麼名字，都無損他在這個時代的重要性。
為什麼重要?
他為這個時代所面對的問題，提供了適當的解決方案，這些問題包含:
- 實現A/B測試
- 實踐金絲雀佈署
- 實踐高強度的頻繁交付
- 實踐不同環境上的自動化佈署
- …
乍看之下，上面這幾件事情都跟Feature Toggle無關，但實則有很大的關連性。在說明前，我們先理解一下 Feature Toggle 是甚麼?
Feature Toggle的建立
他是一個後台控制的開關，與我們的程式碼有所連動，簡單的說，就是在我們的程式中，加上一些簡單的if…then判斷敘述，然後依照這個開關在後台所設定的on或off，來決定是否要執行(啟用)某個功能。
這麼簡單的機制，為何和自動化佈署有關? 又為何可以幫助我們實踐 A/B 測試?
先談『高強度的頻繁交付』，以及『在不同環境上實現自動化佈署』這件事。
如果你對CI/CD或敏捷開發有概念，大概能夠理解近代軟體開發都希望能夠頻繁交付，頻繁的程度因團隊而異，高強度的頻繁交付，可能需要一天更版數次，而無論是一天更版數次，或是一周交付數次，都意味著開發團隊很可能每天多次合併程式碼，在這種狀況下，程式碼版控的多分支方案(例如gitflow)將變得不可行，而會慢慢收斂成單一分支(feature branch)或根本沒有分支的狀態，在這種狀況下，程式碼的整合和交付將可以變得非常頻繁。
但衍生出一個副作用，就是在這個狀況下，開發到一半的功能怎麼辦? 如果團隊需要急著修復用戶反饋的某一個bug, 必須立刻整合上版，但卻又同時需要等某幾個功能都做完，才能一次上線，這就產生了矛盾。
這時，feature toggle就會派上用場，它可以幫我們在正式環境上，先關掉不想開放的功能，等幾個具有相依性的功能都完成，再從後台一次打開開關放行。
這就是feature toggle在近代敏捷開發與CI/CD潮流下，非常重要的原因，因為它有效的分離了釋出(Release)與(Deployment)。
可以實現佈署(Deployment)，但不開放(Release)功能的效果。
配合A/B測試 與 金絲雀佈署
你可能有聽過 A/B Testing，它指的是，我們會在production環境上，將用戶隨機或非隨機地分成兩組(或多組)，然後讓這兩組用戶使用不同的功能設計，以便於鑑別出較好的設計。
而金絲雀佈署則是，我們把要新上線的功能，在正式機上，僅開放給特定一小群用戶來進行盲測(或明確告知其身為對照組也行)，待測試無誤後，再開放給其他人。
A/B Testing為的是找到最佳的UI/UX模式，而金絲雀佈署則是為了降低上線新版功能可能造成的風險。
講到這邊你大概也知道，要實踐這些功能，最簡單的方式就是設計一個開關，對了，開關，那feature toggle不正是最好的選擇?
請看底下這個toggle的設定畫面:
你會發現Azure App Configuration的Feature toggle功能，可以針對特定比例的用戶群組、或特定使用者、特定時間區間來開放或關閉某一個功能，因此完全可以達成我們 A/B Testing 和 金絲雀佈署 的需求。
使用Feature Toggle
介紹過了Feature Toggle之後，我們來看使用的方法，底下這個影片介紹如何在Azure Portal當中，透過App Configuration 服務，來建立Feature Toggle，並且搭配程式碼來實現此功能:
留言