COMPASS專案CI實踐

這篇文章大體上是從COMPASS整個專案組的角度介紹CI實踐的一些經驗和成果，但有些部分偏重於從QA的視角看CI給我們的工作帶來的變化。

一、為什麼引入CI

客戶需求的隨時而變要求我們更快做出響應，開發完成並部署上線新的功能模組。這樣的快速上線需要一種機制來保證每次所釋出版本的可用性和質量。CI就是這樣一種能為提交的每次程式碼修改提供可用性和質量保證的機制。

二、CI是什麼

我理解CI的核心涉及兩方面：專案資料共享和構建自動化。

所有人共享一個有版本控制的程式碼庫，或者更準確地說是資料庫，因為這裡面既包括直接提供客戶價值的業務程式碼，也包括用來驗證業務程式碼是否符合預期設計目標的測試程式碼，除此之外，同時還包括專案文件、資料庫變更指令碼、部署指令碼等，總之，目標就是將所有與專案相關的東西都納入版本控制系統中，並且使之為專案組內所有的人共享。

因為CI涉及頻繁的構建，我們需要通將構建過程自動化來減少構建帶來的成本。通過一系列經過測試的構建指令碼，實現每次程式碼提交都觸發一次自動的構建，或者我們也可以選擇在適當的時機手動觸發一次構建。總之，要提供一套能夠方便地實施構建、釋出的基礎設施，可以是一鍵觸發的，甚至是由程式碼提交自動觸發的。

三、COMPASS專案的CI實施情況及成果介紹

COMPASS專案從4月中旬開始實施CI，到現在為止大致完成了以下幾項CI改造：

1. 搭建基於hudson的CI環境

搭建hudson基礎環境。

我們使用一臺Linux主機作為hudson執行的平臺，使用Tomcat作為hudson執行的容器，安裝了靜態程式碼檢查、build pipeline、覆蓋率分析、副本歸檔、狀態監視、svn版本控制、maven專案管理等外掛。

建立構建任務並按檢視分類管理。

按檢視對各種構建任務進行分類管理。這些檢視包括：當前開發模組所依賴的基礎庫模組的構建任務、當前開發模組的構建任務、部署測試環境的構建任務、產品釋出的構建任務。這樣的分類檢視使各個構件任務的意義更清晰，更加便於管理。

當前基礎庫模組的構建任務和當前開發模組的構建任務都選擇maven2型別的任務，通過使用模組的POM檔案可以大大減少所需的構建配置。並且設定構建觸發機制為每次程式碼提交都觸發一次構建。這樣的觸發頻率能及時反映出有問題的程式碼，確保整合到程式碼庫的程式碼總保持是可工作的版本。另外，還通過pipeline機制建立依賴庫模組與當前開發模組之間的上下游關係，即，一旦基礎庫模組完成一次成功的構建，將自動觸發當前開發模組的一次構建，以此來確保基礎庫更新後當前開發模組仍能正常工作。

部署測試環境的構建任務和產品釋出的構建任務都是自由風格的任務。其本質是通過呼叫經過測試的部署指令碼來從從程式碼庫檢出特定版本的程式碼，經編譯打包後部署到測試環境和釋出產品庫。這兩類任務採用手動觸發的方式，即，只在需要時手動觸發一次構建。

2. 打通快速提測和快速上線的流程

通過編寫部署測試環境和釋出產品的相關指令碼，並將其以構建任務的形式整合到hudson CI環境，極大簡化了提測和上線流程，保證了快速提測和快速上線的實現。目前，完成一次提測只需不到2分鐘時間，完成一次上線也不超過15分鐘。這成為我們能夠快速迭代、快速交付產品的重要基礎。

3. 確定以半周為單位的持續釋出模式

我們的專案已一週為一個迭代，每個迭代安排兩次上線。這樣的頻繁迭代最大地滿足了對使用者需求的快速響應。一般從使用者反饋一個需求到這個需求開發完成交付給使用者，之間間隔的時間不會超過兩週。這極大地改善了使用者體驗。

到目前為止，經過六個迭代，我們已經持續向使用者釋出了12個版本。專案基本保持著勻速、高效的生產力。

4. 測試多樣化和自動化

測試已成為專案的共識。

目前單測已變為RD日常開發工作的一部分，專案Core模組的單元測試已經覆蓋了80%的有效程式碼；在RD的配合下，專案也越來越多的關注於Service模組的資料庫相關的測試。

整合測試。COMPASS系統二期啟動後，做了很多的程式碼重構，而諸多的重構僅僅依靠單測已不能滿足專案對質量的要求。所以團隊在摸索後，引入了DDT（資料驅動測試）的測試理念，也就是由QA設計測試架構和測試資料，由RD負責程式碼實施，這樣能夠最大限度的發揮RD與QA的長處。以專案最重要的模組——任務生命週期管理模組為例，在QA設計了測試架構後，RD僅用3天時間就將架構實現，與此同時，QA為任務生命週期管理模組設計了60幾個測試用例場景，幾乎覆蓋了90%的邏輯，這最大限度的保障了任務生命週期管理模組的正確性以及未來重構的迴歸需求。

除了程式碼級別的單元測試，和資料驅動的整合測試，專案採用Selenium進行功能測試，以保證QA以最接近真實使用者體驗的方式測試系統，經過QA三週的努力，目前Selenium的測試Case已經達到40多個，覆蓋了任務資訊維護、登入許可權控制等系統主要功能模組，在快速交付的後期，為QA節省了很多的迴歸時間，是快速提測和快速上線的重要保證。

更重要的是，目前我們的單測、整合測試和功能測試已經整合到Hudson環境，形成了開發、提測和上線的Pipeline。

四、目前存在的問題及後續改進措施

1. 測試用例分級和分階段執行的進一步細化

目前我們的測試體系已經比較完善，包括了單元測試、整合測試和功能測試等多種形式，能從各個層面保證產品的質量。

但隨著系統功能的豐富，測試用例的數量也會繼續增長，每次執行測試需要的時間也越來越長。這就需要我們對測試用例進行分級，在不同階段只選擇執行相應級別的case。在儘可能保證產品質量的前提下，保持持續整合的快速進行。

2. 完善效能測試

隨著系統推廣使用，大量併發操作和大資料量成為對系統的一大考驗。下一步，我們將規劃更完善的效能測試，找出系統瓶頸進行優化，確定系統效能極限，對系統的承載能力做到心中有數。

而效能測試一般需要較長的測試時間，並且佔用大量系統資源。這就要求我們在持續整合環境中合理規劃效能測試的頻度和範圍。做到既滿足效能測試需求，又不影響持續整合的快速行進流程。

(作者：zhangguiying)