淺談持續集成

最近在看軟件質量保障相關的一些資料，持續集成佔據了其中很大一部分篇幅。這篇博客，介紹下持續集成的起源、發展以及如何實踐。

主要內容是對持續集成相關知識的整理概括，以及我的對持續集成的一些思索總結，僅供參考。。。

去年轉載了一篇介紹持續集成的文章，傳送門：聊聊持續集成

參考資料：《京東系統質量保障技術實戰》

其餘資料：《jenkins入門指南》、《持續集成：軟件質量改進和風險下降之道》、《持續交付：發佈可靠軟件的系統方法》、《敏捷軟件測試：測試人員與敏捷團隊的實踐指南》

下載密碼：un6n

 

1、起源與發展

一、起源

持續集成這個術語最先是在1994年由Grady Booch提出的，目前能看到的關於持續集成最多的描述，來源於Martin Flower發表的一系列論文。

Martin Flower也對微服務架構的流行貢獻了最大的力量，主要源於其2014年發表的論文《Microservice》。

關於微服務架構，我以前整理了一篇博客，感興趣的能夠去看看，傳送門：微服務架構

Martin Flower爲持續集成總結了如下一些原則：

①、維護一個統一的代碼庫；

②、天天都必須向主幹提交代碼；

③、每次提交都應馬上在集成環境進行構建；

④、自動化構建；

⑤、自動化測試；

⑥、自動化部署；

⑦、快速、持續構建；

⑧、構建環境務必於生產環境保持一致；

⑨、訪問權限對團隊成員保持公開透明；

二、定義

持續集成-CI（Continuous Integration）：對軟件項目進行持續的自動化的編譯打包構建測試發佈，來檢查軟件交付質量的一種行爲。

三、組成

自動編譯+自動代碼檢查+自動打包+自動化測試+自動部署

四、演進

模式：互聯網機會窗口期的不斷縮短，須要快速交付，快速發現問題解決問題

角色：功能測試→自動化測試、性能測試、安全測試→測試開發（對軟件研發過程提供各類支持，包括工具，框架，方案，最佳實踐）

崗位：開發、測試的崗位界限愈來愈模糊，由原來的DEV、TEST向質量保障靠攏（可參考《Google的軟件測試之道》，這本書介紹了Google是如何作測試的）

五、工具

AnthillPro：商業的構建管理服務器，提供C功能

Bamboo：商業的CI服務器，對於開源項目免費

Build Forge：多功能商業構建管理工具，特色：高性能、分佈式構建

Cruise Control：基於java實現的持續集成構建工具

CruiseControl.NET：基於C#實現的持續集成構建工具

Jenkins：基於java實現的開源持續集成構建工具，如今最流行和知名度最普遍的持續集成工具

Lunt build：開源的自動化構建工具

Para Build：商業的自動化軟件構建管理服務器

 

2、爲何要作持續集成

一、項目中常見的問題

①、集成時發現系統沒法運行；

②、不一樣分之之間合併代碼常常出錯；

③、加班加點改BUG；

④、重複進行手工的部署、調試、測試、發佈，成本高，風險大；

⑤、其餘。。。。。。

二、團隊文化問題

①、對交付軟件的質量意識不足

②、沒法作到優先處理失敗的構建

③、工程師文化不足

④、團隊管理、流程的不足

三、持續集成的優勢

持續集成能提高交付效率和交付軟件的質量

①、及時反饋結果，儘早發現問題；

②、自動化代替手工，工程師將更多的時間精力放在設計、需求分析、風險預防等方面；

③、持續集成→持續交付→DevOps→基於容器的服務→提升自動化程度來提升效率；

 

3、從零開始構建持續集成

CI = 高效的構建+全面有效的測試+合理的流程規範+工程師文化+ROI

一、高效的構建

①、高效的構建：主幹開發是快速推動CI的有力基礎

核心：源代碼、測試用例、配置和數據統一管理

優點：解決merge回主幹困難，迴歸成本高的問題

解決隨着項目增多，分支增多，管理愈來愈難的問題

修復BUG，能夠達到修改主幹，多出均可以fix的效果

解決QA只保證單獨分支質量，忽視merge後主幹質量的問題

②、高效的構建：須要工具支撐

版本控制：git&SVN

代碼管理：gitlab私有部署

基礎環境：虛擬機、docker、kubernetes

自動構建：jenkins

反饋機制：郵件&短信&微信&釘釘

具象方式：打造符合團隊須要的pipeline

二、全面有效的測試：測試存在於項目週期各個階段

①、需求與設計：PM/DEV/QA

需求評審

需求變動

設計評審

②、開發與測試：DEV/QA/PM

code review、單元測試

測試方案、測試用例、BUG管理、風險評估

功能測試：冒煙、集成、系統、驗收

性能測試、安全測試、容災測試

線上驗證、探索性測試

③、上線與線上：OP/QA/DEV/PM

線上驗證

業務監控

用戶反饋

產品評測

PS：缺陷發現越早，修復成本越低，反之則越高

三、合理的流程規範

①、代碼提交規範

本地開發

本地編譯（自測，check out）

提交至當前主幹（change log簡潔明確）

主幹編譯（測試，check out）

②、注意事項

提交至主幹前作好本地編譯、自測

提交前解決代碼衝突

提交時及時關聯和添加描述

提交後關注代碼掃碼結果

提交後關注主幹集成構建結果

構建沒問題後及時合併

③、遵循原則

主幹構建失敗中止提交代碼，直至構建成功

優先修復失敗的構建，修復問題

若是構建不能快速修復，執行回滾

四、工程師文化

①、提升對交付軟件質量保障的意識（測試是核心）

②、樹立優先處理失敗的構建的意識（優先程度最高）

③、培養團隊工程師文化（流程、質量、溝通、職業素養）

④、優化團隊管理、流程各方面，作到精簡，避免過度強調流程、避免面子工程、作好資源協調

五、ROI（投資回報率）

①、從0到1，可接受的投入的資源成本

入門階段能夠考慮持續編譯打包，及時反饋代碼版本庫的編譯問題衝突問題（快速正向的反饋）；

②、從1到2，選擇對總體交付質量，速率提高最高的選項

能夠選擇性價比較高的持續部署和代碼檢查，定時code review，減小手工部署和代碼級別的BUG形成的風險；

③、從2到3，面臨的問題愈來愈多

挑戰：

構建任務的不斷增長，執行速度的降低，總體效率的下降，成功率低於指望值；

自動化測試腳本維護量大，依賴於基礎測試環境和測試數據的穩定性；

解決方案：

增長任務構建執行機，減小排隊現象（多任務分佈式構建）；

拆分耗時較長的任務，減小單個任務執行時間，解耦；

將自動化測試放在稍後的階段實施，分層設計，輕量的UI和重點API層automation，是目前業內較好的自動化測試實踐結果；

④、從3到N，不斷擴展帶來的挑戰和指望收益提高

不一樣團隊項目類型、技術棧構成、關注點、工做習慣不一樣，要求CI具有高度靈活性和定製化；

須要持續不斷的資源投入；

團隊自發適應、不斷調整和優化方案以及流程；

 

以上內容就是我對持續集成相關資料的整理以及我的的一些思考總結，還存在不少不完善或者不對的地方，若有更好的建議，但願看到的各位不吝指教。。。