背景

產(chǎn)品在新功能發(fā)布前，可能會采取小流量測試的方式，或者在確定方案前使用A/B測試來衡量。一般開發(fā)人員會跟運維同學(xué)合作，通過一些現(xiàn)有平臺切換機器或者流量來實現(xiàn)。本文介紹了另外一種簡便的方式，并解釋了其在持續(xù)集成上的應(yīng)用，同時提供了現(xiàn)有的開發(fā)框架供快速使用。

Feature Flag VS Feature Branches

Feature Flag(又名 Feature Toggle、Flip等)是一種允許控制線上功能開啟或者關(guān)閉的方式，通常會采取配置文件的方式來控制。提到Feature Flag一般都會跟Feature Branches進(jìn)行比較。這兩個有什么關(guān)聯(lián)與差別呢？可以通過一個簡單的示例來比較：假設(shè)產(chǎn)品需要添加一個功能，如果你在主干上進(jìn)行開發(fā)，那么通常的做法是在前端開發(fā)人員在界面上添加功能，然后可能會有其他同學(xué)來完成后端服務(wù)、安全保障，最后測試及Bug修復(fù)并發(fā)布上線。如下圖所示：

圖中有個明顯的問題是主干分支上在功能測試完畢之前是不能進(jìn)行發(fā)布的，因為功能已經(jīng)在提供在界面中，必須完備之后才能發(fā)布給用戶使用。

當(dāng)然解決方法也很簡單，例如我們常見的是會使用功能分支(Feature Branches)來解決。在主干上拉取一個分支，然后在分支上開完測試完之后在合并到主干上，這樣就不會影響主干的持續(xù)發(fā)布了。如果有另外的新的功能那么同樣拉取新的分支來解決。如下圖：

這樣同樣存在問題，如果一個功能比較復(fù)雜，開發(fā)的周期較長，而在此期間主干上已經(jīng)多次修改代碼，那么等分支上開發(fā)完之后合并到主干將是一個比較麻煩的工作。你必須去處理各種沖突，與其他開發(fā)人員溝通修改點。這是很多人不愿意做的。

于是有人提供了新的方案來解決這個問題。例如將開發(fā)工作拆分成多個小塊，在各個分支上開發(fā)測試完成后及時合并到主干中，并且可以先隱藏界面功能，直到所有的功能開發(fā)完成之后才展現(xiàn)。這樣每次合并的難度就小多了；或者每次將主干上的修改都及時同步到分支上，這樣分支上開發(fā)完成之后合并到主干上就簡單多了。

如果發(fā)布時出現(xiàn)bug怎么辦？可能常見的是進(jìn)行回滾重新上線。有什么方式既能避免分支合并的麻煩、保持主干快速迭代隨時發(fā)布，又能更好的控制新功能的發(fā)布、方便的進(jìn)行小流量或快速回滾操作呢？答案就是Feature Flag。

Feature Flag允許關(guān)閉未完成的功能，你可以在主干上進(jìn)行迭代開發(fā)，新功能即便未開發(fā)完成也不會影響發(fā)布，因為它對用戶是關(guān)閉的。當(dāng)功能開發(fā)完成之后，修改配置便可以讓功能發(fā)布。這種操作甚至可以在線上進(jìn)行，例如代碼已經(jīng)發(fā)布但功能不可見，你可以修改配置讓功能對特定的用戶(線上測試、小流量或者全量發(fā)布等)可見。如果發(fā)現(xiàn)新功能存在問題，那么可以通過配置文件來迅速回滾，而必須重新分支上線。Feature Flag原理示意圖如下：

自的優(yōu)缺點

選擇合適的方案，而不拘泥于方式本身

并沒有萬能的方案，兩種方式都有各自的優(yōu)缺點。

Feature Branches

優(yōu)點：

• 同時開發(fā)多個功能分支不會影響主干和線上代碼

• 在分支上開發(fā)新功能時不用擔(dān)心對其他在開發(fā)的功能的影響

• 現(xiàn)有很多持續(xù)集成系統(tǒng)支持分支的構(gòu)建、測試、部署等

缺點也很明顯，Martin Fowler的文章中已經(jīng)做了全面的闡述：

• 分支分出去時間越長往往代碼合并難度越大

• 在一個分支中修改了函數(shù)名字可能會引入大量編譯錯誤。這點被稱為語義沖突（semantic conflict）

• 為了減少語義沖突，會盡量少做重構(gòu)。而重構(gòu)是持續(xù)改進(jìn)代碼質(zhì)量的手段。如果在開發(fā)的過程中持續(xù)不斷的存在功能分支，就會阻礙代碼質(zhì)量的改進(jìn)。

• 一旦代碼庫中存在了分支，也就不再是真正的持續(xù)集成了。當(dāng)然你可以給每個分支建立一個對應(yīng)的CI，但它只能測試當(dāng)前分支的正確性。如果在一個分支中修改了函數(shù)功能，但是在另一個分支還是按照原來的假設(shè)在使用，在合并的時候會引入bug，需要大量的時間來修復(fù)這些bug。

Feature Toggle

優(yōu)點：

• 避免了分支合并代碼沖突的問題，因為是基于主干的開發(fā)

• 每次提交都在主干，迭代速度明顯有優(yōu)勢

• 新功能的整個過程都持續(xù)集成

缺點:

• 未完成的功能可能會部署到線上，如果配置有誤可能將未完成的功能開啟。當(dāng)然可以將界面層最后開發(fā)避免過早暴露。

• 主干上擔(dān)心提交代碼影響其他功能。

我們可以根據(jù)需要選擇合適的方案。Feature Flag在避免分支合并加快迭代上有優(yōu)勢，另外Feature Flag除了主干開發(fā)上的支持，還有什么實用功能呢？下面來介紹。

Feature Flag種類與應(yīng)用

一般Feature Flag可以分為兩類，見下所示：

發(fā)布開關(guān)：

• 在發(fā)布代碼時關(guān)掉未完成的功能

• 生存期短

• 功能穩(wěn)定就馬上刪除

• 在整個開發(fā)過程中有預(yù)定義的值

業(yè)務(wù)開關(guān)：

• 實現(xiàn)A/B測試

• 針對特定人群發(fā)布功能盡早獲得反饋

• 針對特定條件開啟或者關(guān)閉功能。例如可以設(shè)置在指定時間點開啟，這樣新功能將按照設(shè)定自動上線下線，無需手動上線，適合專題等情況

• 能線上開啟或者關(guān)閉,實現(xiàn)快速回滾

發(fā)布開關(guān)主要是為了隱藏未開發(fā)完成的功能，而業(yè)務(wù)開關(guān)則可以幫助我們快速滿足某些需求。例如A/B測試，Feature Flag可以輕松控制展現(xiàn)哪個功能，提升A/B測試的可維護(hù)性。我們也可以通過配置里面的邏輯讓新功能針對小部分人群甚至是特定地域的人群發(fā)布，盡早獲取功能的反饋。甚至是可以在線上開啟調(diào)試，只讓新功能對調(diào)試人員可見。而這些都只需要配置文件和簡單的標(biāo)記來實現(xiàn)。

誰在用Feature Flag

功能看起來很酷，但是不是新東西？有誰在用呢，我可不不愿意承擔(dān)風(fēng)險

事實上Feature Flag已經(jīng)在國外互聯(lián)網(wǎng)公司中獲得廣泛的使用。例如FaceBook、Google等公司使用基于主干的開發(fā)模式來持續(xù)集成開發(fā)，Feature Flag是其中一個基礎(chǔ)技術(shù)。下面這幅圖展現(xiàn)了FaceBook開發(fā)模式轉(zhuǎn)變歷程,可以看到幾年前facebook就開始使用Feature Toggle，使用了Feature Flag關(guān)閉主干上未開發(fā)完成的功能來保證快速迭代和高頻率的發(fā)布。

外主干開發(fā)中推薦這樣一種方式：trunk作為開發(fā)主線，所有開發(fā)人員完成開發(fā)后向及時向主干提交代碼，開發(fā)人員不允許在主干上拉取分支。在發(fā)布的時候由系統(tǒng)拉取分支發(fā)布，主干上的bug修復(fù)及時同步到發(fā)布分支。開發(fā)人員可以本地使用git等工具進(jìn)行版本管理。如下圖所示：

然基于主干的開發(fā)模式已經(jīng)成為國外的主流，但分支開發(fā)并不是不該使用。使用分支不推薦的是讓新功能代碼在分支上長時間堆積，分支應(yīng)當(dāng)是生存周期短的。

實際應(yīng)用中我們可以根據(jù)業(yè)務(wù)場景來選擇是否用功能分支還是Feature Flag，并且這兩者可以相互結(jié)合。例如在文章前面提到的示例中，可以使用分支來開發(fā)細(xì)分的子功能保持分支及時合并，同時使用Feature Flag來控制功能的發(fā)布，提升工作效率。

最佳實踐

除了主干開發(fā)，什么情況下選擇使用Feature Flag呢？下面是使用Feature Flag的一些典型場景：

• 在 UI 中隱藏或禁用新功能

• 在應(yīng)用程序中隱藏或禁用新組件

• 對接口進(jìn)行版本控制

• 擴展接口

• 支持組件的多個版本

• 將新功能添加到現(xiàn)有應(yīng)用程序

• 增強現(xiàn)有應(yīng)用程序中的現(xiàn)有功能

可以看到，由于Feature Flag本身是對業(yè)務(wù)功能的控制，所以不適于功能大范圍的改動等情況。另外使用過程中需要注意一些問題：

• 只在需要的地方創(chuàng)建開關(guān)。美酒雖豪，不可貪杯。濫用任何技術(shù)都會出現(xiàn)問題。

• 控制開關(guān)的數(shù)量。同上，開關(guān)應(yīng)按需使用并及時清除。

• 開關(guān)之間代碼保持獨立。如果代碼存在依賴就沒法刪除，最終維護(hù)性反而變差

• 清除發(fā)布開關(guān)和廢棄代碼。發(fā)布開關(guān)應(yīng)當(dāng)在功能穩(wěn)定后刪除，舊代碼也是。

• 界面層最后暴露。

如何實現(xiàn)

實現(xiàn)這套東西復(fù)雜嗎？下面以php和smarty模板為例來介紹。

首先需要一套控制代碼邏輯的工具，雖然開源的框架有在后端代碼層的支持，但推薦在模板層使用Feature Flag，因為模板直接跟功能掛鉤，維護(hù)起來更加直觀方便。

例如我們會提供一個smarty插件，讓你控制相應(yīng)的展現(xiàn):

個代碼的意思是如果common模塊的featureA命中，則展現(xiàn)下面代碼，否則展現(xiàn)另外一套代碼，展現(xiàn)代碼由于與功能相關(guān)，所以就相當(dāng)于控制了展現(xiàn)哪個功能。當(dāng)然你也可以不用featureelse只控制功能的開啟或者關(guān)閉。

另外我們需要一個配置文件，對應(yīng)featureA的配置，如下所示：

??{
??????"features"?:?{
??????????"featureA"?:?{
??????????????"type"?:?"switch",
??????????????"value"?:?"on",
??????????????"desc"?:?"test?switch?feature?work?or?not"
??????????}
??????}
??}

featureA配置的value是on，開關(guān)類型是switch。也就是說這個功能是開啟的。與switch類似的可以實現(xiàn)多個feature類型，例如抽樣控制、日期控制、地域控制等，代碼邏輯只需要根據(jù)value的設(shè)定判斷是true還是false。例如抽樣類型，value設(shè)置0.5，那么對應(yīng)的類型邏輯只需要判斷隨機數(shù)是否在0-0.5范圍內(nèi)而已。

部署中我們只需要修改featureA的配置就可以控制功能的發(fā)布，是不是so easy!

開發(fā)框架

有哪些相應(yīng)的開源框架呢？幾乎各種語言都有相應(yīng)的實現(xiàn)。例如FEX?FIS小組提供了基于php和node.js的框架。此外還有多種語言的開源實現(xiàn)：

語言Feature Flag框架

php	基于smarty的Feature Flag框架
NodeJs	基于Node前后端解決方案Yogurt的Feature Flag框架
java	Togglz
.NET	FeatureToggle
Ruby	Rollout、Degrade
Python	Gargoyle、Nexus admin
Groovy	GrailsFeatureToggle

總結(jié)

• Feature Flag與Feature Branches各有優(yōu)勢，結(jié)合使用能發(fā)揮更大作用

• 結(jié)合業(yè)務(wù)場景選擇合適方案

• Feature Flag能支持主干開發(fā)，并在控制功能發(fā)布上有獨特優(yōu)勢

參考資料

• 采用功能切換進(jìn)行軟件開發(fā)

• 使用功能開關(guān)更好地實現(xiàn)持續(xù)部署

• FeatureToggle

• Feature driven development

• Favor Feature Toggles over Feature Branches

• What is Trunk Based Development?

• Decoupling Deployment and Release- Feature Toggles

總結(jié)

以上是生活随笔為你收集整理的Feature Flag 功能发布控制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。