持續(xù)集成
開發(fā)中,我們經(jīng)常遇到一些奇怪問題,比如本地可以編譯成功的代碼但是同事們更新代碼后編譯出錯(cuò),或者在項(xiàng)目有多個(gè)Target的時(shí)候,資源文件只添加到了當(dāng)前的Target,另外一個(gè)Target這個(gè)時(shí)候是不能正常編譯的,再比如寫的工具類,被同事改了,或者自己有改動(dòng),很多地方用到了,怎么保證這個(gè)類的行為沒有發(fā)生變化而影響到項(xiàng)目中的其它模塊呢?諸如此類。
那么這些問題原因在哪,可否避免呢?當(dāng)然是可以避免的,如果代碼有新的改動(dòng),提交到版本庫(kù)中的時(shí)候,有一個(gè)人幫我們檢查必要事項(xiàng),然后做做測(cè)試不就好了,這個(gè)當(dāng)然是可以的,前提是老板同意專門招一個(gè)這樣的人。
引起各種奇怪問題的原因有很多,比如開發(fā)環(huán)境比較復(fù)雜不干凈,IDE的bug,提交前有一些必要的檢查需要做,但是開發(fā)時(shí)因?yàn)楦鞣N原因沒做,這些機(jī)械重復(fù)的事情我們可以找一個(gè)工具來幫我們完成,而且這個(gè)工具跑在一個(gè)專門的服務(wù)器上,該服務(wù)器環(huán)境相對(duì)干凈,可以運(yùn)行一些自動(dòng)化操作,而自動(dòng)編譯,代碼檢查,測(cè)試等環(huán)節(jié),那么這種東西,就是接下來講的[持續(xù)集成]。
個(gè)人理解持續(xù)集成:為解決程序代碼提交質(zhì)量低,提交內(nèi)容導(dǎo)致原有系統(tǒng)的bug,按時(shí)或按需自動(dòng)編譯版本,自動(dòng)進(jìn)行自動(dòng)化測(cè)試。
百度的定義:持續(xù)集成是一種軟件開發(fā)實(shí)踐,即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作,通常每個(gè)成員每天至少集成一次,也就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過自動(dòng)化的構(gòu)建(包括編譯,發(fā)布,自動(dòng)化測(cè)試)來驗(yàn)證,從而盡快發(fā)現(xiàn)集成錯(cuò)誤。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過程可以大大減少集成的問題,讓團(tuán)隊(duì)能夠更快的開發(fā)內(nèi)聚的軟件。
[是什么]
持續(xù)集成是一種軟件開發(fā)實(shí)踐,即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作,通過每個(gè)成員每天至少集成一次,也就意味著每天可能會(huì)發(fā)生多次集成,每次的集成都通過自動(dòng)化的構(gòu)建(包括編譯,發(fā)布,自動(dòng)化測(cè)試)來驗(yàn)證,從而盡早發(fā)現(xiàn)集成錯(cuò)誤。簡(jiǎn)單來說,就是持續(xù)的定時(shí)的在多個(gè)團(tuán)隊(duì)成員的工作中進(jìn)行集成,并且給予反饋。
持續(xù)集成需要開發(fā)人員一天多次的將代碼集成到主干,并進(jìn)行自動(dòng)化編譯、測(cè)試等操作,由于這種頻繁集成,以及集成后及時(shí)開始的編譯和測(cè)試,可以有效避免我們?cè)谔峤淮a時(shí)沒有進(jìn)行必要檢查而導(dǎo)致的錯(cuò)誤,以及一些超出預(yù)期效果的更改,從而保證代碼的質(zhì)量。
由于這種及時(shí)性,如果在一次提交后項(xiàng)目集成失敗,可以快速的在這次提交中查找問題所在,縮小了找問題的范圍,從而減少了一些debug時(shí)間。同時(shí)如果按照這種實(shí)踐,那么我們的主干代碼時(shí)刻都是正確的,這樣我們可以更頻繁的交付。
[為什么]
一般規(guī)模較小的項(xiàng)目,對(duì)外部系統(tǒng)的依賴和服務(wù)調(diào)用很小,對(duì)于軟件的集成不是問題。但是隨著軟件復(fù)雜度的增加,對(duì)集成提出了更多的要求,持續(xù)集成的好處就體現(xiàn)出來了。
1)對(duì)重復(fù)的編譯發(fā)布等操作進(jìn)行抽象,減少重復(fù)過程。
2)及早發(fā)現(xiàn)各種沖突和錯(cuò)誤,減少風(fēng)險(xiǎn)。
3)任何時(shí)間、任何地點(diǎn)生成可部署的軟件
[怎么做]
基本要求:要將這種實(shí)踐付諸實(shí)際,需要一些必要的條件,如下
1.一個(gè)自動(dòng)構(gòu)建過程,包括自動(dòng)編譯、分發(fā)、部署和測(cè)試等
2.一個(gè)代碼存儲(chǔ)庫(kù),即需要版本控制軟件來保障代碼的可維護(hù)性,同時(shí)作為構(gòu)建過程的素材庫(kù)。
3.一個(gè)持續(xù)集成服務(wù)器。
自動(dòng)化構(gòu)建成過程,可幫助我們節(jié)省大量時(shí)間,完成這個(gè)過程的自動(dòng)化后,在以后的開發(fā)過程中,我們需要做的,就是只是提交代碼到版本庫(kù)中,構(gòu)建自動(dòng)完成,基本不再需要人工干預(yù)。
代碼倉(cāng)庫(kù)作為構(gòu)建的素材庫(kù),構(gòu)建所需的代碼從代碼庫(kù)中獲得。
最好有一臺(tái)服務(wù)器單獨(dú)作為持續(xù)集成服務(wù)器,一方面保證了環(huán)境的純凈,一方面不影響開發(fā),而且持續(xù)集成服務(wù)器一般是隨時(shí)準(zhǔn)備開始構(gòu)建的,所以一般也不關(guān)機(jī)。
1[首先要有統(tǒng)一的代碼庫(kù),服務(wù)器不斷從版本控制服務(wù)器上檢查代碼狀態(tài),看代碼是否有更新。如果發(fā)現(xiàn)有代碼更新,那么就從版本控制服務(wù)器下載最新的代碼。等代碼完全更新以后,調(diào)用自動(dòng)化編譯腳本,進(jìn)行代碼編譯。然后運(yùn)行所有的自動(dòng)化測(cè)試,并且進(jìn)行代碼分析。如果其中任何一個(gè)步驟失敗,就表示build失敗,持續(xù)集成服務(wù)器會(huì)給予響應(yīng)的反饋。每次代碼提交之后,都會(huì)在持續(xù)集成服務(wù)器上觸發(fā)一個(gè)定時(shí)構(gòu)建,然后進(jìn)行編譯、部署。]
[原則]
1.開發(fā)人員必須及時(shí)向版本控制庫(kù)中提交代碼,也必須經(jīng)常性地從版本控制庫(kù)中更新代碼到本地;
2.需要有專門的集成服務(wù)器來執(zhí)行集成構(gòu)建。根據(jù)項(xiàng)目的具體實(shí)際,集成構(gòu)建可以被軟件的修改來直接觸發(fā),也可以定時(shí)啟動(dòng),如每半個(gè)小時(shí)構(gòu)建一次;
3.必須保證構(gòu)建的成功。如果構(gòu)建失敗,修復(fù)構(gòu)建過程中的錯(cuò)誤是優(yōu)先級(jí)最高的工作。一旦修復(fù),需要手動(dòng)啟動(dòng)一次構(gòu)建。
4.不更新構(gòu)建失敗的代碼
開發(fā)人員及時(shí)的提交代碼進(jìn)行構(gòu)建是符合上述實(shí)踐的,及時(shí)拉取代碼可以防止工作中的分支偏離主干分支太多。定時(shí)觸發(fā)構(gòu)建或者通過檢測(cè)代碼的修改情況在觸發(fā)構(gòu)建都是可以的,主要是根及時(shí)的構(gòu)建新的代碼。如果構(gòu)建失敗,則必要及時(shí)處理導(dǎo)致失敗的問題,修復(fù)后重新構(gòu)建。當(dāng)然構(gòu)建失敗的代碼就不要拉到本地了,會(huì)污染一個(gè)本來是可以運(yùn)行的工作區(qū)。
[持續(xù)集成工具]
講了這么多概念,有沒一種工具把這種實(shí)踐實(shí)現(xiàn)呢?當(dāng)然有,常見的持續(xù)集成工具如下:
jenkins
travis
gitlab
buddybuild
僅列舉了一些典型的,Jenkins 是傳統(tǒng)型的工具,前身是 Hudson,04 年到現(xiàn)在已經(jīng)有十多年的歷史,后幾個(gè)是最近幾年出現(xiàn)的新一批,多少都和容器技術(shù)有點(diǎn)關(guān)系,這里我們主要介紹 Jenkins,因?yàn)檫@個(gè)工具比較常用,各種開發(fā)實(shí)踐都可以通過大量的插件來組合實(shí)現(xiàn),可定制性好很多。
jenkins
1jenkins是一個(gè)開源項(xiàng)目,提供了一種易于使用的持續(xù)集成系統(tǒng),使開發(fā)者從繁雜的集成中解脫出來,專注于更為重要的業(yè)務(wù)邏輯實(shí)現(xiàn)上。同時(shí) Jenkins 能實(shí)施監(jiān)控集成中存在的錯(cuò)誤,提供詳細(xì)的日志文件和提醒功能,還能用圖表的形式形象地展示項(xiàng)目構(gòu)建的趨勢(shì)和穩(wěn)定性。— 維基百科
Jenkins 有哪些功能呢?
1.定時(shí)拉取代碼并編譯
2.靜態(tài)代碼分析
3.定時(shí)打包發(fā)布測(cè)試版
4.自定義額外的操作,如跑單元測(cè)試等
5.出錯(cuò)提醒
基本上都是持續(xù)集成實(shí)踐中的要求和周邊的一些實(shí)現(xiàn)措施,如提醒功能等,出錯(cuò)后及時(shí)提醒開發(fā)者修復(fù),Jenkins 中通過配置 SMTP 配置信息(這個(gè)一般的郵件服務(wù)提供商都有提供),郵件模板等,創(chuàng)建事件觸發(fā)器,在事件(如編譯失?。┌l(fā)生時(shí),及時(shí)發(fā)送郵件通知開發(fā)者,挺方便的。
Jenkins 有很多種觸發(fā)構(gòu)建的方式,如 webhook,定時(shí)更新代碼等,同時(shí)可以在觸發(fā)構(gòu)建后執(zhí)行自定義的構(gòu)建操作,通過編輯自定義的構(gòu)建腳本,幾乎可以進(jìn)行任何構(gòu)建操作。
圖片理解:
1)齒輪:如果將java/maven/ant/git/tomcat/jenkins等軟件比喻為齒輪,如下圖
2)兩個(gè)軟件在一起可以驅(qū)動(dòng)另外一個(gè)軟件,如下圖
3)如果把這些軟件要集成在一起工作,那么這個(gè)軟件就可以存在其他軟件的中間來驅(qū)動(dòng)各個(gè)軟件工作,如下圖:
4)jenkins就是類似中間那個(gè)齒輪,來驅(qū)動(dòng)其他軟件的集成一起工作,如下圖
jenkins是一個(gè)開源軟件項(xiàng)目,旨在提供一個(gè)開放易用的軟件平臺(tái),使得持續(xù)集成編程可能。它的前身是hudson,是基于java開發(fā)的一種持續(xù)集成工具,它可以根據(jù)配置進(jìn)行持續(xù)定期編譯,運(yùn)行相應(yīng)的代碼,將運(yùn)行結(jié)果發(fā)送至郵件或者展示成報(bào)告等。
jenkins作為持續(xù)集成的標(biāo)志性工具,自然是有了持續(xù)集成的眾多優(yōu)點(diǎn)。jenkins可以做一些自動(dòng)化的build,只要我們把jenkins搭建成功,可以設(shè)置幾分鐘build一次,在定時(shí)自動(dòng)build,驗(yàn)證單元測(cè)試,如果發(fā)生錯(cuò)誤則把錯(cuò)誤報(bào)告以email形式發(fā)送給項(xiàng)目模塊負(fù)責(zé)人。
[宏觀理解]
先來張圖,大致理解下宏觀:
詳細(xì)介紹:
至于關(guān)于郵件的配置,也是為了方便我們的開發(fā)和管理,jenkins很強(qiáng)大。
講到這里,還是“啊呀呀,完蛋,還是有點(diǎn)不懂“的話,不如直接甩圖(從網(wǎng)上copy下來的):
這里是選擇Gitlab作為git server。Gitlab的功能和Github差不多,但是是開源的,可以用來搭建私有g(shù)it server,也提供非常強(qiáng)大的web GUI,比如開發(fā)者互相review源代碼的時(shí)候就會(huì)很方便。
系統(tǒng)的工作流程大概分為以下幾步:
1> 開發(fā)者將新版本push到git server (Gitlab)。
2> Gitlab隨后觸發(fā)jenkins master結(jié)點(diǎn)進(jìn)行一次build。(通過web hook或者定時(shí)檢測(cè))
3> jenkins master結(jié)點(diǎn)將這個(gè)build任務(wù)分配給若干個(gè)注冊(cè)的slave結(jié)點(diǎn)中的一個(gè),這個(gè)slave結(jié)點(diǎn)根據(jù)一個(gè)事先設(shè)置好的腳本進(jìn)行build。這個(gè)腳本可以做的事情很多,比如編譯,測(cè)試,生成測(cè)試報(bào)告等等。這些原本需要手動(dòng)完成的任務(wù)都可以交給jenkins來做。
4> 我們?cè)赽uild中要進(jìn)行編譯,這里使用了分布式編譯器distcc來加快編譯速度。
notes
jenkins的工作原理是先將源代碼從gitlab中拷貝一份到本地,然后根據(jù)設(shè)置的腳本進(jìn)行build。我們可以看出,整個(gè)系統(tǒng)的關(guān)鍵就是那個(gè)build腳本,用來告訴jenkins在一次集成中需要執(zhí)行的任務(wù)。
不過我之后是用的Github作為git server。但其實(shí)差不多,先講到這里,重點(diǎn)難點(diǎn)還是在之后jenkins的安裝配置使用上。
-
jenkins
+關(guān)注
關(guān)注
0文章
31瀏覽量
5159
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論