京東持續集成實踐
導讀目錄：
1、持續集成簡介
2、持續集成實踐
3、集成環境的部署及自動化測試
3.1、搭建J-auto系統
3.2、J-auto系統使用
4、持續集成數據分析
1、持續集成簡介
持續集成不僅僅是一項項目實踐，而是多項項目實踐的總和。在嘗試這些實踐時，不可避免要遇到一個問題：爲什麼要持續集成？如果不能很好地理解爲什麼，持續集成可能會進入誤區，不能帶來期望的效果。
質量、進度和成本是軟件項目關注的三大要素，它們互相依賴、互相制約。以前軟件生命週期模型是程序員負責編寫不同的模塊，在項目完成之前，一次性的把各個模塊集成在一起，再進行測試。使用該種方式會爲項目引入很多的未知因素和巨大風險－－開發工程師往往發現越來越多的Bug 等待他們去修復、許多嚴重問題不能在前期及時發現修正、需求頻繁變更導致項目後期時間嚴重不足等等，這些風險很有可能會威脅到項目的成功。隨着對產品的發佈要求越來越高、越來越頻繁，以前老的方式已經越來越不能滿足要求。持續集成允許代碼分批提交，代碼提交後立即測試，測試在開發過程中一直存在，直至開發完完畢，避免代碼積累很多後集成，造成代碼質量低下。可以有效地解決項目過程中的許多問題，快速、及時發現系統錯誤，有效地確保系統質量，減小項目的風險，使得團隊從容面對各種各樣的變化。在項目過程中持續集成更能及時呈現各種分析報告，讓項目中各種角色瞭解項目的真實狀況，從而爲正確選擇提供了數據基礎。
2、持續集成實踐
隨着京東業務爆炸式增長，需求迅速增加，這對應用系統及時且保證質量交付產生了極大的挑戰。此時如果沒有良好的管理和高效的工具來幫助測試，整個測試團隊必會處於混亂的狀態，導致無法在短時間內保質保量地完成應用系統的測試任務，那麼整個測試團隊命運必然是被淘汰。在此背景下，交易質量部提出一套高效可行的解決方案——京東持續集成JCI (JD Continuous Integration)。從而節約了時間成本，提高了應用系統質量，增強了項目的可見性，使研發工程師與測試工程師之間的協作更完美。持續集成閉環系統環節如圖25-1所示：
持續集成方案如圖25-2所示：
京東持續集成包含子系統：
- J-one：其負責靜態代碼掃描、代碼編譯、提交測試併發送提測JMQ消息等；
- J-auto：其負責接受提測JMQ消息、解析JMQ消息並自動搭建部署測試環境、自動執行測試用例併發送測試詳情報告、保存測試執行數據等；
- J-cim：展示各種分析彙總的結果數據等；
- Source：存儲系統代碼、測試腳本等數據等；
3、集成環境的部署及自動化測試
測試環境部署是一個重複且費時的工作。隨着需求增加，測試環境部署及應用系統測試的成本顯著增加。爲了減少工作成本提高效率，經過測試工程師們積極探索，成功地引入自動化部署及自動化測試。
自動部署及自動化測試方案整體流程圖如下：
流程圖解釋說明如下：
①通過京東J-one系統提交測試時，J-one會產生提測的JMQ消息：
②J-auto系統接受並解析JMQ消息，獲得提測的詳細信息，如：應用名稱、開發工程師、測試工程師、被測代碼分支、安裝介質下載地址等等；
③獲取應用於任務映射關係，關係包含：應用名稱、部署任務名稱、自動化測試任務名稱、部署目標主機ip、任務是否啓用等信息；
④調用主任務，主任務負責在京東雲下載安裝介質、分發安裝介質及部署腳本、調用部署子任務；
⑤執行部署，部署任務根據映射關係信息，執行部署腳本。部署完成後，發送部署結果反饋。如果成功部署則啓動自動化測試，否則回滾環境；
⑥自動化測試任務，從Source系統獲取測試相關測試腳本，運行測試腳本並反饋測試結果等信息。
3.1、搭建J-auto系統
J-auto系統包含兩部分，Jenkins任務調度模塊及Jenkins模塊。搭建步驟如下：
安裝JDK：
在應用服務器上的指定目錄下新建目錄，如：/xx/xx/java。將安裝包剪切到java下，並解壓。命令如下：
|
mv ./jdk-7u80-linux-x64.tar.gz /xx/xx/java/jdk-7u80-linux-x64.tar.gz cd /xx/xx/java/ tar –xvf jdk-7u80-linux-x64.tar.gz |
配置JAVA_HOME環境變量,命令是
|
Export JAVA_HOME=/xx/xx/java/jdk1.7.0_80 |
安裝tomcat：
在應用服務器上的指定目錄下新建目錄，如：/xx/xx/tomcat。將安裝包剪切到tomcat下，並解壓。命令如下：
|
mv ./apache-tomcat-7.0.30.tar.gz /xx/xx/tomcat/apache-tomcat-7.0.30.tar.gz cd /xx/xx/tomcat/ tar –xvf apache-tomcat-7.0.30.tar.gz |
將Jenkins任務調度模塊部署到tomcat 容器中。
安裝jenkins：
將安裝包剪切到/xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins下並解壓。
命令如下：
|
mv ./ jenkins.war /xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins/jenkins.war cd /xx/xx/tomcat/apache-tomcat-7.0.30/webapps/jenkins/ jar –xvf jenkins.war |
啓動jenkins，在tomcat的根目錄下，執行
|
cd ./bin ./startup.sh |
jenkins全局配置
訪問jenkins系統，註冊用戶並登錄後，點擊左側的【系統管理】菜單，再點擊【系統設置】，界面如下：
圖25-4 Jenkins系統設置
圖注：
- Jenkins主目錄，存放Jenkins任務數據、構建數據等；
- 選擇【Role-Based Strategy】搭配【Role-based Authorization Strategy】插件實現根據角色權限命名任務；
- 郵件配置，包含郵件服務器，郵件模板等信息
角色權限配置，首先，點擊【系統管理】，在點擊【Configure Global Security】，啓用及配置安全策略，如下圖25-5所示：
圖25-5 配置安全策略
圖注：
- 啓用安全
- 安全域選擇【Jenkins專有用戶數據庫】並允許用戶註冊
- 授權策略選擇【Role-Based Strategy】
其次配置角色權限，如圖25-6所示：
圖注：
- 創系統中的全局角色及賦權
- 創建項目角色及賦權
- 建機器節點角色及賦權
最後，爲用戶分配角色。點擊【系統管理】，點擊【Manage and Assign Roles】，點擊【Assign Roles】，界面如圖25-7：
圖注：
- 給用戶關聯全局角色
- 用戶關聯項目角色
- 用戶關聯機器節點角色
配置機器節點
點擊頁面左側【系統管理】，點擊右側頁面的【管理節點】，點擊左側的【新建節點】，節點信息編輯界面如下：
- 節點名稱
- 設置執行者的數量
- Jenkins執行目錄
- 機器節點的標籤名
- 機器節點的使用方式，選擇【只允許運行綁定到這臺機器的Job】
- 機器節點的啓動方法，選擇【Launch slave agents on Unix machines via SSH】
- 節點鏈接啓動時的ip地址
- 節點鏈接啓動時鑑權的賬戶與密碼
- 節點機器上的工具配置，支持JDK、maven、ant等
配置完成後，鏈接節點。
Jenkins主任務配置
首先創建任務時，選擇【構建一個自由風格的軟件項目】，如圖25-9所示
配置【General】信息，如圖25-10：
- 任務名稱；
- 任務描述；
- 歷史構建信息保存策略設置；
- 設置任務運行時的接受的參數，圖片中只展示部分；
- 設置任務支持併發運行；
- 設置的任務運行的目標機器節點；
配置【構建環境】，如圖25-11，介紹如下：
- 勾選【Abort the build if it's stuck】，超時策略選擇【Absolute】，時間閾值25分鐘，此設置保證運行異常時，任務可以中斷，防止影響後續其他任務的運行。
配置【構建】，如圖25-12所示，介紹如下：
增加構建步驟時，選擇【Execute shell】，編寫腳本。
配置【構建後操作】，如圖25-13所示，介紹如下：
點擊【增加構建後操作步驟】，選擇【Editable Email Notification】，設置構建後的郵件通知策略。
3.2、J-auto系統使用
J-auto系統搭建完成後，下面就是應用J-auto系統進行自動部署和自動化測試了。首先，需要在Jenkins中新建一個自動化測試任務，與主任務不同，在創建任務時選擇【構建一個maven項目】，如下圖所示：
【源碼管理】配置中，①處配置測試腳本源碼地址及鑑權賬號和密碼；②處設置測試腳本的分支名稱。
【Build】環節設置
①配置Maven的.pom文件
- 置Maven的運行命令
然後新建一個自動部署任務，其與主任務配置類似。需要注意此任務存在shell腳本調用shell腳本的情況，【構建】環節編寫shell腳本時，需要加BUILD_ID=[DoNotKillMe]。防止外層腳本運行完成，但是內層腳本仍在運行時，內層shell腳本被終止，如圖25-17所示。
另外【構建後操作】除了發送反饋郵件配置，增加【Trigger parameterized build on other projects】步驟，用來關聯上一步建立的自動化測試任務，啓動自動化測試任務進行測試。
- 需要啓動的自動化測試任務名稱。
- 設置啓動後續任務策略。圖中配置是部署成功後啓動後續任務。
- 勾選後，啓動後續任務不使用參數。
映射關係配置，是整個系統運行起來的關鍵環節。指明瞭那個應用系統部署在那臺機器及應用部署的目錄、應用的域名等信息，鏈接提測到自動部署自動化測試環節，如圖6-19所示。
此時研發通過J-one系統提交測試，J-auto接受提測的JMQ消息，就可以觸發後續的自動部署、自動化測試、及各環節反饋，如圖25-20。
4、持續集成數據分析
持續集成過程中，我們可以從編譯、部署、測試等環節中拿到許多相關數據。通過對這些數據分析和數據挖掘，可以幫助我們後續質量評估分析、質量趨勢分析、質量可回溯分析等，有效地規範項目流程，發出項目風險預警。下面單從應用缺陷方面進行分析。
應用缺陷數據分析，是持續集成數據分析中一部分，顧名思義就是對測試過程中發現的各種缺陷的彙總分析。既然是數據分析就得有數據模型，應用缺陷數據分析的模型如下:
|
指標 |
指標說明 |
|
所屬項目 |
被測應用歸屬的項目 |
|
所屬模塊 |
產生缺陷的功能模塊 |
|
發現階段 |
發現缺陷的時間，如：需求評審、設計評審、編碼開發、單元測試、功能測試等 |
|
研發工程師 |
編寫相關模塊及解決該問題的人員 |
|
缺陷級別 |
缺陷的嚴重性，如：建議、輕微、一般、嚴重等 |
表25-1 缺陷數據分析模型
通過構造缺陷在軟件生命週期的各環節的屬性進行分析，從不同維度得到各類缺陷的缺陷個數和缺陷比例，積累得到各類缺陷的基準值，用於評估測試活動，指導測試改進和整個生命週期流程的改進。比如，按模塊進行單維度分析，可以得出各個功能模塊的缺陷密度，從而瞭解各個功能模塊的質量狀況；還有按發現階段分類分析，按模塊加驗證程度分類分析等等；
再有通過已有項目歷史數據進行缺陷趨勢分析，缺陷趨勢可以通過每日新建bug、每日關閉bug、累計未解決的bug，累計關閉bug、bug總數等指標進性分析，通過缺陷增長和減少的趨勢，瞭解測試的效率和開發修復bug的效率、測試瓶頸等。可以通過每日新建bug趨勢來了解測試的效率，正常來說提測中前期每日新增bug指標應該逐漸增加並達到一個峯值，然後呈下降趨勢，最後趨向於0。符合這個趨勢說明測試效率和測試質量較高，且開發修復bug新引入bug的概率是比較小的。每日關閉bug指標反映了研發工程師的處理響應速度。每日關閉bug數大說明研發修復bug效率高。如果新建的bug數越來越小，但是關閉的bug數量一直小於累計未解決的bug數，則說明研發同學效率低，是項目的瓶頸。bug總數曲線和累計關閉bug數應該大體一致並且最後重合。
文末備註：
此文書寫實踐是一期摸索實踐，寫了很久沒有時間發佈分享給大家，最近纔有時間整體出來，這並不是最佳實踐，只是記錄實踐探索，希望能給大家帶來思路和借鑑，我的二次摸索實踐在進行中，希望後續有機會能給大家分享最佳實踐；