Trunk Based Developement 概述

Trunk Based Development

最近看到了google 的一些文章，裡面提到了google & facebook 都使用了Trunk Based Development，覺得很有趣，所有就去查了一些相關的文章
Trunk Based Development最特別的地方就是，新的功能並不是開一個新的feature branch做開發，而是直接在trunk 上做開發，當然依然要遵守，每筆commit都不能太過於龐大的守則

由於Trunk Based Development 會使多個功能同時在同一個branch上開發，這也就衍生了另一個問題，假設某些功能是v1.0要進，某些功能是v1.1才要進，那要怎麼處理?

根據martin fowler的說法，我們必須實作feature toogle，講白了點就是類似開關的功能，根據設定檔開啟或關閉該功能，舉個例子來說，某個版本要進v1.1，但是我們的功能在v0.1 的時候就已經開始開發，所以我們必須實作一個開關，避免v1.0的版本會出現這個不應該出現的功能，接著我們可以在v1.1的時候將開關打開，然後在v1.2的時候將開關這個功能拔除並且移除舊的功能.
又或者，我們可以實作branch by abstraction的方法，其實也是一個開關的概念或者是說switch的概念，當沒有切換的時候就使用舊版的作法，當切換的時候則改成新版的做法，至於為什麼要使用abstraction的關鍵字?
其實這也對應到了 OO的概念

針對介面來撰寫程式，而不要針對實作

所以在實作這個功能的時候，首先必須先將共同的邏輯抽離抽成interface or abstract，然後舊版則實作這個interface or abstract，新版也實作這個interface or abstract，然後最重要的是使用者只針對interface or abstract 做動作，然後我們就可以去做switch的動作

TBD的好處

• 降低test的成本
  
  • 如果有多個feature branch也就代表有多個branch要執行test，這相對也提升了test 成本
• always是可以release 的codebase，並且可以根據需求，修改需要release的功能
  
  • 可以利用開關開啟或關閉某項功能
  • 可以利用開關使用新版或舊版功能
• 減少merge conflict的機會
  
  • 由於所有人都在同一個trunk上開發，只要所有的人都保證commit的code並不是過於龐大，就算遇到conflict也可以快速解決
  • 適合多人同時開發的專案

結論

講了那麼多，其實我也還沒有機會實際run過這個流程，不過根據目前的理解，TBD講白了就是把所有的功能都放在同一個branch上開發，然後使用featuretoggle & branch by abstraction來隔開尚未完成的實作，很合理…但是同時也覺得會有很多坑啊!!

reference

http://www.alwaysagileconsulting.com/organisation-pattern-trunk-based-development/
http://martinfowler.com/bliki/FeatureBranch.html
http://www.martinfowler.com/bliki/FeatureToggle.html
http://paulhammant.com/blog/branch_by_abstraction.html