一鍵式持續交付資訊管理系統
前言
在持續交付過程中，每次交付都不可避免地要花費大量時間精力用於環境配置、build、迴歸（Regression）測試、結果管理、問題跟蹤、質量分析、總結，一個可以自動化完成所有功能的智慧系統將大大提高開發、測試和管理效率。
本文基於開源工具或技術搭建一鍵式持續交付管理系統，對於任何程式碼的更新或修改，只需要發起一個 build 請求，剩下的所有流程將自動完成，使用者只需要關注是否有分配給他的 issue 即可，並且本系統將所有 build、測試資訊納入統一管理儲存到資料庫，方便隨時查閱。通過該系統提供的查詢網站，使用者可以隨時檢視 bug、build、regression 的趨勢，以及對一段時間內或某個 release 的情形進行分析總結。
環境部署測試整體架構
本章主要介紹一鍵式持續交付資訊管理系統的整體框架和流程，如圖 1 所示。從大的功能點上劃分，該系統主要包括：Jenkins 控制模組、Build 階段、部署階段、測試階段、郵件通知模組、資料庫、查詢網站，每部分的具體功能將在下一章介紹。
圖 1. 一鍵式持續交付資訊管理系統整體架構
該系統比較典型的一個工作流程如下：
- 工程師在完成程式碼提交後，便可發起新一輪的 build 請求，這個請求將被髮送給 Jenkins 控制模組。
- Jenkins 作為整個系統的控制單元，在收到請求後將啟動 job 觸發 Build 階段。Build 階段主要包括 Build 和 BVT（版本驗證測試），此階段無論成功或是失敗都會有郵件通知使用者，並且此次 build 和 BVT 的資訊將會被插入到資料庫的 buildinfo 表中。如果成功，build 將會被髮布到 Nexus 上，一個成功的 Build Stage 將會觸發 Deploy Stage。
- Deploy 階段將會進行實際迴歸測試環境的部署，此階段主要通過 Docker 部署所需要的 Spark Cluster 服務端（圖中 Docker Cluster）以及執行測試用例所需要的客戶端（圖中 Docker Client）。圖中虛線表示此部分並不是必須的，如果環境在此階段之前已經準備完成便可以跳過此階段直接進行測試以節省時間。比如，我們可以將所需要的 Docker 映象事先儲存在機器上以便直接使用，而不是每次都去重新 build 映象。Deploy 階段完成後管理員將會收到郵件通知以便及時瞭解環境配置是否存在異常。
- 環境準備完成後，將會開始進行實際的測試（圖中 Test Stage），主要包括 Regression 測試和程式碼覆蓋率測試，我們將程式碼覆蓋率測試作為一個非必選項（圖中虛線部分 Code Coverage）。在開始測試前，將從 Nexus 上下載所需要的 build，與 Github 進行測試程式碼的同步。測試完成後，通過專門的結果分析過程（圖中 Result Analysis），使用者將會收到包含此次測試資訊的郵件，此次測試的統計資訊報告會被 push 到 Github Wiki 上以便後續查閱，詳細測試資訊插入到資料庫的 regressioninfo 表中。如果存在失敗的測試用例，Github 上將會自動建立相關失敗模組的 issue 以便於跟蹤問題，並將改 issue 指定給對應模組的管理人員。
- 上面四步基本可以組成一個完成的交付流程。此外，我們特地設計開發了一個查詢網站（圖中 Query Website）用於隨時查閱 build，regression 和 bug 資訊，以便於統計和總結。查詢網站是對資料庫資訊表的直觀展示和總結，包括 buildinfo 表、regressioninfo 表和 buginfo 表，其中 buginfo 表是從 Github 上持續獲取 bug 資訊插入到資料庫中的。使用者可以通過查詢網站隨時去查詢每個 build 的資訊、每次 Regression 測試的資訊、每個 bug 的資訊，也可以對一個時間段或者某個 release 的 build、regression、bug 情況進行查詢。
功能和輸出
本章將對上一章節所述架構中的各個部分進行具體介紹，重點介紹各部分的功能及輸出。
Build 階段
Build 階段主要進行程式碼的編譯、build 輸出、BVT。對外交付的實際版本由此部分產生，並且對程式碼進行了簡單的測試。
功能：
- 程式碼編譯、build、BVT。
- 插入 build 資訊到資料庫 buildinfo 表。
- 將成功的 build 釋出到 Nexus 上。
- 觸發 Deploy 環境的流程。
- 傳送郵件通知使用者。
輸出：
- Build。
- Build 成功或者失敗的郵件。
- BVT 報告。
Build 階段輸出的郵件如圖 2 所示，該郵件為 Build 成功的郵件，失敗的郵件類似，標題中會包含明確的版本號和成功失敗標誌。
圖 2. Build 階段成功郵件
郵件內容中有具體的 Jenkins 連結以便於查閱本次 build 的 Jenkins Job 情況，還有對應的 BVT 報告以便查閱各個模組以及所有 BVT 測試用例的詳細情況，如圖 3 所示。
圖 3. Build 階段 BVT 報告
Deploy 階段
Deploy 階段主要進行 Spark Cluster、Client 端環境的部署和配置，為了環境的易用性本系統採用了 Docker。Spark Cluster 和 Client 的部署均通過 Dockerfile 指令碼實現，支援部署各種組合引數需要的環境，如不同的 Spark 版本、Java 版本、Scala 版本。
功能：
- 部署測試環境的 Spark Cluster。
- 部署測試環境的 Client 端。
- 觸發測試流程。
- 傳送郵件通知環境管理員。
輸出：
- Spark Cluster 環境。
- Client 端。
Deploy 階段輸出的 Spark Cluster 環境部署成功的郵件如圖 4 所示。
圖 4. Deploy 階段成功郵件
通過郵件中的連結可以訪問該環境對應的 yarn 埠檢視具體資訊，如圖 5 所示。
圖 5. Spark Cluster Yarn 頁面
在機器上可以通過執行 docker ps 命令查詢所啟動的 Docker container 情況，此處啟動了 namenode 和 client1 兩個 container，如圖 6 所示，其中 namenode 即為 Spark Cluster 的 namenode，當然也可以啟動其他 datanode 節點，本系統為了簡便沒有啟用。client1 為第一個客戶端，當存在多個客戶端並行測試時此處會啟動多個 client。
圖 6. namenode 和 client container
Test 階段
Test 階段主要進行 Regression 和程式碼覆蓋率的實際測試。所有的 Regression 測試用例都是在這一階段執行的，測試結果直接反應本輪 build 的質量，也是本輪交付的關鍵。
功能：
- Regression 測試。
- 程式碼覆蓋率測試。
- 將本輪測試資訊插入到資料庫的測試表中。
- 分析測試結果並生成測試用例級的詳細測試報告。
- 釋出 Wiki 測試報告到 Github 上。
- 如果測試中存在失敗用例則在 Github 上建立 issue。
- 傳送測試完成郵件給使用者。
輸出：
- 測試郵件。
- Wiki 報告。
- 用例級詳細測試報告。
- Issue。
如果測試過程中存在失敗用例，使用者將會收到帶有詳細資訊的測試郵件，如圖 7 所示，郵件中給出了本輪測試的用例級詳細測試報告、測試的輸出檔案位置、Github 上的 Wiki 報告。
圖 7. 測試階段失敗郵件
用例級詳細測試報告如圖 8 所示，該報告是使用 Ant 工具 build 完成，然後放入 Apache Tomcat 中以方便使用者訪問。從中可以檢視到所有模組、所有用例的具體情況（可以看到用例失敗的具體原因）。
圖 8. 用例級詳細測試報告
Wiki 測試報告如圖 9 所示，該報告是對本輪測試的一個總結，報告中包括測試環境資訊、issue 個數、程式碼覆蓋率連結以及各模組情況。其中程式碼覆蓋率報告如圖 10 所示。
圖 9. Wiki 測試報告
圖 10. 程式碼覆蓋率報告
系統自動建立的 issue 如圖 11 所示，issue 是通過 Github API 按模組自動建立，標題中包含模組名和其失敗的用例個數，內容包含測試 build 號、詳細測試報告、對應的 Assignees、Labels、Releases 等，當模組的負責人收到指定給他的 issue 時才需要進行後續分析，否則則認為其所負責的模組在本輪測試中沒有問題。
圖 11. Issue
資料庫
資料庫用來儲存日常開發測試流程中的各種資訊，主要包括 build 資訊、測試資訊、bug 資訊，
分別儲存在 buildinfo、 regressioninfo、 buginfo 表中。表中可以盡你所能多儲存資訊以便於後續查閱或網頁展示。
build 資訊是在 Build 階段結束時插入的，測試資訊實在測試階段結束時插入的。需要注意的是 buginfo 表中除了儲存每次測試階段所建立的 issue 資訊外，還是儲存從 Github 上不斷獲取的外部或者個人建立的其他 bug 資訊，這個舉動是通過我們維護的一個程序實時獲取的。
查詢網站
查詢網站作為對資料庫資訊的展示和總結，是整個系統中對於使用者來說最直觀的一個部分。如圖 12 所示，查詢網站包含三個部分：Regression Analysis、Bug Analysis、Build Analysis，分別對應資料中的三張表。
圖 12. 查詢網站
- 對於 Build Analysis，網站支援查詢一個時間段或者 release 內的 build 次數趨勢、每個 build 的時間和 UT 覆蓋率、build 的成功失敗佔比等。
- 對於 Bug Analysis，網站支援查詢一個時間段或者 release 內的 bug 個數趨勢、內部外部 bug 佔比、各模組 bug 佔比、有效無效 bug 佔比等。
- 對於 Regression Analysis，網站支援查詢一個時間段或者 release 內的測試次數趨勢、每次測試的用例通過率、測試的成功失敗佔比等。
對於每部分來說，頁面最下方是資料庫的直接展示（由於頁面大小限制未在截圖中顯示）。
結束語
本文側重於從架構和流程上介紹一鍵式持續交付資訊管理系統，希望您能夠從整體上對於系統有個完整的認識，通過了解系統各部分的功能和輸出從而明白整個系統是如何運作的。而實際系統的搭建涉及大量技術細節，由於內容過於繁瑣且文章篇幅有限在此不能一一介紹，如果您感興趣可以在實際系統搭建過程中去體會，本文最後一個參考資源中也有部分介紹。本系統早已在實際工作中投入使用，並且經過不斷的優化提升，目前執行流暢，極大的提升了開發、測試和交付效率。另外，通過把工作中的資訊儲存至資料庫中從而納入統一管理，極大的提高了工作質量和管理人員的統計和管理效率。