基于 jenkins 和 docker 的個(gè)推持續(xù)集成平臺(tái)

binaryTree 發(fā)布于2019-06-28 15:01 / 2588人閱讀

摘要：基于的特性，以及持續(xù)集成的需求，個(gè)推采用為持續(xù)集成搭建了一整套測(cè)試系統(tǒng)。個(gè)推持續(xù)集成流程以一個(gè)假設(shè)名為模塊為例，以開(kāi)發(fā)人員的視角闡述了持續(xù)集成的邏輯。

軟件開(kāi)發(fā)過(guò)程中，開(kāi)發(fā)成員經(jīng)常需要把自己工作集成到項(xiàng)目中,通常每個(gè)成員每天至少集成一次。如果項(xiàng)目較小，對(duì)外部的依賴較小，那么軟件集成可能不會(huì)是什么問(wèn)題。但是目前很多軟件項(xiàng)目特別是互聯(lián)網(wǎng)項(xiàng)目面臨著需求不明確，系統(tǒng)架構(gòu)復(fù)雜，任務(wù)分配混亂等一系列問(wèn)題，從而給持續(xù)集成帶來(lái)許多麻煩。也給整個(gè)項(xiàng)目帶來(lái)不必要的風(fēng)險(xiǎn)。因此一個(gè)有效的持續(xù)集成系統(tǒng)越來(lái)越重要。

個(gè)推平臺(tái)是一個(gè)極其復(fù)雜的分布式系統(tǒng)，整個(gè)系統(tǒng)包含了 RPC 調(diào)用，高速緩存，集群同步等各種復(fù)雜的場(chǎng)景。整個(gè)團(tuán)隊(duì)只有二十來(lái)個(gè)人卻維護(hù)了近百個(gè)模塊的開(kāi)發(fā)和測(cè)試工作，如果沒(méi)有一套有效的機(jī)制，很難想象如何完成這些任務(wù)。持續(xù)集成在其中扮演了非常重要的角色，借助于 Git、Docker、Jenkins 以及 Nexus 等工具，我們搭建了自己的持續(xù)集成環(huán)境，并一步一步的摸索出了自己的最佳實(shí)踐，這篇文章將會(huì)和大家一起分享我們是如何利用這些技術(shù)提高團(tuán)隊(duì)的生產(chǎn)力的。

個(gè)推持續(xù)集成系統(tǒng)的組成 使用git作為版本控制庫(kù)

相比于同類項(xiàng)目版本系統(tǒng)，git有一項(xiàng)非常顯著的優(yōu)勢(shì)，就是版本分支(branch)的合并(merge)十分方便。

使用docker搭建測(cè)試環(huán)境

作為一種新型的虛擬化方式，相對(duì)于傳統(tǒng)的虛擬化方式有著眾多的優(yōu)勢(shì)。例如，docker虛擬容器的啟動(dòng)可以在秒級(jí)實(shí)現(xiàn)，并且對(duì)系統(tǒng)資源的利用率很高。另外，docker的管理，遷移和擴(kuò)展也更輕松有效。

使用jenkins作為持續(xù)集成服務(wù)器

Jenkins為開(kāi)發(fā)人員提供了非常有效的持續(xù)集管理。其強(qiáng)大的插件系統(tǒng)和明確的構(gòu)建邏輯，使得構(gòu)建流程的創(chuàng)建非常簡(jiǎn)便。

Docker在持續(xù)集成系統(tǒng)中的作用

測(cè)試作為軟件項(xiàng)目重要的一環(huán)，一般都需要開(kāi)發(fā)團(tuán)隊(duì)搭建一套獨(dú)立的測(cè)試系統(tǒng)。但作為持續(xù)集成的一個(gè)環(huán)節(jié)，此測(cè)試系統(tǒng)又異于一般的測(cè)試系統(tǒng)。主要原因?yàn)椋掷m(xù)集成測(cè)試系統(tǒng)主要用來(lái)做回歸測(cè)試，而且需要支持快速大量的代碼升級(jí)。基于docker的特性，以及持續(xù)集成的需求，個(gè)推采用docker為持續(xù)集成搭建了一整套測(cè)試系統(tǒng)。

鏡像準(zhǔn)備：docker 的運(yùn)行基于鏡像文件，而每個(gè)項(xiàng)目所需的鏡像文件又不同。因此需要獨(dú)立分析每個(gè)項(xiàng)目的需求以及未來(lái)擴(kuò)展需要，創(chuàng)建出不同版本的鏡像文件。目前，個(gè)推主要有4大類鏡像，分別支持前端，后端，工具類，以及其他項(xiàng)目。以前端為例，個(gè)推采用了前后端分離的開(kāi)發(fā)模式，因此此鏡像主要用來(lái)支持web 前端的服務(wù)運(yùn)行。

素材準(zhǔn)備：為了能在docker里運(yùn)行所需要的服務(wù)，需要docker實(shí)例中安裝相應(yīng)的包。一般有兩種方法，一種為將相應(yīng)的素材與鏡像文件相綁定，另一種以docker 卷的形式動(dòng)態(tài)映射到docker實(shí)例。兩種方式有其優(yōu)劣，第一種方式使得每次docker 容器的啟動(dòng)非常迅捷，而第二種方式則更為靈活。這個(gè)需要根據(jù)不同的需求選擇合適的方式。

下圖為docker 在整個(gè)持續(xù)集成系統(tǒng)中的作用。Jenkins 作為主服務(wù)器將代碼和docker 統(tǒng)一的管理起來(lái)。

個(gè)推持續(xù)集成流程

以一個(gè)假設(shè)名為user模塊為例，以開(kāi)發(fā)人員的視角闡述了持續(xù)集成的邏輯。從下圖中可以看出，我們系統(tǒng)的git分支包括dev，master兩個(gè)分支：

dev:開(kāi)發(fā)分支，開(kāi)發(fā)人員維護(hù)，開(kāi)發(fā)人員將最新代碼提交到這個(gè)分支，Jekins監(jiān)視這個(gè)分支，任何代碼改變都會(huì)觸發(fā)自動(dòng)化測(cè)試

master:發(fā)布分支，這個(gè)分支上的版本是自動(dòng)化測(cè)試通過(guò)后的版本，且自動(dòng)化打包監(jiān)控這個(gè)分支

圖中的每個(gè)長(zhǎng)方形代表一個(gè)Jenkins Job。下面將對(duì)每個(gè)Job進(jìn)行說(shuō)明：

user: 監(jiān)控user代碼庫(kù)的dev分支，當(dāng)每次有新的代碼提交時(shí)，就會(huì)自動(dòng)觸發(fā)構(gòu)建任務(wù)。編譯代碼，同時(shí)生成code style,測(cè)試覆蓋率等關(guān)于代碼質(zhì)量的報(bào)表。成功后將觸發(fā)user-docker任務(wù)。

user-docker: 打包user工程，重啟user的docker實(shí)例以便于使用全新的user包。成功后將觸發(fā)testcase任務(wù)

testcase: 驗(yàn)收測(cè)試，檢測(cè)改變是否滿足業(yè)務(wù)需求所定義的驗(yàn)收條件。成功后將觸發(fā)marge任務(wù)

merge：將user的dev分支merge到master分支

user-pkg: 監(jiān)控user代碼庫(kù)的master分支，當(dāng)有代碼改變時(shí)，執(zhí)行mvn package打包操作

經(jīng)過(guò)上面的幾個(gè)步驟，從代碼提交到打包的整個(gè)過(guò)程就自動(dòng)化起來(lái)了。

總結(jié)

目前越來(lái)越多的公司開(kāi)始重視持續(xù)集成系統(tǒng)，但是缺乏定制化的系統(tǒng)真的能滿足復(fù)雜的需求嗎？當(dāng)模塊之間的聯(lián)系越來(lái)越復(fù)雜，集成的頻率越來(lái)越大，運(yùn)行環(huán)境的不斷升級(jí) 等等，缺乏定制的持續(xù)集成系統(tǒng)是否能達(dá)到預(yù)期，個(gè)推在docker 上找到了問(wèn)題的答案。雖然仍然有許多挑戰(zhàn)，但隨著技術(shù)的升級(jí)和完善，我們終會(huì)越做越好。