摘要：在這里聊一聊主干開發你需要知道的7件事。
現在各大公司流行主干開發，什么是主干開發，什么是分支開發、具體定義、流程是啥，這里不做知識普及，想要了解的童鞋到網上去搜一搜，再來讀本文。作者本人經歷過分支開發，也走過分支開發到主干開發演變的全過程，經歷過演變中的陣痛。團隊適應主干開發后，也踩過不少坑，當然主干開發帶來的好處也是比比皆是。咱這里聊一聊主干開發你需要知道的7件事。
1、主干開發的錯誤認識一：主干開發會改進產品質量
不要迷信主干開發，也別妄想通過主干開發來改進產品質量。首先要明確的是產品質量好不好與主干開發、分支開發沒啥本質關系。說到底，feature做慢一點，做少一點，多進行code review，DT，相對來說質量會好很多。如果主干開發同等時間做的功能過多，測試不充分，產品發布以后，同樣問題多多。即使是分支開發，留下充足的時間去控制質量，質量相對來說也會很好。之前的經驗是遷移到主干開發后，GIRA報表上明顯可以看出，每個月迭代出去的feature越多，engineer release前defects的統計越糟糕。同樣最終產線上產生的CFD（customer found defects）就會越多。
總結來說：產品質量的是好還是壞與主干開發、分支開發沒半毛錢關系。產品質量還是依據開發本身最根本的原則，多花時間測試來發現問題，產品上產線問題會越少。
2、 主干開發的錯誤認識二：分支開發的問題，主干開發都能解決。
分支開發通常會遇到這個問題：當分支的代碼合並到主干時，通常在一定周期內，出包都是個問題，即使出了包，經常會有大規模的block issues。如果覺得主干開發可以徹底解決這問題，實際上也是現實的。當采取主干開發模式時，基本上可以解決其中的一部分問題，但是有些問題，不是通過流程來解決的。
首先主干開發基本上不存在出包問題，理論上只要代碼能夠入倉，就能夠跑過CI上的所有檢測，能夠順利出包。但是我們都知道主干開發一個最重要的要是就是代碼要通過feature toggle來控制，通常情況下，開發中的feature都是toggle off的。也就是每天的包，不同的團隊，打開不同的feature toggle來測試。但是當同時打開幾個feature toggle時，或者產品決定要同時release幾個feature時，這時候沒有人可以保證這些新feature可以在一起可以同時正常工作。特別時有些功能時橫向的變化，有些功能時縱向的變化，中間的交際不同的團隊如果沒有溝通好，沒有提前進行繼承，同樣會產生大規模的block issues。舉個例子：之前在開發的功能，我們的SVP坐飛機從硅谷飛到芝加哥給客戶做demo。上飛機前打開我們的feature toggle，但是軟件在他的機器上一運行就crash。但是在我們自己的開發機器上是好的。他發了一個log給我們以后就上飛機了，說下了飛機在看怎么回事。我們分析了他的feature toggle列表，與我們的做了一個比較，發現其中有3個feature toggle不一樣，當打開其中一個feature toggle后，我們可以重現這個問題。 為了demo順利進行，在后台給他關閉了那個沖突的feature toggle，SVP下了飛機以后到酒店再試就好了。他不太明白咋回事，我們廢了好半天才跟他解釋我們產品關於feature toggle的設計與實現，以及問題產生的原因。
總結來說：主干開發在代碼合並的角度上比分支開發要好一些，但是還是需要不同團隊多交流，來解決。甚至看起來完全沒有關系的feature放在一起，沒有經過繼承測試，同樣會導致嚴重的問題。
3、 主干開發的錯誤認識三：主干開發增加開發效率，讓迭代更快。
由於沒有了分支合並主干的工作，大家會覺得主干開發效率更高，可以讓產品迭代更快，實際上這是個誤區。首先主干開發對於功能的開發效率比分支開發低，原因后面會提到。所以總體時間差距不大。我之前分支開發模式下時每月一個迭代，切到主干開發也是每月一個迭代，做到功能規模差距不大，所以這個說法並沒有根據，由於切換過程中的一些不習慣，短期內效率會變低。
總結來說：主干開發的目的不是為了增加開發效率，也沒有什么特定的因素可以根本加快開發效率。
4、 主干開發的副作用：相對於分支開發，主干開發的代碼會更“爛”。
主干開發，通常來說沒有達到release標准的代碼會運行在真實的產線中，只是代碼通過if/else來通過feature toggle來讓產線的代碼不會走到開發過程中的feature邏輯。首先任何人都無法保證所寫的代碼邏輯完全正確，所以主干開發對於code review以及開發者測試的要求極高，換句話說就是對於開發人員的要求極高，這也是很多團隊無法開展主干開發模式的根本原因。一旦你的代碼再toggle off的時候也會導致bug，那么產線就要回滾版本，或者立刻出EP（emergency package）來fix這個問題(作者本人就犯過這種錯誤，if else的位置多包含了一個判斷，導致現有功能一個邏輯處理異常)，其成本極高，所以主干開發的commit到主干的每一行代碼，都要及其重視。同時由於定義了大量的feature toggle以及遍布到處的if/else，代碼看起來相對比較糟糕，還有就是為了配合一些特定的發布流程，幾乎常常要變更feature toggle的定義，這些都是主干開發帶來的負面影響。通常我們會有feature toggle + feature option來控制一個feature的使能，意思就是當feature toggle ON的時候，代碼才會執行，但是feature本身是由可配置到feature option來打開或者關閉該功能，當產品功能真正上線成熟后，開發團隊應該刪除feature toggle的邏輯，但是很多開發團隊沒有意識或者無暇顧及這些，導致“爛”代碼一直存在，這也是主干開發的一些弊端或者要着重要注意的地方。
總結來說：主干開發過程中，其工作量要比分支開發更多，其出錯概率也更高，對於開發人員要求也更高，代碼寫的也更爛。
5、 主干開發的優勢一：主干開發天然支持灰度發布以及A/B Test。
上面說了主干開發那么多問題，但是為什么大家還要做主干開發，當然其有很多好處。最大的特點就是主干開發流程中，feature toggle的存在，讓開發本身天然的支持了灰度發布以及A/B Test。如果說5年前，灰度發布，A/B Test這種理念比較先進，大家決定比較高深。當產品采用主干開發模式以后，那么你就會發現原來這個東西真的很簡單。由於feature toggle的存在，可以通過服務器的配置可以針對企業級別，用戶級別的feature toggle控制。以我之前產品的開發模式為例，開發過程中，開發團隊開發feature toggle進行開發，當功能達到一定成熟度，可以申請進行“Blue Channel”，所謂的Blue Channel就是所有產品的開發人員以及通過特殊渠道申請加入的一群人，規模在500-1000人左右。
這個所有的Blue Channel就是對於feature toggle管理的一個集合，在這個Channel中所規定的feature toggle按照一定的設定來進行開發與測試。這個Channel的包極其不穩定，主要是產品功能並未做完全，各種feature在也會出現 “干架”的情況。由於我們所做的產品是我們日常都要用（例如Welink這種），所以加入這個Channel的非開發人員是需要勇氣的。再往后，feature成熟度更高，就會擴展到公司層面的一些人，規模在幾千人左右。通常老板們會加入這個Channel，經常拿這個版本給客戶做Demo，我們把這個Channel叫做“Purple Channel”。當功能更完善時，會提交申請進入“Green Channel”，對外叫做“EFT Channel”，通常會有幾萬用戶在用，也會給一些想要試用新功能的部分客戶試用。當產品的功能達到一定發布標准時，產品進入最后一個Channel，叫做“Golden Channel”，然后通過預定的灰度發布計划逐步把Feature Toggle給所有用戶打開最終達到GA。客戶再根據自己的需要決定Turn On/Turn Off feature option。整個過程中，沒切換一次channel，都要提交相關的流程申請，還有更換feature toggle。當產品達到GA標准以后，理論上需要刪除feature toggle相關的代碼。
總結來說：主干開發天然支持灰度發布以及A/B Test，這也是很多公司切到主干開發的主要原因。
6、主干開發的優勢二：主干開發比分支開發更容易的控制feature的發布。
分支開發，當決定在某個release時，會把代碼合並到主干，但是如果后續開發測試過程中，如果在規定發布時間內達不到質量要求，這時候就比較尷尬了。到底是延遲發布時間，還是把代碼給刪掉？這是分支開發的一個弊端。主干開發基本上不存在這個問題，主干開發通常會提前一定時間開出release branch（不同公司、不同產品有不同的規定，我之前的產品基本上在3周-6周）。當產品測試發現質量達不到要求是，只要產線toggle off就可以了。我之前公司有“一進一出”的評審，“一進”就是確定release branch開出時，該feature是否打開feature toggle進入系統級別的測試。“一出”就是根據測試結果來決定那些feature可以打開feature toggle進入本次release，基本上不需要額外的工作就可以完成。還有就是產品灰度發布的過程中，甚至GA初期，功能出現任何較大的問題，都可以通過feature toggle立即關閉該功能。對於產品質量的管理更方便。
總結來說：主干開發對於一個feature什么時候release，release過程中的一些問題，相對分支開發更容易處理。
7、 主干開發的優勢三：更簡單的版本管理。
分支開發經常會面臨一個這樣的問題：一些客戶的特殊需求，我們開出一個分支來開發，甚至直接在這個分支上發布給客戶。如果合到主干，就要面臨想主干開發那樣如何隔離的問題，但是本身不是主干開發，所以這是一個嚴重的負擔，如果停留在分支上，后續該用戶的持續升級面臨版本管理的問題。而主干開發來說，這個需求就是一個feature toggle控制的一個功能，開發測試完成正常進入release，只不過該feature toggle一直存在並且只針對特定的可以打開而已。
總結來說：主干開發的設計就是簡化版本管理，在主干上按照一定的規則拉出一個分支發布，比分支開發管理更簡單。
總結
分析了主干開發相對於分支開發的各種利弊，大家可以根據自己團隊的實際情況來看待我是用主干開發還是分支開發。如果主干開發的優勢對自身產品可有可無，那么沒有這種必要來切換。但是如果有必要，但是團隊的成熟度和技能達不到，也不適合切換到主干開發。甚至當你決定要切換到主干開發，一定要有心里准備來應對變革過程中遇到的各種問題。當然當你的團隊經歷了這些陣痛並真正適應了主干開發，那么團隊就的成長也是巨大的。