在前文中，咱們談到生命周期長短不同的兩種分支策略。對于不超過二十人的小團隊來說，推薦使用短生命周期的分支策略。Joe的團隊在首次發(fā)布之前，也一直使用這種方式。然而，首次發(fā)布之后，因市場反響非常好，公司決定加大開發(fā)投入，希望更快地推出升級平臺，以及更多基于平臺的游戲。

　　一、按特性分支的持續(xù)集成策略

　　現(xiàn)在，Joe的團隊中，開發(fā)人員快速增加，已接近30人了。由于首次發(fā)布后的市場壓力，大家一直在趕進度，持續(xù)集成的失敗頻率越來越高，修復構(gòu)建的時間也越來越長，排隊等待提交的代碼也越積越多。“這種狀況不能再持續(xù)下去了，需要想個辦法解決它。”Joe決定下午召集主要人員開會，分析一下原因和對策。

　　“現(xiàn)在我們還在使用提交令牌（參見《Checkin Dance》一文的最后一節(jié)），可我們的開發(fā)人數(shù)已經(jīng)翻了一倍。而且，我們自動化測試用例的數(shù)量也激增。”Joe說道，“有時候我想提交代碼都要排隊等很長時間。”

　　“嗯，每天等待提交的人也挺多的。”Alice說道，“現(xiàn)在看來，雖然持續(xù)集成讓我們每次提交的質(zhì)量都更有保證，但是在同一個主干上開發(fā)的人數(shù)太多，它就成了一個提高開發(fā)效率的瓶頸了。”

　　“要不這樣吧：我們把大家分成小組，每個小組從主干上拉出一個分支，完成一組相近特性的開發(fā)后，再合并回主干。”Bob邊說邊在白板上畫了出來（如圖1所示）。

　　“對應的持續(xù)集成方案也需要調(diào)整。包括：

• 保留現(xiàn)有主干對應的持續(xù)集成平臺，但不許在主干上直接開發(fā)代碼；
• 每個分支增加一個相對應的持續(xù)集成平臺；
• 每個分支的持續(xù)集成平臺構(gòu)建中需要包括該分支對應特性的單元測試、功能測試；
• 每次向主干合并時，都會觸發(fā)主干上的持續(xù)集成，構(gòu)建中應包含整個系統(tǒng)的單元測試、功能測試等。

　　這樣，每個小組的人數(shù)不會太多，提交時需要等待他們提交完成的概率應該不會太大。另外，每個分支的持續(xù)集成上只運行自己分支對應特性的單元測試和功能測試，這樣，構(gòu)建時間也會縮短。”

　　“聽上去是個好辦法，”Alice答道，“可是，我對這個方案有幾個疑問。比如說，這幾個小組在什么時候做同步？每個小組什么時候向主干合并代碼？”

　　“嗯，好問題。我還沒有想到這么多呢。”Bob皺了皺眉，感到很沮喪。

　　Joe笑了笑，說道：“的確是不錯的方案。只要加一點同步與合并規(guī)則，改進一下。”然后，他拿起白板筆，在圖上加了幾筆（所圖2所示）。

　　“規(guī)則如下：

• 每個小功能在盡可能短的時間里開發(fā)且測試完成，最好是在一周之內(nèi)。
• 每組做完一個小功能后，一旦該分支上的持續(xù)集成構(gòu)建通過，而且手工驗證沒有問題，就可以向主干合并代碼。
• 合并后，與主干對應的持續(xù)集成平臺會立即驗證這些代碼。
• 如果主干持續(xù)集成平臺的構(gòu)建失敗，那么是哪個小組提交導致的，就由哪個小組負責修復。
• 每天各組在開始工作之前，都要將主干上那個最新且通過主干持續(xù)集成構(gòu)建成功的代碼檢出，并與各自分支的代碼進行合并。

　　其實，這就是小組級別的‘Checkin Dance’。目的還是要持續(xù)集成，即盡量要將各小組的工作成果集成在一起。如果每個小組能夠做到頻繁與主干代碼同步。”

　　Alice問道：“由于每個分支上都是多人開發(fā)，那么當某個功能完成后，并需要合并回主干時，該分支上可能已經(jīng)有一些代碼是屬于尚未完成功能的代碼。我們需要把屬于該功能的代碼修改挑選出來后提交到主干嗎？”

　　“你是說Cherry Picking吧。只要我們能夠通過技術手段確保用戶無法訪問到未完成的功能，就不需要Cherry Picking了。比如通過配置項或功能開關的方式。”Joe說道。

　　“這樣做，聽起來挺好的，但還有一個問題需要解決，那就是：現(xiàn)在大家的代碼耦合度太高啦。每增加一個小功能，都要修改很多個位置的代碼。”Bob說道，“如果這么做的話，各組之間的代碼沖突會很多，合并可能帶來很多問題。”

　　“的確是這樣的，目前的持續(xù)集成方案只能緩解合并問題，但無法解決合并中的代碼沖突問題，只有通過對代碼的結(jié)構(gòu)進行調(diào)整才能夠解決。”Job說道。“而且，對于我們這樣的軟件系統(tǒng)來說，對架構(gòu)進行調(diào)整帶來的益處更大。”

　　二、模塊化應用程序的持續(xù)集成

　　“啊哈！架構(gòu)調(diào)整？”Bob笑道，“架構(gòu)這個詞讓人用得太濫了，還是不要提的好。一提到架構(gòu)調(diào)整，我就想起在前一雇主公司干的活了——每次架構(gòu)調(diào)整都是重寫代碼。”

　　“哦，事實上，我們系統(tǒng)的架構(gòu)基本上是模塊化的，比如平臺與具體游戲之間的邊界還算清晰。”Joe回應道，“現(xiàn)在我們所要做的是強化模塊化。因為，新加入的開發(fā)人員對系統(tǒng)了解不夠深入，有些功能的耦合度開始增高了。我希望每個游戲就作為一個獨立模塊，進行開發(fā)與測試。而它所依賴的游戲平臺需要提供穩(wěn)定的對外接口。”

　　Alice說道：“那我們就可以不用前面提到的特性分支策略了，只要把每個模塊做為一個獨立的代碼庫進行開發(fā)，將它所依賴的游戲平臺作為外部依賴進行集成就行了。”

　　“的確是這樣的。”Joe肯定的回答道。“如果每個模塊對外都有某種形式的接口（比如API，接口定義文件），而所有外部依賴都通過這些接口與其進行交互的話，就可以這樣做。”如圖3所示。

　　“如果這么做的話，我們的持續(xù)集成方案應該是什么樣的呢？”Bob問道。

　　“那不是一樣嘛，即然都是獨立的，各模塊做各自的持續(xù)集成不就行了嘛。”Alice說道。

　　“當然不行，因為這些模塊之間仍舊需要通過彼此交互才能正常運行起來，尤其是對于那些有信息交換的游戲模塊，集成測試就更加重要。”Joe回答道，“既然需要集成，就要做持續(xù)集成。”

　　Alice問：“那我們有這么多個游戲，每個游戲都要與基礎游戲平臺進行持續(xù)集成，到底應該怎么做呢？”

　　“我們可以這么做。”Bob拿起筆在白板上畫了起來（如圖4所示）。“為每個模塊的代碼庫建立對應的持續(xù)集成環(huán)境，包括每個游戲和基礎平臺。無論哪個模塊代碼庫修改了代碼，都會觸發(fā)對應的持續(xù)集成構(gòu)建，一旦該模塊的持續(xù)集成構(gòu)建成功以后，就會觸發(fā)一個包含所有游戲和平臺的集成構(gòu)建。”

　　“這樣不錯，但是現(xiàn)在每個模塊都對應獨立的代碼庫了，那么在最后各模塊集成構(gòu)建時，到底用各模塊的哪個版本呢？”Alice問道。

　　Joe說道，“Alice的問題非常好。在最后各模塊集成構(gòu)建時，除了那個主動觸發(fā)構(gòu)建的模塊使用最新版本外，其它模塊都使用最后一次令該集成構(gòu)建成功的那個對應版本。”Joe邊說邊在白板上畫了一個例子。

　　“比如，對于我們目前的系統(tǒng)來說，一共有四個游戲模塊和一個基礎平臺。假如最后一次成功的集成構(gòu)建中，各模塊對應的版本分別是123, 245, 212, 467 和12387。當我們對游戲模塊A進行了一次提交，其版本變?yōu)?24，并且通過了它自己的持續(xù)集成構(gòu)建以后，就會觸發(fā)最后的集成構(gòu)建。這次集成構(gòu)建所對應的各模塊版本分別為124, 245, 212, 467和12387。如果這次構(gòu)建成功，則下次最后集成構(gòu)建就以這些版本為基礎；如果這次構(gòu)建失敗了，則標記游戲模塊A的124版本是可疑版本，盡管它通過了其自身模塊的構(gòu)建。同時需要有人對這次集成構(gòu)建進行分析，進行問題定位并修復。”如圖5所示。

　　“那么，我們的基礎游戲平臺也是由多個模塊組成的。我們是否也需要把這些模塊獨立成庫，使用同樣的方式進行持續(xù)集成呢？”Bob問道。

　　Joe回答道：“我認為現(xiàn)在還不需要。平臺內(nèi)部模塊化是應該的，但因為它自身的構(gòu)建時間并不長，還沒有必要獨立成庫。”

　　Alice此時說道：“這樣看來，我們的持續(xù)集成問題可以按這種方案來解決。讓我們試試吧。”

　　那么，Joe的團隊使用這種持續(xù)集成方案以后，還會遇到什么情況呢？比如，基礎平臺的構(gòu)建時間變長，會怎么樣呢？

　　需要注意的是，無論采用哪種方法，我建議都不要讓同一組人一直工作在一個模塊上（雖然這是在各組織中經(jīng)常見到的），而是讓一組人工作在一組模塊或功能上，并讓小組成員在各組間流動。這樣有利于組間的知道共享，對保持架構(gòu)的一致性也會起到積極作用。

it知識庫：持續(xù)集成之“分支策略”(續(xù))，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。