京東持續整合實踐
京東持續整合實踐
導讀目錄：
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數應該大體一致並且最後重合。
文末備註：
此文書寫實踐是一期摸索實踐，寫了很久沒有時間釋出分享給大家，最近才有時間整體出來，這並不是最佳實踐，只是記錄實踐探索，希望能給大家帶來思路和借鑑，我的二次摸索實踐在進行中，希望後續有機會能給大家分享最佳實踐；