基於Jenkins的開發測試全流程持續集成實踐

今年一直在公司實踐CI，本文將近半年來的一些實踐總結一下，可能不太完善或優美，但的確初步解決了我目前所在項目組的一些痛點。固然這僅是一家之言也不夠完整，後續還會深刻實踐和引入Kubernetes進行容器編排，以及經過阿里雲K8S服務進行高效的雲上託管，但願對各位童鞋有一點用。

1、持續集成全流程介紹

　　今年一直在開發我司的一個核心業務系統，一個還未上線的產品開發階段，其中後端採用ASP.NET Core + 一系列開源組件開發微服務而且部署在Linux Docker中，前端採用React + Flutter開發Web和App。採用了Jenkins做爲CI工具，集成了一堆插件Plugin實現了初步的持續集成全流程。

　　下圖就是我最近整理的一個目前的持續集成全流程圖：

　　

　　能夠看出，在開發測試環境我有3個環境：

　　（1）DEV環境：用於dev分支的先後端開發聯調，有單獨的數據庫

　　（2）MT環境：用於release分支（現階段我直接用的master分支，產品上線後不可取）的測試進行集成測試，有單獨的數據庫

　　（3）DEV-AT環境：用於dev分支的自動化接口測試環境，即專門拿來跑自動化接口腳本的環境，有單獨的數據庫

　　針對CI服務器，在開發測試環境我有個2個節點：

　　（1）master節點：用於持續集成和部署等通常性構建任務

　　（2）slave-at節點：專門用於跑自動化接口測試腳本構建任務

　　推薦在Jenkins中爲不一樣類型的構建任務設置不一樣的label，這樣能夠綁定不一樣類型的構建任務至不一樣的Node上執行，從而減小高峯時期master節點的負載壓力。

2、ASP.NET Core CI流程部分

　　個人後端微服務是基於ASP.NET Core開發的，採用了容器化部署至Linux服務器，以前有過一篇詳細的文章介紹過《基於Jenkins Pipeline的ASP.NET Core持續集成實踐》。

　　

　　在Jenkins中提供了Pipeline方便地進行構建流水線，在個人實踐中主要是經過開發人員的每一次Check-In到git，觸發一個Webhook到Jenkins中從而使持續集成構建任務開始執行：

　　從圖中能夠看出，其經歷了中臺微服務的編譯和單元測試 及 BFF（Backend for Frontend）服務的編譯和單元測試來保障代碼質量，固然前提是有足夠的單元測試做爲保護層，這也須要開發人員花時間爲每一個服務接口（或者高價值的部分）寫單元測試！

　　若是構建任務中有一個Stage失敗了，那麼此構建任務則認爲失敗，會給開發團隊和Leader發送郵件告警：

　　此外，咱們還使用了一個用於大屏顯示構建狀態的插件—Build Monitor，在咱們工做區後方的電視屏上會顯示各個構建任務的實時狀態，若是有任務失敗了會變爲紅色：

　　而且，Build Monitor還會將推動不可靠代碼的提交者名字（git帳號名字）顯示在屏幕中的構建任務裏邊，方便你們查看誰的鍋：

3、ASP.NET Core CD流程部分

　　通過CI部分，就能夠初步認爲提交的代碼已經通過了初步的驗證，這時會進入部署部分的構建任務，在個人流程裏會有開發聯調環境的部署及接口自動化環境的部署。固然，除了API的部署也有Web的部署，咱們能夠將其寫到一個統一的Pipeline中也能夠分開兩個Pipeline來寫。

　　下圖是個人一個API的部署構建任務，其中會經歷中臺微服務的部署及BFF服務的部署，固然也能夠部署至多個服務器：

　　這裏說一下，因爲我目前並無採用任何的容器編排工具，因此這裏的發佈就只是單純的將release文件覆蓋以後而後將docker暫停和重啓。這樣作的缺點是沒有充分利用鏡像的優勢，沒法實現版本的有效管理（好比回退）。

4、RobotFramework AT流程部分

　　對於一個產品來講，質量很重要，而保證質量的輔助手段就是充分的迴歸測試。自動化接口測試使得迴歸測試成爲能夠頻繁觸發，也就能及時發現提交的代碼對已有接口功能的影響。咱們的AT是根據重要的業務場景來寫的，並且咱們也以爲AT應該寫在那些主要業務流程的接口上面，才能顯示出它的價值，並且AT的編寫也是不小的工做量。

　　咱們使用的是RobotFramework，開發語言是Python。在開發人員提交代碼併發布到開發聯調環境時，便會自動觸發AT環境的部署，部署無誤後就會觸發AT任務的執行，AT執行無誤後纔會自動Merge dev分支的代碼至穩定的測試分支，以後測試再選擇是否發佈最新的更改至測試環境進行驗證bug fix。

　　下圖是基於RF的AT構建任務的執行結果：

　　下圖是該任務的具體的輸出信息，咱們能夠看到每一個用例的執行狀況：

　　因爲我目前對這塊瞭解很少，後續有機會了解多點後能夠介紹一點咱們在AT方面的實踐和規範。

5、小結

　　本文介紹了我目前團隊所在使用的持續集成全流程及一些重要插件的使用，雖然還很不完善，但初步解決了我所在團隊在集成和發佈上的一些痛點。隨着後續對K8S的學習的深刻，我會逐步引入K8S進行微服務的容器編排以及持續集成的K8S化改造，但願到時再進行分享。

 

做者：周旭龍

出處：https://edisonchou.cnblogs.com

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文連接。