上一篇中我們總結了價值流圖中變更管理的基礎技術手段之一：版本控制，本篇我們繼續總結變更管理的基礎技術手段之二：持續集成。
持續集成意味着團隊的所有成員以每日至少一次的頻率將自己的代碼變更集成至中心代碼庫並通過自動化的構建和測試來驗證變更質量，以儘可能早和快的發現問題。持續集成與版本控制配合完成了對軟件開發過程的持續質量保障，二者缺一不可。最常見的比如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.團隊文化
持續集成不僅僅是技術手段，更是一種團隊文化。它的重點在於：頻繁的小型提交；提前本地構建驗證；足夠快的自動化測試套件；修復失敗構建爲第一要務；實時構建狀態公開；......