一鍵式持續交付信息管理系統

前言

在持續交付過程中，每次交付都不可避免地要花費大量時間精力用于環境配置、build、回歸（Regression）測試、結果管理、問題跟蹤、質量分析、總結，一個可以自動化完成所有功能的智能系統將大大提高開發、測試和管理效率。

本文基于開源工具或技術搭建一鍵式持續交付管理系統，對于任何代碼的更新或修改，只需要發起一個 build 請求，剩下的所有流程將自動完成，用戶只需要關注是否有分配給他的 issue 即可，并且本系統將所有 build、測試信息納入統一管理存儲到數據庫，方便隨時查閱。通過該系統提供的查詢網站，用戶可以隨時查看 bug、build、regression 的趨勢，以及對一段時間內或某個 release 的情形進行分析總結。

環境部署測試整體架構

本章主要介紹一鍵式持續交付信息管理系統的整體框架和流程，如圖 1 所示。從大的功能點上劃分，該系統主要包括：Jenkins 控制模塊、Build 階段、部署階段、測試階段、郵件通知模塊、數據庫、查詢網站，每部分的具體功能將在下一章介紹。

圖 1. 一鍵式持續交付信息管理系統整體架構

該系統比較典型的一個工作流程如下：

1. 工程師在完成代碼提交后，便可發起新一輪的 build 請求，這個請求將被發送給 Jenkins 控制模塊。
2. Jenkins 作為整個系統的控制單元，在收到請求后將啟動 job 觸發 Build 階段。Build 階段主要包括 Build 和 BVT（版本驗證測試），此階段無論成功或是失敗都會有郵件通知用戶，并且此次 build 和 BVT 的信息將會被插入到數據庫的 buildinfo 表中。如果成功，build 將會被發布到 Nexus 上，一個成功的 Build Stage 將會觸發 Deploy Stage。
3. Deploy 階段將會進行實際回歸測試環境的部署，此階段主要通過 Docker 部署所需要的 Spark Cluster 服務端（圖中 Docker Cluster）以及執行測試用例所需要的客戶端（圖中 Docker Client）。圖中虛線表示此部分并不是必須的，如果環境在此階段之前已經準備完成便可以跳過此階段直接進行測試以節省時間。比如，我們可以將所需要的 Docker 鏡像事先存儲在機器上以便直接使用，而不是每次都去重新 build 鏡像。Deploy 階段完成后管理員將會收到郵件通知以便及時了解環境配置是否存在異常。
4. 環境準備完成后，將會開始進行實際的測試（圖中 Test Stage），主要包括 Regression 測試和代碼覆蓋率測試，我們將代碼覆蓋率測試作為一個非必選項（圖中虛線部分 Code Coverage）。在開始測試前，將從 Nexus 上下載所需要的 build，與 Github 進行測試代碼的同步。測試完成后，通過專門的結果分析過程（圖中 Result Analysis），用戶將會收到包含此次測試信息的郵件，此次測試的統計信息報告會被 push 到 Github Wiki 上以便后續查閱，詳細測試信息插入到數據庫的 regressioninfo 表中。如果存在失敗的測試用例，Github 上將會自動創建相關失敗模塊的 issue 以便于跟蹤問題，并將改 issue 指定給對應模塊的管理人員。
5. 上面四步基本可以組成一個完成的交付流程。此外，我們特地設計開發了一個查詢網站（圖中 Query Website）用于隨時查閱 build，regression 和 bug 信息，以便于統計和總結。查詢網站是對數據庫信息表的直觀展示和總結，包括 buildinfo 表、regressioninfo 表和 buginfo 表，其中 buginfo 表是從 Github 上持續獲取 bug 信息插入到數據庫中的。用戶可以通過查詢網站隨時去查詢每個 build 的信息、每次 Regression 測試的信息、每個 bug 的信息，也可以對一個時間段或者某個 release 的 build、regression、bug 情況進行查詢。

功能和輸出

本章將對上一章節所述架構中的各個部分進行具體介紹，重點介紹各部分的功能及輸出。

Build 階段

Build 階段主要進行代碼的編譯、build 輸出、BVT。對外交付的實際版本由此部分產生，并且對代碼進行了簡單的測試。

功能：

1. 代碼編譯、build、BVT。
2. 插入 build 信息到數據庫 buildinfo 表。
3. 將成功的 build 發布到 Nexus 上。
4. 觸發 Deploy 環境的流程。
5. 發送郵件通知用戶。

輸出：

1. Build。
2. Build 成功或者失敗的郵件。
3. 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 版本。

功能：

1. 部署測試環境的 Spark Cluster。
2. 部署測試環境的 Client 端。
3. 觸發測試流程。
4. 發送郵件通知環境管理員。

輸出：

1. Spark Cluster 環境。
2. 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 的質量，也是本輪交付的關鍵。

功能：

1. Regression 測試。
2. 代碼覆蓋率測試。
3. 將本輪測試信息插入到數據庫的測試表中。
4. 分析測試結果并生成測試用例級的詳細測試報告。
5. 發布 Wiki 測試報告到 Github 上。
6. 如果測試中存在失敗用例則在 Github 上創建 issue。
7. 發送測試完成郵件給用戶。

輸出：

1. 測試郵件。
2. Wiki 報告。
3. 用例級詳細測試報告。
4. 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 內的測試次數趨勢、每次測試的用例通過率、測試的成功失敗占比等。

對于每部分來說，頁面最下方是數據庫的直接展示（由于頁面大小限制未在截圖中顯示）。

結束語

本文側重于從架構和流程上介紹一鍵式持續交付信息管理系統，希望您能夠從整體上對于系統有個完整的認識，通過了解系統各部分的功能和輸出從而明白整個系統是如何運作的。而實際系統的搭建涉及大量技術細節，由于內容過于繁瑣且文章篇幅有限在此不能一一介紹，如果您感興趣可以在實際系統搭建過程中去體會，本文最后一個參考資源中也有部分介紹。本系統早已在實際工作中投入使用，并且經過不斷的優化提升，目前運行流暢，極大的提升了開發、測試和交付效率。另外，通過把工作中的信息存儲至數據庫中從而納入統一管理，極大的提高了工作質量和管理人員的統計和管理效率。

原文轉自：https://www.ibm.com/developerworks/cn/opensource/os-one-click-continuous-delivery-information-management-system/index.html