京東到家的持續整合實踐之路

內容來源：2017年4月8日，京東到家資深測試開發工程師孫斌在“餓了麼技術沙龍北京測試專場”進行《持續整合實踐》演講分享。IT大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

閱讀字數: 1716 用時: 11分鐘

持續整合是一種軟體開發實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編輯、釋出、自動化測試）來驗證，從而儘快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的軟體。

1、減少風險：越早發現的錯誤，修正的費用越低。及時檢查軟體測試的健康狀況，減少釋出時的風險。

2、減少重複性的工作：通過自動化的持續整合可以將編譯、部署、測試等動作都變成自動化的，無需太多人工干預。

3、任何時間、任何地點都可以部署軟體：利用持續整合，可以經常對原始碼進行一些小改動，並將這些改動和其他的程式碼進行整合。如果出現問題，專案成員馬上就會被通知到。

京東到家是基於地理位置的o2o生活平臺。雖然業務和京東商城不太一樣，但是系統的複雜度不低於商城，從成立到現在有200+個服務。系統之間依賴度高，但是由於業務的特殊性，迭代速度比較快。如何使各個服務能夠快速部署快速測試上線，對測試和研發工程師形成了很大的挑戰。我們引入了持續整合的概念，並開始逐步實施。

持續整合幫京東到家解決了三個問題。

1、提測質量差。如果壓縮了開發週期，質量一定是不行的。

2、測試周期長。一旦程式碼質量變差，測試投入成本就會很高。

3、重複性的工作多。

持續整合需要整個team都達成共識，按統一好的規則去做同一件事。

我們先找了易做的、影響力大的事情去做，然後用一個專案去做試點，會得到一些資料，就可以用這些資料去說服領導和同事。

提高程式碼到git，程式碼靜態掃描，然後單元測試和程式碼覆蓋job會執行，之後編譯打包，部署到對應的伺服器上。

UI、jsf和App會執行自動化測試，並修復和分析失敗的case。如果有需要再做功能測試，收集功能測試程式碼覆蓋率。

目前我們對這套程式碼的要求就是要修復阻塞和重要級別的bug，新增程式碼必須達到一定的覆蓋率。所有系統都做到自動編譯、打包和部署。必須覆蓋主流程，不斷新增測試用例。及時檢視覆蓋率報告，對於新增程式碼業務邏輯必須全覆蓋。

第一階段：需要手動編譯、打包、部署。解決方案就是引入jenkins自動化編譯打包部署。

第二階段：伺服器硬碟打滿了，一臺機器上部署的服務太多，服務停止。我們做的就是定時清理硬碟空間，監控服務狀態，自動重啟服務，保證總體服務可用。

第三階段：主要問題是分散式服務之間調不通。是因為迭代速度快，開發在本地除錯，隨意修改本地配置檔案。組名不對導致呼叫不到服務。

我們部署了兩套測試環境，一套對外提供服務，供他人測試呼叫，一套自己使用。儲存本地配置，與線上配置比對，防止誤改。使用自動化測試，檢查整個系統的健康狀況，及時修復。

1、配置Sonar環境。

2、配置jenkins環境，下載sonarqube外掛，並進行配置。

3、在jenkins程式碼靜態掃描的job後，配置執行sonar。

Jenkins執行mvn clean install命令，生成程式碼覆蓋率報告。

1、啟動指令碼中插入監聽引數。

2、Dump出監聽檔案。

3、使用Ant指令碼生成最終的html。

配置到jenkins的持續整合環境。

1、配置maven pom.xml檔案。

2、配置Jenkins job。

當時選擇appium是因為它支援android和ios系統，支援現有框架和多種語言，而且可以跨應用。最重要的是appium不依賴於原始碼。

APP自動化測試在持續整合中也遇到了一些問題。針對網路不穩定失敗率高，我們引入了重試監聽，如果重試3次還不能通過，那就是有問題的。第二個問題是不容易定位case失敗，我們加入了截圖和log日誌功能，多打日誌加截圖，就能發現整體的問題所在。還有就是執行速度慢，android可以啟動多個服務，分佈執行。

以上是我今天分享的內容，感謝聆聽！

原文地址：t.cn/RoroPlK