摘要：在這裡聊一聊主幹開發你需要知道的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一直存在並且只針對特定的可以開啟而已。
總結來說：主幹開發的設計就是簡化版本管理，在主幹上按照一定的規則拉出一個分支釋出，比分支開發管理更簡單。
總結
分析了主幹開發相對於分支開發的各種利弊，大家可以根據自己團隊的實際情況來看待我是用主幹開發還是分支開發。如果主幹開發的優勢對自身產品可有可無，那麼沒有這種必要來切換。但是如果有必要，但是團隊的成熟度和技能達不到，也不適合切換到主幹開發。甚至當你決定要切換到主幹開發，一定要有心裡準備來應對變革過程中遇到的各種問題。當然當你的團隊經歷了這些陣痛並真正適應了主幹開發，那麼團隊就的成長也是巨大的。