今年上半年一直在公司實踐CI，本文將上半年來的一些實踐總結(jié)一下，可能不太完善或優(yōu)美，但的確初步解決了我目前所在項目組的一些痛點。當(dāng)然這僅是一家之言也不夠完整，后續(xù)下半年還會深入實踐和引入Kubernetes進(jìn)行容器編排，以及通過阿里云K8S服務(wù)進(jìn)行高效的云上托管，希望對各位童鞋有一點用。

01

—

我的持續(xù)集成全流程

????????今年一直在開發(fā)我司的一個核心業(yè)務(wù)系統(tǒng)，一個還未上線的產(chǎn)品開發(fā)階段，其中后端采用ASP.NET Core + 一系列開源組件開發(fā)微服務(wù)并且部署在Linux Docker中，前端采用React + Flutter開發(fā)Web和App。采用了Jenkins作為CI工具，繼承了一堆插件Plugin實現(xiàn)了初步的持續(xù)集成全流程。

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

　　可以看出，在開發(fā)測試環(huán)境我有3個環(huán)境：

　　（1）DEV環(huán)境：用于dev分支的前后端開發(fā)聯(lián)調(diào)，有單獨的數(shù)據(jù)庫

　　（2）MT環(huán)境：用于release分支（現(xiàn)階段我直接用的master分支，產(chǎn)品上線后不可取）的測試進(jìn)行集成測試，有單獨的數(shù)據(jù)庫

　　（3）DEV-AT環(huán)境：用于dev分支的自動化接口測試環(huán)境，即專門拿來跑自動化接口腳本的環(huán)境，有單獨的數(shù)據(jù)庫

　　針對CI服務(wù)器，在開發(fā)測試環(huán)境我有個2個節(jié)點：

　　（1）master節(jié)點：用于持續(xù)集成和部署等一般性構(gòu)建任務(wù)

　　（2）slave-at節(jié)點：專門用于跑自動化接口測試腳本構(gòu)建任務(wù)

　　推薦在Jenkins中為不同類型的構(gòu)建任務(wù)設(shè)置不同的label，這樣可以綁定不同類型的構(gòu)建任務(wù)至不同的Node上執(zhí)行，從而減少高峰時期master節(jié)點的負(fù)載壓力。

02

—

ASP.NET Core CI部分

????????我的后端微服務(wù)是基于ASP.NET Core開發(fā)的，采用了容器化部署至Linux服務(wù)器，之前有過一篇詳細(xì)的文章介紹過《基于Jenkins Pipeline的ASP.NET Core持續(xù)集成實踐》。

　　

　　在Jenkins中提供了Pipeline方便地進(jìn)行構(gòu)建流水線，在我的實踐中主要是通過開發(fā)人員的每一次Check-In到git，觸發(fā)一個Webhook到Jenkins中從而使持續(xù)集成構(gòu)建任務(wù)開始執(zhí)行：

　　從圖中可以看出，其經(jīng)歷了中臺微服務(wù)的編譯和單元測試 及 BFF（Backend for Frontend）服務(wù)的編譯和單元測試來保障代碼質(zhì)量，當(dāng)然前提是有足夠的單元測試作為保護(hù)層，這也需要開發(fā)人員花時間為每個服務(wù)接口（或者高價值的部分）寫單元測試！

　　如果構(gòu)建任務(wù)中有一個Stage失敗了，那么此構(gòu)建任務(wù)則認(rèn)為失敗，會給開發(fā)團(tuán)隊和Leader發(fā)送郵件告警：

　　此外，我們還使用了一個用于大屏顯示構(gòu)建狀態(tài)的插件—Build Monitor，在我們工作區(qū)后方的電視屏上會顯示各個構(gòu)建任務(wù)的實時狀態(tài)，如果有任務(wù)失敗了會變?yōu)榧t色：

　　并且，Build Monitor還會將推進(jìn)不可靠代碼的提交者名字（git賬號名字）顯示在屏幕中的構(gòu)建任務(wù)里邊，方便大家查看誰的鍋：

03

—

ASP.NET Core CD部分

????????經(jīng)過CI部分，就可以初步認(rèn)為提交的代碼已經(jīng)經(jīng)過了初步的驗證，這時會進(jìn)入部署部分的構(gòu)建任務(wù)，在我的流程里會有開發(fā)聯(lián)調(diào)環(huán)境的部署及接口自動化環(huán)境的部署。當(dāng)然，除了API的部署也有Web的部署，我們可以將其寫到一個統(tǒng)一的Pipeline中也可以分開兩個Pipeline來寫。

　　下圖是我的一個API的部署構(gòu)建任務(wù)，其中會經(jīng)歷中臺微服務(wù)的部署及BFF服務(wù)的部署，當(dāng)然也可以部署至多個服務(wù)器：

　　這里說一下，由于我目前并沒有采用任何的容器編排工具，所以這里的發(fā)布就只是單純的將release文件覆蓋之后然后將docker暫停和重啟。這樣做的缺點是沒有充分利用鏡像的優(yōu)點，無法實現(xiàn)版本的有效管理（比如回退）。

04

—

RobotFramework AT部分

????????對于一個產(chǎn)品來說，質(zhì)量很重要，而保證質(zhì)量的輔助手段就是充分的回歸測試。自動化接口測試使得回歸測試成為可以頻繁觸發(fā)，也就能及時發(fā)現(xiàn)提交的代碼對已有接口功能的影響。我們的AT是根據(jù)重要的業(yè)務(wù)場景來寫的，而且我們也覺得AT應(yīng)該寫在那些主要業(yè)務(wù)流程的接口上面，才能顯示出它的價值，而且AT的編寫也是不小的工作量。

　　我們使用的是RobotFramework，開發(fā)語言是Python。在開發(fā)人員提交代碼并發(fā)布到開發(fā)聯(lián)調(diào)環(huán)境時，便會自動觸發(fā)AT環(huán)境的部署，部署無誤后就會觸發(fā)AT任務(wù)的執(zhí)行，AT執(zhí)行無誤后才會自動Merge dev分支的代碼至穩(wěn)定的測試分支，之后測試再選擇是否發(fā)布最新的更改至測試環(huán)境進(jìn)行驗證bug fix。

　　下圖是基于RF的AT構(gòu)建任務(wù)的執(zhí)行結(jié)果：

　　下圖是該任務(wù)的具體的輸出信息，我們可以看到每個用例的執(zhí)行情況：

　　由于我目前對這塊了解不多，后續(xù)有機會了解多點后可以介紹一點我們在AT方面的實踐和規(guī)范。

05

—

小結(jié)

????????本文介紹了我目前團(tuán)隊所在使用的持續(xù)集成全流程及一些重要插件的使用，雖然還很不完善，但初步解決了我所在團(tuán)隊在集成和發(fā)布上的一些痛點。隨著后續(xù)對K8S的學(xué)習(xí)的深入，我會逐步引入K8S進(jìn)行微服務(wù)的容器編排以及持續(xù)集成的K8S化改造，希望到時再進(jìn)行分享。

你點的每個贊，我都認(rèn)真當(dāng)成了喜歡

總結(jié)

以上是生活随笔為你收集整理的基于Jenkins的开发测试全流程持续集成实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。