最近在看軟件質量保障相關的一些資料，持續集成占據了其中很大一部分篇幅。這篇博客，介紹下持續集成的起源、發展以及如何實踐。
主要內容是對持續集成相關知識的整理歸納，以及個人對持續集成的一些思索總結，僅供參考。。。
去年轉載了一篇介紹持續集成的文章，傳送門：聊聊持續集成
參考資料：《京東系統質量保障技術實戰》
其他資料：《jenkins入門指南》、《持續集成：軟件質量改進和風險降低之道》、《持續交付：發布可靠軟件的系統方法》、《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》
下載密碼：un6n
一、起源與發展
1、起源
持續集成這個術語最早是在1994年由Grady Booch提出的，目前能看到的關於持續集成最多的描述，來源於Martin Flower發表的一系列論文。
Martin Flower也對微服務架構的流行貢獻了最大的力量，主要源於其2014年發表的論文《Microservice》。
關於微服務架構，我之前整理了一篇博客，感興趣的可以去看看，傳送門：微服務架構
Martin Flower為持續集成總結了以下一些原則：
①、維護一個統一的代碼庫；
②、每天都必須向主干提交代碼；
③、每次提交都應立刻在集成環境進行構建；
④、自動化構建；
⑤、自動化測試；
⑥、自動化部署；
⑦、快速、持續構建；
⑧、構建環境務必於生產環境保持一致；
⑨、訪問權限對團隊成員保持公開透明；
2、定義
持續集成-CI（Continuous Integration）：對軟件項目進行持續的自動化的編譯打包構建測試發布，來檢查軟件交付質量的一種行為。
3、組成
自動編譯+自動代碼檢查+自動打包+自動化測試+自動部署
4、演進
模式：互聯網機會窗口期的不斷縮短，需要快速交付，快速發現問題解決問題
角色：功能測試→自動化測試、性能測試、安全測試→測試開發（對軟件研發過程提供各種支持，包括工具，框架，方案，最佳實踐）
崗位：開發、測試的崗位界限越來越模糊，由原來的DEV、TEST向質量保障靠攏（可參考《Google的軟件測試之道》，這本書介紹了Google是如何做測試的）
5、工具
AnthillPro：商業的構建管理服務器，提供C功能
Bamboo：商業的CI服務器，對於開源項目免費
Build Forge：多功能商業構建管理工具，特點：高性能、分布式構建
Cruise Control：基於java實現的持續集成構建工具
CruiseControl.NET：基於C#實現的持續集成構建工具
Jenkins：基於java實現的開源持續集成構建工具，現在最流行和知名度最廣泛的持續集成工具
Lunt build：開源的自動化構建工具
Para Build：商業的自動化軟件構建管理服務器
二、為什么要做持續集成
1、項目中常見的問題
①、集成時發現系統無法運行；
②、不同分之之間合並代碼經常出錯；
③、加班加點改BUG；
④、重復進行手工的部署、調試、測試、發布，成本高，風險大；
⑤、其他。。。。。。
2、團隊文化問題
①、對交付軟件的質量意識不足
②、無法做到優先處理失敗的構建
③、工程師文化不足
④、團隊管理、流程的不足
3、持續集成的優點
持續集成能提升交付效率和交付軟件的質量
①、及時反饋結果，盡早發現問題；
②、自動化代替手工，工程師將更多的時間精力放在設計、需求分析、風險預防等方面；
③、持續集成→持續交付→DevOps→基於容器的服務→提高自動化程度來提高效率；
三、從零開始構建持續集成
CI = 高效的構建+全面有效的測試+合理的流程規范+工程師文化+ROI
1、高效的構建
①、高效的構建：主干開發是快速推進CI的有力基礎
核心：源代碼、測試用例、配置和數據統一管理
優勢：解決merge回主干困難，回歸成本高的問題
解決隨着項目增多，分支增多，管理越來越難的問題
修復BUG，可以達到修改主干，多出都可以fix的效果
解決QA只保證單獨分支質量，忽視merge后主干質量的問題
②、高效的構建：需要工具支撐
版本控制：git&SVN
代碼管理：gitlab私有部署
基礎環境：虛擬機、docker、kubernetes
自動構建：jenkins
反饋機制：郵件&短信&微信&釘釘
具象方式：打造符合團隊需要的pipeline
2、全面有效的測試：測試存在於項目周期各個階段
①、需求與設計：PM/DEV/QA
需求評審
需求變更
設計評審
②、開發與測試：DEV/QA/PM
code review、單元測試
測試方案、測試用例、BUG管理、風險評估
功能測試：冒煙、集成、系統、驗收
性能測試、安全測試、容災測試
線上驗證、探索性測試
③、上線與線上：OP/QA/DEV/PM
線上驗證
業務監控
用戶反饋
產品評測
PS：缺陷發現越早，修復成本越低，反之則越高
3、合理的流程規范
①、代碼提交規范
本地開發
本地編譯（自測，check out）
提交至當前主干（change log簡潔明確）
主干編譯（測試，check out）
②、注意事項
提交至主干前做好本地編譯、自測
提交前解決代碼沖突
提交時及時關聯和添加描述
提交后關注代碼掃碼結果
提交后關注主干集成構建結果
構建沒問題后及時合並
③、遵循原則
主干構建失敗停止提交代碼，直至構建成功
優先修復失敗的構建，修復問題
如果構建不能快速修復，執行回滾
4、工程師文化
①、提高對交付軟件質量保障的意識（測試是核心）
②、樹立優先處理失敗的構建的意識（優先程度最高）
③、培養團隊工程師文化（流程、質量、溝通、職業素養）
④、優化團隊管理、流程各方面，做到精簡，避免過分強調流程、避免面子工程、做好資源協調
5、ROI（投資回報率）
①、從0到1，可接受的投入的資源成本
入門階段可以考慮持續編譯打包，及時反饋代碼版本庫的編譯問題沖突問題（快速正向的反饋）；
②、從1到2，選擇對整體交付質量，速率提升最高的選項
可以選擇性價比較高的持續部署和代碼檢查，定時code review，減少手工部署和代碼級別的BUG造成的風險；
③、從2到3，面臨的問題越來越多
挑戰：
構建任務的不斷增加，執行速度的下降，整體效率的降低，成功率低於期望值；
自動化測試腳本維護量大，依賴於基礎測試環境和測試數據的穩定性；
解決方案：
增加任務構建執行機，減少排隊現象（多任務分布式構建）；
拆分耗時較長的任務，減少單個任務執行時間，解耦；
將自動化測試放在稍后的階段實施，分層設計，輕量的UI和重點API層automation，是目前業內較好的自動化測試實踐結果；
④、從3到N，不斷擴展帶來的挑戰和期望收益提升
不同團隊項目類型、技術棧構成、關注點、工作習慣不同，要求CI具備高度靈活性和定制化；
需要持續不斷的資源投入；
團隊自發適應、不斷調整和優化方案以及流程；
以上內容就是我對持續集成相關資料的整理以及個人的一些思考總結，還存在很多不完善或者不對的地方，如有更好的建議，希望看到的各位不吝指教。。。