上一篇中我們總結了價值流圖中變更管理的基礎技術手段之一：版本控制，本篇我們繼續總結變更管理的基礎技術手段之二：持續整合。

持續整合意味著團隊的所有成員以每日至少一次的頻率將自己的程式碼變更整合至中心程式碼庫並通過自動化的構建和測試來驗證變更質量，以儘可能早和快的發現問題。持續整合與版本控制配合完成了對軟體開發過程的持續質量保障，二者缺一不可。最常見的比如jenkins和gerrit的配合，每個提交到gerrit的change都能觸發jenkins的job，而job執行完成後可以根據結果對gerrit的change進行review&verify 打分，以反饋驗證結果。

如果說需求管理是持續交付的引子，版本控制是持續交付的基礎，那麼持續整合就是持續交付的核心。持續整合不僅僅保障了開發過程的程式碼質量，而且通過持續整合工具對上游程式碼變更的監控和對下游觸發任務的編排，持續整合將持續交付流水線前後貫穿並使其流動起來，使得“每一次程式碼變更都能生成一次可用的軟體版本”成為可能。

如今國內大大小小的軟體開發公司都已用上了基本的持續整合功能，因為它的投入代價實在太小而獲得收益實在太高。首先總結一下持續整合耳熟能詳的兩個基本功能點：第一，輪詢監控版本控制庫並觸發任務；第二，視覺化展示任務結果。

然後我們嘗試深入思考一下持續整合實踐中遇到的一些問題和解決思路： 

1.分支策略

持續整合所面向的物件實際上是中心程式碼庫裡某一條分支的全部或部分程式碼倉庫，即持續整合是以分支為部署粒度的。分支策略的選擇會極大地影響持續整合的資源投入和效果收益。

通常我們能看到三種分支策略：

Ⅰ 主幹用於日常bug修復，新特性開發工作在特性分支上進行，商用版本釋出在釋出分支上進行；所有特性分支和釋出分支所合入的特性和bug都以一定的週期合併回主幹。

Ⅱ 主幹同時用於新特性開發和商用版本釋出以及日常bug修復，沒有額外的分支。

Ⅲ 主幹用於新特性開發和日常bug修復，商用版本釋出在釋出分支上進行；釋出分支僅合入bug修復並且確保所有修復合併回主幹。

就目前而言，第三種分支策略綜合考慮比較實用，既保障了商用版本釋出的穩定，又避免了過多的特性分支與主幹合併的致命問題。在主幹上進行新特性開發通常會通過特性開關或者增量式開發來規避新特性對主幹質量的影響。

2.分層協作

通常持續整合會分為如下幾層：個人構建；元件構建；整合構建；版本構建。

不同層次的構建負責的驗證範疇不同，比如個人構建關注基本的靜態檢查，元件構建關注本元件的質量，整合構建關注本元件與其他元件的配套關係，版本構建關注多個元件構成的整體版本功能。

比較令人頭疼的是持續整合過程中不同物件的協同，我們列舉三種常見情況。

2.1 同一個元件下不同程式碼倉庫的協同構建

有時候一次缺陷修復會同時涉及多個程式碼倉庫，對應程式碼變更會生成多個change記錄，如果持續構建將這些change分開單獨驗證，結果自然是失敗的。因此需要保證相關聯的change記錄使用相同的changeid，並在持續整合系統中定製實現按照changeid查詢所需要驗證的change列表，對change列表中的所有change同時進行驗證。

2.2 不同元件的協同構建

考慮上面提到的整合構建，需要對不同元件之間的配套關係進行驗證，此時需要確認不同元件間協同構建的策略。通常我們需要持續維護各個元件的穩定狀態製品庫，並選擇製品庫中最新的穩定版本來滿足其他元件的驗證需求。

但是這種策略面對同一次程式碼變更涉及多個元件的場景時又無法滿足，所以還需要進一步思考。

2.3 程式碼與測試用例協同構建

面對程式碼變更涉及測試用例變更的場景，需要保證測試用例跟隨程式碼變更同時驗證和生效，才能避免持續交付流水線的無意義失敗。因此我們需要藉助敏捷開發模式，開發和測試團隊融合工作，將測試用例也納入持續整合範疇。比如可通過測試用例變更與程式碼變更使用相同的changeid來保證二者同時被驗證。

3.團隊文化

持續整合不僅僅是技術手段，更是一種團隊文化。它的重點在於：頻繁的小型提交；提前本地構建驗證；足夠快的自動化測試套件；修復失敗構建為第一要務；實時構建狀態公開；......