一種基于DevOps 的自動化測試及CI/CD流程的設計與實現

卞中杰

（上海甚解信息技術有限公司，上海 200235）

隨著交通運輸行業的飛速發展，道路貨物運輸量逐年上升，為了幫助運輸企業降低運輸過程中的事故率，出現了由第三方企業開展的針對道路貨物運輸的風險控制業務；然而由于風控軟件的特殊性，軟件發布需要做全套的單元測試、集成測試、系統測試、回歸測試，傳統的人工測試無法在有限時間和資源內確保測試的全面性和準確性，同時伴隨長鏈路的業務流程越來越多，人工測試在數據準備和業務驗證方面效率低下[1]。因此，自動化測試是一種能夠保證測試正確執行的可行方法，只有保證自動化測試的正確性，才能實現系統后續的自動部署和快速迭代。

1 基于容器的DevOps

持續集成和持續部署（CI/CD）作為關鍵內容，包含多種實現方式，比如通過Jenkins 和Ansible 實現軟件的自動化編譯和部署[1]；通過GitLab 的Pipeline 功能和Terraform 結合實現基礎設施的自動化創建和部署[3]；基于容器的DevOps 實施方案和實踐[4]。

容器（指Docker、Podman 等容器技術）的出現使得DevOps 更容易被實現，DevOps 往往需要多種軟件協同實現，由于容器天生具備隔離性，可使得不同版本的軟件互不影響地在同一宿主機上運行，相比虛擬機而言，啟動速度更快、資源占用更小。此外，容器的打包方式可實現開發環境和生產環境的軟件版本、依賴項等高度統一，打包完成的鏡像易于分發。

Kubernetes 的出現改變了容器編排方式，能從更高維度管理容器的生命周期，將服務器作為一整個集群統一管理，使得容器可靈活地在集群中被啟動和調度。Kubernetes 可以幫助基于容器分發的軟件獲得高可用、可擴展、可漂移的能力，并具備細粒度的容器管理能力。本文探討的CI/CD 以及自動化測試的實現均基于Kubernetes，充分利用容器的能力和特性，實現從開發到部署的自動化。

2 DevOps 中CI/CD 總體流程設計

對于CI/CD 流程而言，觸發整個流程開始的事件通常是開發人員提交代碼或者代碼被合并到測試或生產分支。一旦代碼提交，如果GitLab 發現代碼倉庫根目錄中存在.gitlabci.yml 文件，GitLab 會通知獨立部署的GitLab Runner 組件，依次運行該文件內定義的流程任務，CI/CD 的整體流程見圖1。

圖1 CI/CD 整體流程設計

CI/CD 流程腳本都寫在.gitlab-ci.yml 文件中，在文件的開頭往往會定義一些變量為后續步驟服務，同時該文件也定義了運行每個步驟默認使用的容器（文本使用docker:stable 鏡像）以及整個流程的3 個流程節點（又稱Stage）：test、build 和deploy。

在流程的第一步中，編譯測試會被首先執行，可確保新的代碼能夠被編譯通過。在這之后，會根據不同項目類型執行單元測試、集成測試、系統測試等，在所有測試通過以后，到下一步鏡像打包階段，如果測試失敗，則流程終止。

鏡像打包階段軟件需要被打包成Docker 鏡像，由于每一步流程都是在一個容器中啟動，此方式被成為DinD（Docker in Docker）。運行DinD 需要priveleged 權限，出于安全考慮，選用kaniko 鏡像來實現鏡像打包且無需額外權限即可使用。

鏡像打包并上傳到鏡像倉庫以后，在測試環境或預發布環境中進行部署，而Kubernetes 中，部署方式通常有兩種：使用原生部署配置文件或Helm 工具。Helm 通過向模板注入不同的配置和參數，來生成不同的部署文件，其靈活性優于Kubernetes 原生部署文件；并且Helm 具備部署的版本管理功能，便于版本切換，故使用Helm 進行部署，配置如下：

Helm 從app/test 下載模板文件，并且結合代碼倉庫下. /deploy / test / values . yaml 的屬性更改，會在Kubernetes的test 命名空間（namespace）下，部署一個名為test-app 的應用。至此，測試、預發布程序已經完成部署。對于測試環境則流程結束；而對于正式環境，可在預發布環境做最后的核對和測試，當測試完成后，繼續后續的發布到生產環境的流程。

3 自動化測試設計

在整個自動化部署流程中，測試是最為關鍵的一環。測試方法和用例的設計以及用例是否能被正確執行，決定了能否自動執行后續的發布流程。在測試執行過程中，面臨著兩類問題：（1）多人提交代碼導致測試并發執行，引起數據沖突使得測試失敗；（2）由于前一次的測試用例修改了測試數據，再次執行測試導致測試失敗。下文將介紹通過容器技術和測試管線設計來解決以上兩個問題。

3.1 總體測試執行流程

代碼在提交、合并或進入發布通道時均可設置不同的測試環節。當軟件通過了所有的測試，流程自動進入到后續的發布階段，而測試中有某一項未通過，則發布流程終止。如果流程涉及合并請求，可以駁回并自動關閉本次合并請求。自動化的測試流程分為4 個階段：創建和啟動測試環境；導入和初始化測試數據；執行測試；銷毀測試環境。當環境和數據準備完成之后，執行所有測試并判斷結果；當測試完成以后，銷毀測試環境，執行后續流程。

3.2 測試數據準備

高質量、可復用的測試數據除了能夠支撐后臺軟件測試，同樣要能夠為前端測試提供服務。單一存儲的測試數據會被測試樣例在運行期間刪除、修改，導致測試無法重現，并且在多人并發測試場景下，如果某一方修改了測試數據，會導致其他依賴該測試數據的測試無法進行。因此，測試數據必須被獨立抽取出來，在測試流程開始時完整地恢復到測試環境中，形成可復用的測試數據。在該項目中，測試數據按照生產環境要求和格式預先被設計好并存放在MySql 中，使用MySql 的dump 命令將測試數據全部抽取形成文件，并存放到源代碼管理系統中。例如對于MySql5.7 版本，把App 數據庫中的users 表數據全部導出為users.sql 文件，可使用如下命令：mysql _user USER _password PASSWORD _host HOST dump _database App _tables users > users.sql，其中USER、PASSWORD、HOST 分別需要替換為真實的數據庫用戶名、密碼和數據庫服務器地址。要把該導出文件恢復到測試環境數據庫中，則對應的恢復命令是：mysql _user USER_password PASSWORD _host HOST < users.sql

在后續的測試指令執行完成后，本次Stage 內啟動的所有容器及其中數據都會被刪除，不會造成數據和環境殘留。

3.3 測試環境啟動和執行

由于整個CI/CD 流程均在基于容器的環境中進行，因此可以使用容器在測試環節中啟動測試該業務所需的所有配套設施。

3.3.1 后臺測試環境配置和啟動流程

以測試一個微服務為例，需要啟動的依賴設施有MySQL 數據庫和Flask 服務器。在Pipeline 中對應的Stage配置如下：

這段配置文件首先修改了默認運行環境為：${TEST_ENV_IMAGE}，這是一個變量，指向開頭定義的對應的鏡像名，該鏡像是一個安裝了flask 和pytest 的帶有python3.7 運行時環境的容器。services 語句定義了除運行主容器以外，在這個Stage 中還需要運行一個MySql5.7 的容器，該容器和主容器之間可進行網絡通信。接下來before_script 屬性的值描述了容器啟動后先運行的腳本，這里是向MySql 導入測試數據的合適時機。再接下來的script屬性定義了環境準備完畢后運行測試的指令，在這里運行的是pytest 測試指令，可以根據實際需要定義若干條測試指令。因此，一個完整的測試環境在容器中得以運行，該微服務所依賴的所有外部服務同時也以容器方式啟動，在所有測試語句運行完畢以后，這些容器都會被銷毀，不會留下數據和配置殘留。

3.3.2 前端測試環境配置和啟動流程

前端軟件的測試會和后臺服務軟件測試存在差異。除了小游戲、工具型軟件等無需和后臺交互的程序外，與業務結合的前端軟件絕大部分依賴于后臺服務才能運行，因此在測試前端的過程中，后臺服務環境也要一并啟動。單元測試由于不依賴于后臺，只需啟動一個帶有headless 瀏覽器的容器（本文使用cypress/browsers:node16.13.0-chrome95-ff94 鏡像），在該容器內可以運行前端的單元測試代碼；但是e2e 測試由于需要最大程度地模擬用戶真實使用場景，且為了確保測試可靠性，整個流程需要真實后臺數據參與，在e2e-test該環節中的services 中定義了需要額外啟動2 個容器，分別是MySql 和后臺微服務。通過啟動后臺微服務確保前端測試匹配對應版本后臺邏輯，測試過程中可與真實測試數據進行交互，而MySql 則是運行后臺微服務所需要的依賴項。

4 自動化集成和部署設計

在代碼通過測試后，自動化流程來到集成和部署階段。CI/CD 的實現因不同軟件打包方式、系統運行環境和部署方式而不同，由于本系統全部運行在基于容器的Kubernetes之上，因此軟件的分發需要把軟件打包成Docker 鏡像，并在Kubernetes 上進行部署。在.gitlab-ci.yml 中，可以分成2 個Stage 來進行：（1）在build 這個stage 中，使用Docker-in-Docker 的方式編譯打包微服務的Docker 鏡像，并上傳到一個私有的鏡像倉庫。而在build-test-mysql 中，基于MySql 鏡像打包了一個帶有測試數據的鏡像，可作為一個帶有初始數據的數據庫鏡像靈活地運用在所有需要測試數據的環節中。（2）在deploy 這個stage 中，使用kubernetes 原生工具kubectl 通過配置文件部署應用，除了前文提到的Helm，如果不需要每次提交都對部署文件進行改動，而只是進行簡單的版本更新操作，則此方式更為便捷。

從圖2 可以看出，從代碼提交到測試，再從軟件打包到部署成功，整個流程并無人工參與，只耗時3 分32 秒（當中還包含每個Stage 的啟動耗時）。如果項目使用敏捷開發模式，每天均可發布新的版本，這種方式能極大地提高軟件測試和部署效率且避免人工操作錯誤，從而提高流程可靠性。

圖2 GitLab 中后臺服務CI/CD 效果圖

5 結論

本文通過實現DevOps 以及使用Kubernetes 作為生產環境，軟件的測試和發布效率都相比傳統方式有了大幅度的提升。在本文中基于容器和自動化腳本的測試環境可以方便地啟動和生產環境相同的組件，但這種測試環境追求的是最小化的類生產環境，因此該測試方法適用于測試業務的正確性。由于受限于測試環境所啟動的單機資源限制，在自動化Pipeline 中啟動的測試環境一般達不到和生產環境等同的資源和性能，如果生產環境是分布式、大數據系統，則啟動相同形式的最小測試環境也會占用相當大的資源，會限制可同時進行的測試數量。除此以外，測試環境的特性決定了并不適合進行一些極端的壓力測試，因為單機資源存在瓶頸且本地回環網絡和真實服務器之間的物理網絡吞吐能力都存在很大不同，這就造成性能測試結果無法代表軟件在真實的生產環境中的性能表現，對于如何解決以上這些問題，仍需進行更進一步的研究與實踐。