[翻譯]what-is-trunk-based-development

原文地址 https://paulhammant.com/2013/04/05/what-is-trunk-based-development

什麼是基於主幹開發（簡稱TBD）？

什麼是TBD？

它是一個軟件開發的分支模型。歷史上，它也被稱爲「主線/mainline」(見下文)。 它須要更多的專一和嚴格，而不是(在共享的源代碼控制服務器上)創建一個分支來知足一時的須要。雖然您能夠在不進行持續集成(CI)的狀況下完成，就像許多開源項目所作的那樣，可是對於企業開發來講，您必須將CI鏈接到主幹，強制執行「提交是好的」的多個方面。 在本文中，我沒有提到開發人員在他們本身的工做站上如何經過「本地」分支來適應他們的逐小時活動。這都是關於共享倉庫的，在這裏，多個開發人員集成/合併他們的平常工做以達到更好的效果:）

基於主幹開發(TBD)是全部開發人員(針對特定的可部署單元)在源代碼控制下提交到一個共享分支的地方。這個分支一般被稱爲主幹，甚至可能被命名爲「主幹/trunk」。開發人員能夠在他們本身的開發工做站中進行一些多分支開發(好比使用Git)，可是當他們經過更改或bug修復「完成」時，應該返回到共享主幹。若是它不在那裏，那就不算「完成」——注意那個小謊話。請參閱下面關於pull-requests的部分。 開發人員不容許在共享位置建立發佈分支。只有發佈工程師纔會致力於這些發佈分支，並真正建立每一個發佈分支。若是有意願，他們也能夠挑選我的向該分支做出承諾。在一個版本被另外一個版本取代以後，發佈分支極可能被刪除。 主幹做爲一個模型，已經使用了大約20年。最初是由開源社區推進的，但在「企業級」中，當ClearCase(和其餘人)發佈其餘分支模型成爲主流時，狀況就不那麼樂觀了。谷歌和Facebook，今天，實踐TBD風格的分支模型。若是不徹底正確，那就足夠接近。不管是谷歌仍是Facebook都公開了他們TBD的使用狀況，它的市場份額都在不斷增加。

可是這裏有分支!

是的，有這種狀況。可是關於發佈。「發佈分支」是策略。發佈分支在被另外一個發佈分支取代以前會存在很短的時間，它在建立時從主幹中獲取全部內容。就合併而言，只支持從主幹到發佈分支的遴選cherry-pick。對於許多企業，只會合併錯誤修復。對於Facebook(他們每週從發行分支上進行10次直播)來講，若是利益相關者優先考慮的話，加強功能的合併也會發生。

幾乎全部人都贊成，bug是固定在主幹上併合併到發佈分支上的，而不是固定在發佈分支上併合併到主幹上的。一般只有不多一部分人能夠提交到發佈分支。

Pull-Requests 仍是分支!

好的，因此GitHub率先將pull-request做爲開發工做流。這與TBD至關兼容，由於一個特性/任務是在不在主幹/主服務器上的位置進行編組的，但能夠快速完成。一般狀況下，代碼審查發生在那裏，CI會自動權衡PR分支是否有資格合併到主幹/主分支。若是一切正常，PR被合併到主/主幹中，而後刪除，留下一個平滑的主幹/主時間軸。固然，稍後做爲pull-request主題的特性/任務分支應該是一我的或一對分支，而且壽命很短(好比一天)。也有一些變體——「fork」和原始的簡單分支都是很好的pull-request選擇。只有代碼倉庫讀寫權限指南應該使用。

開發的義務

開發人員不會用任何提交破壞構建。這須要不少規則，也許這也是爲何谷歌和Facebook的誘導程序對於開發者來講是冗長的。回滾/恢復提交是一種防止由此形成損害(損失時間)的策略。更復雜的公司將使用預提交驗證。開發人員養成了這樣的習慣:經過同步主幹的最新版本，從根本上/從頭構建，再次檢查它們的功能變化，而後提交，來證實提交是好的。在早期，包括在ThoughtWorks中，開發人員有一個「標記」來證實他們並無破壞構建——在他們進行驗證的過程當中，沒有人可以控制雞。橡膠雞已經被使用了十多年，可是任何東西均可以(感謝Jez的連接)。

持續集成CI

像Jenkins這樣的持續集成會參與到這個提交中，並經過構建管道構建、測試、部署、測試等等。它可能會檢測到故障，這極可能是由於開發人員沒有證實他們的提交或執行令牌操做。另外一個問題多是開發人員在提交以前沒有添加新的源文件。這很容易/很快就能夠補救，並且「前滾」也能夠。

須要「太長時間」才能完成的更改

開發人員使用一種稱爲分支抽象(BbA)的技術來確保他們可以在更長的時間內完成更復雜的更改。我已經寫過不少次了。Martin Fowler強調了這一點，Jez Humble也寫過一樣的文章。它減輕的風險是分支機構的增長，以及那些「臨時」分支機構沒有按照人們但願的時間表完成工做。

My own case studies

From 2005, a move from crazy branching towards TBD (a US FX trading bank).

主幹開發回顧

Quick reminder of what TBD is: ● 開發提交到一個單獨的主幹 ● 發佈工程師 (or 編譯員工) 建立分支, 而且多多少少遴選到分支 ○ 只有一個缺陷不能在樹幹修復, 才許可給在發佈分支修復,並擇遴選回主幹。 若是你用到了發佈分支的概念，那就值得記住: ● 主幹開發意味着普通的開發人員承諾不提交到發佈分支. ● 主幹開發意味着你要刪除舊的發佈分支,而不是合併回主幹

什麼絕對不是TBD

開發者提交到多個分支

包含相同源文件的分支。參考BbA上面-你應該這樣作。高級開發人員一般會聲稱他們有一個特殊的案例，而且但願在一個分支上完成。問題在於共享源控制服務器上的分支的增長，它們的「臨時」生命期的長度，以及當有許多開發人員和許多提交到某個地方時合併的困難。 Branches containing the same source files, that is. Refer BbA above - you should be doing it. Often senior devs would claim they have a special case, and want to do it on a branch. The pitfall is the proliferation of branches on the shared source-control server, the length of their ‘temporary’ life, and the difficulty of merging when there are lots of developers and lots of commits to one place or another. 即便是喜歡樹幹概念的人也會反覆討論這一方面的問題。我將在沙子上畫一條線，而且說你不該該爲特性(在那個共享倉庫上)建立分支，無論它們須要多長時間，無論它們是否超過了發佈日期。你應該作BbA。

不在單一分支開啓一個持續集成管道

固然，做爲我的實踐，您能夠防止破壞，許多開源團隊會認爲沒有CI是好的。但對於擁有數十名開發人員的企業土地，您須要完全的CI。

手動維護依賴版本號

能夠用版本化的方式表示可構建組件的依賴關係。 例如，Log4J目前是1.2.17，由Apache維護。你不會把他們的資源拉進你的資源控制。您將依賴於一個二進制文件，併爲您本身的構建文件烘焙版本號(在源代碼控制下)。 對於您本身的東西，它多是在CI的不一樣階段構建的，您不該該爲特定的構建指定版本號。借鑑Maven的習慣用法，您應該依賴於CI下的移動目標。說「OurCommonThings-1.1-SNAPSHOT」，但要確保你是在「正確」的CI構建階段構建的。您不打算這樣作，可是若是您不使用編譯並使用最新版本的everything進行測試，您就不能持續地進行集成。

CI管道中更核心的實現將使用我上面建議的有爭議的「1.1-SNAPSHOT」以外的其餘東西。It(以及Maven自己)在企業開發中是一個有爭議的問題。對於顛覆或強制安裝，存儲庫修訂號能夠是您使用的——「1.1-12345」。或者，構建號可能很流行(全部CI工具均可覺得它們執行的腳本提供一個構建號)。

不在root下持續集成

在常規配置中，CI應該從頭構建全部內容，而不是依賴於以前構建的任何內容。一些更復雜的CI基礎設施(好比ThoughtWorks Studios的Go)擁有一種更可證實的/指紋的方式，可使用預構建塊進行戰術上的操做，但常規安裝應該從零開始(儘量快地)。

基於主幹開發是「一切最新版本」的另外一個變體。

連續版本的併發開發

有些企業同時處理一系列發行版。他們打算使用運行時切換來進行暗部署，但也可能在生成的二進制文件中使用構建時切換到子集功能，這取決於他們想在CI階段測試什麼。它們可能有多個CI管道用於同一主幹，這證實「amazon_one_click=true」和「amazon_one_click=false」交替構建並經過測試。這兩個失敗中的任何一個仍然是提交失敗，而且可能發生回滾/恢復。

您只須要爲您但願實時發佈的版本設置不一樣排列的切換管道。若是「管理」取消了一個版本的特性(由一個開關激活)，或者從新排列版本，那麼您能夠儘快從新配置CI管道。CI很快就澄清了「從新規劃」的成本和時間影響，以及由此致使的每一個主幹的傳遞/失敗視圖。你永遠不會去測試不合理的切換排列。

順便說一句，極限編程社區正確地指出，連續發行版的連續開發更可取。

名存實亡

mianline是另外一回事

好的，傳統意義上的「mainline」是trunk的同義詞，對於基於主幹開發的人一直使用「主線」來描述這一點。問題是「mianline」從1993年開始也被ClearCase社區使用，它指的是一種浪費和延遲的分支模式，以下所示:

這也是一個「遲到的」的集成設計，而TBD是「最先」的集成流程，這是開發過程當中成本下降的關鍵概念之一，也是最大的助推器。這個分支模型的另外一個事實是，掛起發佈分支的分支，這些分支應該是臨時的。

全部，總結，mianline對於不少軟件開發人員來講意味着別的東西。

功能切換

最近我據說人們把TBD稱爲「功能切換」。馬丁•福勒(Martin Fowler)將這種長期存在的作法命名爲該行業。它常常與TBD一塊兒使用，但不是必須的。它能夠與任何分支模式一塊兒使用，並且可能與開發軟件服務並將其投入使用同樣古老。

在以前的一個客戶端中，咱們也談到了構建時切換。對於maven來講，這些配置文件是這樣的:

# with amazon one click
mvn -p amazon_one_click install

# without amazon one click
mvn install

所以，對於該客戶端來講，運行時的toggles與構建時的toggles (Maven配置文件)不一樣，固然有些是二者兼而有之。如前所述，CI管道將啓動commit以實現合理的切換排列。

持續發佈 (部署)

這是簡單的TBD和CI用法的改進。Jez有一本頗有名的書，它是必不可少的閱讀材料。

感想…

Jez Humble勘誤, 有一句很好的引言「分支不是問題，合併纔是問題」(這是TBD試圖解決的一個問題的一種說法)

更新

June 30th, 2016 - We smile on Pull Requests, of course.