如何使用 DevOps 提升區塊鏈項目的工程質量與測試效率

主文分享介紹了溪塔團隊如何運用 DevOps 技術體系讓開發和測試、運維進行高效協做，如何使用 CI/CD 進行區塊鏈軟件自動化測試、軟件發佈；設計 CI/CD 流水線時須要注意哪些問題；區塊鏈軟件自動化測試有哪些難點；如何提升自動化測試運行效率；什麼樣的測試報告纔是好的報告；測試框架優化實戰經驗分享。

分享大綱

背景介紹
DevOps 流程 - 需求、開發、測試、運維、監控一體化
敏捷開發與 DevOps - 開發和測試、運維應該如何協做
爲何要自動化測試？
介紹 CI/CD 流水線
如何設計測試流水線
實戰經驗：優化流水線
實戰經驗：優化測試框架

背景介紹

爲了提升軟件的研發效率、保證軟件質量、高效服務運維，溪塔團隊在開發管理上實踐敏捷開發、使用 DevOps 進行自動化運維、實行持續的自動化測試。在介紹怎麼作以前，先說下溪塔團隊作了什麼，這樣能比較好理解知道團隊爲何要這樣作。

溪塔科技團隊在 2016 年開發了一款區塊鏈軟件 CITA，並在 2017 年進行了項目開源：https://github.com/cryptape/cita

CITA 是溪塔團隊從頭開始自主研發的一個高性能區塊鏈內核，具備微服架構、水平擴展、組件可插拔、高性能這些特質。區塊鏈服務簡單能夠看做是一種分佈式的帳本同步系統。爲了簡化應用開發者的使用，溪塔團隊開發了與之配套的各類開發、調試工具、組件，例如：

CITA 內核與各組件的關係圖：

這些工具都是開源的：
https://www.citahub.com/#comp...

具體怎麼作

溪塔團隊使用敏捷開發中的 Scrum 框架管理團隊目標和進度。敏捷開發的目標是經過迭代開發的方式交付可工做的軟件。溪塔團隊會將一個大的版本做爲一個Milestone（里程碑），定義好必需要完成的總目標和時間點，而後切分紅幾個較短工做週期的 Sprint（迭代），每一個 Sprint 有本身要完成的階段目標。

溪塔團隊使用 Story Point 來評估每一個任務的完成時間，使用燃盡圖反饋任務完成進度，以即可調控每一個 Sprint 的節奏和進度，以下圖，是溪塔團隊一個子產品開發過程的各個 Sprint 裏的燃盡圖：

在具體的任務管理上溪塔團隊使用 Kanban（看板）工具來跟蹤每一個成員的任務狀態，以下圖：

看板是一種圖形化的展現工具，因爲人類天生對視覺化的信息更容易理解，經過它能夠很直觀的反應每一個任務的狀態、同時也是一種工做量的直觀呈現，讓開發組中每一個成員均可以清晰知道本身、同時瞭解到其餘人的工做進展。

實踐 DevOps

軟件開發不僅是把代碼編寫出來就完事，還須要通過測試保證完整性、把測試後的軟件部署到服務器上，還要設置監控保障服務運行正常，並能收集反饋給產品、開發團隊對軟件功能、質量進行持續的改善，纔是一個完整可用的服務開發到上線的過程，整個過程如上圖所示，一環銜接一環。

如何實踐 DevOps

如上圖所示，DevOps 不單是運維團隊的事情，而是開發、運維、測試各類崗位人員一體化實施的一個過程。溪塔團隊要求作到流程規範化，這樣各個職能成員能互相瞭解對方的工做輸出預期，才能高效協做。流程規範化後，才能使用工具進行自動化來提升工做效率和減小人爲產生的故障。讓各環節的協做像是流水線般清晰可感知、可預期。

有人認爲要實踐 DevOps 要求團隊成員都是全棧工程師，而溪塔團隊認爲專業分工才能深刻和精通，所以能夠將團隊分爲區塊鏈開發、測試開發、運維開發團隊，注意到每一個崗位都是有「開發「字眼，具有有編程能力的團隊纔是能有效實踐 DevOps 的根本。

給溪塔團隊設定3個目標：

1. 開發區塊鏈軟件 - 軟件代碼 用 CI 進行自動化代碼質檢、測試、構建、發佈
2. 測試區塊鏈軟件 - 測試代碼 用 CI 進行冒煙、迴歸、性能、穩定性測試
3. 運維區塊鏈服務 - 監控服務 用 CI 進行主動監控、被動告警

對這樣的團隊的要求：

開發、測試、運維均要求有編程能力
開發、測試、監控服務的代碼，均聽從相同的開發流程、使用CI工具

開發流程

使用 GitHub Flow 進行代碼管理， 本地建立 feature 分支 -> 發PR -> 代碼審查 / CI 檢查 -> 合併 master 分支：

自動化運維

使用 CI/CD 流水線 進行自動化構建、測試、發佈、部署：

開發人員的代碼開發完成會進行代碼審查、靜態代碼掃描檢查代碼規範和代碼安全檢查、運行自動化測試；根據不一樣的分支合併策略進行不一樣環節的自動化部署，如合併到 develop 分支會觸發 staging 環境的部署，部署成功後自動通知測試人員進行驗收測試；合併到 master 分支會觸發 production 環境的部署，部署成功後自動發送上線通知讓運營人員進行運營使用。使用自動化的 CI/CD 工具和流程，能夠把功能開發到上線時間，縮短到開發人員提交代碼的最後一刻，而且在 CI 服務上有記錄，每一個人都能知道是什麼人、在何時、部署了什麼改動、到哪一個環節，提升了運維效率也減小了人工操做過程的人爲事故可能性。

服務監控

運維使用 ELK 服務進行日誌收集、數據分析，以下圖，溪塔團隊對測試鏈各個節點上服務的日誌收集和分析，出現軟件故障時方便運維、開發人員瞭解緣由。

爲了方便 CITA 服務的運維，溪塔的運維團隊開發了 CITA 的監控服務，可用於監控節點中 CITA 的服務運行狀況，包括採集區塊鏈數據、CITA 進程的存活監控、運行環境監控、故障自動告警通知，提供給開發、運維人員友好的可視化的面板，以下圖：

一樣的，這個監控工具的自己的開發流程也是同樣聽從一樣的 DevOps 實踐，一樣也是開源的：https://github.com/cryptape/c...

持續自動化測試

提升了開發、運維效率，還要保障軟件的質量，這個是溪塔測試團隊的工做重點。下圖是軟件測試中著名的測試金字塔，測試金字塔說明了一種兩難的境地：越是上層的測試，就會耗費越多的精力、時間和成本。

溪塔的測試團隊的工做重點正是最耗時間、資源的系統測試的自動化。這並非說開發團隊就不用管測試了，開發團隊主要編寫單元測試、集成測試等的白盒測試。

由於溪塔團隊認爲：

自動化測試才能讓 QA 的價值最大化；
自動化須要 CI 工具來作管理和執行。

區塊鏈軟件是一種多實例運行的系統，只保障了單元測試、集成測試的結果是遠不足夠保障系統最終是可用、結果是可信的，而區塊鏈又是一個用計算機軟件解決「信任」的工具，軟件首先必須是可信的，產生的數據才能讓人信任，所以溪塔團隊對測試工做投入大量的精力來保障軟件的質量。

溪塔團隊作的系統測試是一種端對端級別的、在仿真環境中軟件運行結果的黑盒測試，爲了提升測試工做效率，咱們使用了 CI 流水線來管理多種測試策略。

測試流水線

什麼是 CI/CD 流水線(Pipeline)？

以下圖所示，Jenkins 是溪塔團隊使用的 CI 工具之一，一條 CI/CD Pipeline 像是一節節的管道，代碼提交後會觸發 CI 的運行策略，執行自動化的構建、測試從而實現持續集成或持續部署流程，不一樣管道環節有各自的輸入、輸出，任何一個環節出問題都阻塞影響到整個管道的工做。

進行 CI/CD 流水線設置以前，先思考 3 個問題：

• 如何設計一條合理的流水線？

• 如何設計測試流水線？
• 爲何要設置多條流水線？

流水線設計關鍵要素有 2 點：

設計合適的Workflow：工做流程，如：stage 1 -> stage 2 -> stage 3
設計Workflow 中的 Stage Job：階段工做，如：unit-test, build, integration-test, code-audit, staging-deploy, production-deploy

每一個 Stage Job 也有 5 個設計關鍵要素：

Up/Down stream：上下游的Stage Job
Trigger: 觸發條件
Input/Output：輸入參數；輸出構件產物、輸出參數
Steps：執行步驟
Notification：結果通知；最後的 stage 都要有明確的通知對象

衆所周知作軟件開發須要有 PRD（功能需求文檔），一樣的流水線設置也須要有設計文檔。在設置具體的 CI/CD 流水線前，要作下流水線設計，以下圖是溪塔團隊其中 2 條流水線的設計文檔：

設計好各類流水線的做用、執行策略和運行步驟細節後，就能夠在 CI 工具上進行相應的設置，不要一邊想一邊改 CI 配置，特別是對於複雜的流水線應該設計好再作設置，這樣一來流水線本身也有了文檔留存，方便其餘運維同事協做，開發和測試也能清楚工做流程。

以下圖，是溪塔團隊設置的發版測試流水線：

發版測試流水線分爲 4 個階段：

構建測試對象：獲取軟件代碼，自動編譯生成不一樣算法版本的二進制文件bin
生成測試運行環節：把 bin 文件放入可運行的環境，構建 Docker Image
運行測試用例：對不一樣 bin 版本運行自動化測試用例；並行執行節省時間
生成測試報告：自動彙總各個版本的測試結果，自動生成一份包含測試對象、測試環境、測試結果的報告；並自動把構建產物存檔，方便對外發布

多種流水線策略

發版流水線無疑是溪塔團隊平常開發中最重要的一種流水線，爲了能讓開發人員儘早發現代碼質量問題，團隊還設置各類策略的測試流水線，例如用於保障開發主分支的系統測試流水線、用於保障測試代碼質量的冒煙、回顧測試流水線；用於保障軟件性能的性能測試流水線等。

系統測試流水線：
當開發人員在開發的 develop 分支有合併時執行全量測試用例集的迴歸測試，用於保障開發主分支的代碼質量。

冒煙測試流水線：
用於作測試用例的增量，用於保障測試代碼的代碼質量；當測試人員提交測試代碼的 feature 分支時執行；只運行 P1 級別的測試用例集，執行速度快，加快代碼審查、合併流程；複用由發版流水線生成的測試對象。

迴歸測試流水線：
用於保障測試代碼的代碼質量；當測試人員合併測試代碼的 develop 分支時執行；運行全量的測試用例集，執行速度慢，但避免引入有破壞性的代碼；一樣是複用由發版流水線生成的測試對象。

其餘測試流水線

性能測試流水線：
除了保障軟件的可用性，溪塔團隊很是關注軟件的運行效率，所以團隊設置了性能測試流水線。性能測試關注的結果是一些性能指標，如反映服務處理能力的 TPS、延遲和響應時間等。但性能測試的運行代價很高，須要獨佔主機資源並長時間運行。所以溪塔團隊設置成天天晚上凌晨 2 點半自動運行性能測試流水線，運行完畢會生成圖形化的報告發送郵件通知開發團隊。這樣開發團隊天天都能瞭解到主分支的性能變化狀況，當出現有重大性能變化時能夠及早進行優化修復，而不是等到發版測試階段才知道結果。

穩定性測試流水線：
溪塔團隊還關注軟件的穩定性，軟件的穩定性是指在服務有大量請求壓力時各類關鍵功能還能正常工做。所以溪塔團隊設置了穩定性測試流水線，在發版階段執行，能夠按須要選擇壓測的參數。

可用性測試流水線：
開發人員作了一些重大改動，在合併到主分支前，想了解是否有其餘反作用，所以運維提供了可用性測試流水線，開發本身選擇須要測試的分支執行便可得到該分支迴歸測試的結果。

性能改進測試流水線：
開發人員作了一些性能相關的改動，想了解總體上的性能變化，所以運維提供了性能改進測試流水線，開發本身選擇須要測試的分支執行便可得到該分支迴歸測試的結果。
在 DevOps 模式的協做重點

在 DevOps 模式下開發、測試、運維人員的協做重點爲：

運維的工做目標是使用自動化運術爲開發、測試提供便利流程、工具，減小重複工做
測試的工做目標是使用自動化運術提升測試效率、保障開發成果質量
開發享受自動化的便利，專心作開發，提升軟件質量

沒有自動化則沒有效率提高和質量持續保障，而自動化工具的維護固然也是有代價的，這個正就是實踐 DevOps 的團隊真正要作的工做。

實戰經驗分享

如何優化流水線和測試框架，如下是咱們實踐的一些技巧和收穫：

流水線優化技巧

• 流水線互相制約保障質量

系統測試流水線保障開發代碼質量
迴歸測試流水線保障測試代碼質量

• 配合 GitHub Flow 約定自動化觸發規則

feature 分支跑冒煙，冒煙過了合併到 develop
合併 develop 跑回歸，迴歸過了合併到 master

• 重用測試對象

發版測試構建測試對象
冒煙、迴歸使用已構建的測試對象
測試對象放入Docker Image 作版本管理，本地測試和CI上使用相同測試對象
存檔構建工件

• 合併測試報告
• 測試環境使用 Docker Container 隔離
• 每條測試用例隔離運行

測試框架優化技巧

• 使用環境變量及 Docker Image Tag 獲取測試對象
• 使用 Docker Image 得到統一的測試環境
• 出錯自動重試用例
• 測試用例並行執行
• 管理輸出日誌
• 輸出直觀的測試報告

什麼樣的測試報告纔是好的報告？

測試工做的最終呈現結果就是測試報告，那什麼樣的測試報告纔是好的報告？溪塔團隊認爲一份清晰準確的測試報告總結內容應該包含：

1. 測試對象

   1. 軟件名稱
   2. 軟件版本
   3. 源碼地址
   4. 源碼commit id
   5. bin文件輸出的版本信息

2. 測試環境

   1. 測試代碼的commit id
3. 測試用例
4. 測試結果

而一個好的測試框架應該能幫助測試人員自動生成這樣一份測試報告，提升測試人員的工做效率和準確性。

如下就是溪塔團隊使用的測試框架（使用 TestNG 做爲基礎框架）獲得的報告：

溪塔團隊對測試框架持續改良，使得自動生成測試報告中能輸出咱們關注的測試對象版本、測試環境、測試代碼版本等信息，收到測試報告通知時，每一個人都在經過報告能夠清晰並準確知道測試的是什麼、是什麼結果、怎麼測試的。

溪塔團隊認爲企業協做的高效祕訣之一是：Don't ask, look by your self! （不用問，本身看）能夠主動感知的信息纔有效率，經過詢問才能得知是低效的工做方式。

以上即是溪塔團隊對區塊鏈軟件的工程質量控制的一些經驗分享，請注意，每一個企業都有各自的優點、短板或歷史包袱，經驗不能複製只能參考，適合本身的纔是最好的，謝謝。​