摘要：持續(xù)集成的定義大師是這樣定義持續(xù)集成的持續(xù)集成是一種軟件開發(fā)實(shí)戰(zhàn)即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作通常每個(gè)成員每天至少集成一次也就意味著每天可能發(fā)生多次集成持續(xù)集成并不能消除而是讓它們非常容易發(fā)現(xiàn)和改正根據(jù)對(duì)項(xiàng)目實(shí)戰(zhàn)的理解持續(xù)集成中的持續(xù)是指

大師 Martin Fowler 是這樣定義持續(xù)集成的: 持續(xù)集成是一種軟件開發(fā)實(shí)戰(zhàn), 即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作. 通常, 每個(gè)成員每天至少集成一次, 也就意味著每天可能發(fā)生多次集成.

持續(xù)集成并不能消除Bug, 而是讓它們非常容易發(fā)現(xiàn)和改正.

根據(jù)對(duì)項(xiàng)目實(shí)戰(zhàn)的理解, 持續(xù)集成中的 "持續(xù)" 是指不間斷的; "集成" 可分為廣義和狹義, 廣義的集成指軟件各個(gè)過程的集成, 包括開發(fā)、部署、測(cè)試等. 狹義的集成即代碼和代碼之間的集成, 從而保證代碼合并不沖突.

每次集成都通過自動(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)聚的軟件. 請(qǐng)注意, 持續(xù)集成不等于持續(xù)編譯.

在沒有應(yīng)用持續(xù)集成之前，傳統(tǒng)的開發(fā)模式是這樣的：

項(xiàng)目一開始是先劃分好模塊，分配模塊給相應(yīng)的開發(fā)人員；

開發(fā)人員開發(fā)好一個(gè)模塊就進(jìn)行單元測(cè)試；

等所有的模塊都開發(fā)完成之后，由項(xiàng)目經(jīng)理對(duì)所有代碼進(jìn)行集成；

集成后的項(xiàng)目由項(xiàng)目經(jīng)理部署到測(cè)試服務(wù)器上，被交由測(cè)試人員進(jìn)行集成測(cè)試；

測(cè)試過程中出現(xiàn) Bug 就提把問題記錄進(jìn)行 Bug 列表中；

項(xiàng)目經(jīng)理分配 Bug 給相應(yīng)的責(zé)任人進(jìn)行修改；

修改完成后，項(xiàng)目經(jīng)理再次對(duì)項(xiàng)目進(jìn)行集成，并部署到測(cè)試服務(wù)器上；

測(cè)試人員在下一次的集成測(cè)試中進(jìn)行回歸測(cè)試；

通過通過之后就部署到生產(chǎn)環(huán)境中；

如果測(cè)試不通過，則重復(fù)上述“分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測(cè)試服務(wù)器上 -> 集成測(cè)試”工作。

這個(gè)過程中可能會(huì)出現(xiàn)如下問題:

隨著軟件技術(shù)的發(fā)展, 軟件規(guī)模也在擴(kuò)大, 軟件需求越來越復(fù)雜, 軟件已經(jīng)不能簡(jiǎn)單地通過劃分模塊的方式來開發(fā), 往往需要在項(xiàng)目?jī)?nèi)部互相合作, 模塊之間存在一定的依賴關(guān)系, 那么早期就存在的 Bug 往往會(huì)在最后集成的時(shí)候才被發(fā)現(xiàn).

很多開發(fā)者需要在集成階段花費(fèi)大量的時(shí)間來尋找 Bug 的根源, 加上軟件的復(fù)雜性, 問題的根源很難定位. 而且我們都清楚, 間隔的時(shí)間越久, Bug 修復(fù)的成本越高, 因?yàn)檫B開發(fā)人員自己都忘了當(dāng)初寫得是什么鬼代碼, 從而不得不從頭閱讀代碼、理解代碼.

正是因?yàn)槲覀儫o法及時(shí)修復(fù) Bug, 或者是沒能在早期就修復(fù) Bug, 從而令整個(gè)修復(fù) Bug 的周期拉長(zhǎng)了. 不管怎么樣, 我們不可能把明知存在 Bug 的軟件交付給客戶.

而且, 大量沒有在前期預(yù)估到的工作量產(chǎn)生了——開發(fā)人員不得不花費(fèi)大把時(shí)間在查找 Bug 上; 測(cè)試人員不斷的需要進(jìn)行回歸測(cè)試; 項(xiàng)目經(jīng)理不得不疲命于該死的代碼的集成、部署這些重復(fù)性工作——最終導(dǎo)致整個(gè)項(xiàng)目的周期拉長(zhǎng), 交付時(shí)間點(diǎn)往后拖.

某些項(xiàng)目, 程序會(huì)經(jīng)常需要變更. 由于產(chǎn)品經(jīng)理在與客戶交流過程中, 往往實(shí)際的軟件就是最好的原型, 所以軟件會(huì)被當(dāng)作原型作為跟客戶交流的工具. 當(dāng)然, 客戶最希望的當(dāng)然是客戶的想法能夠馬上反映到原型上, 這會(huì)導(dǎo)致程序會(huì)經(jīng)常被修改的. 那么也就意味著“分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測(cè)試服務(wù)器上 -> 集成測(cè)試”工作無形又爆增了.

有可能開發(fā)在等集成其他人的模塊; 測(cè)試人員在等待開發(fā)人員修復(fù) Bug; 產(chǎn)品經(jīng)理在等待新版本上線好給客戶做演示; 項(xiàng)目經(jīng)理在等待其他人提交代碼. 不管怎么樣, 等待意味低效.

這里的用戶是廣義的, 可以指最終的客戶, 也可以是產(chǎn)品經(jīng)理、公司領(lǐng)導(dǎo)、測(cè)試人員, 甚至可能是開發(fā)人員自己. 你想想看, 本來三個(gè)月做完的項(xiàng)目被拉長(zhǎng)到了九個(gè)月甚至一年, 用戶能滿意嗎! 產(chǎn)品經(jīng)理、公司領(lǐng)導(dǎo)經(jīng)常需要拿項(xiàng)目作為演示的原型, 結(jié)果告訴我在演示前一刻發(fā)現(xiàn)還有很多 Bug 沒有解決, 項(xiàng)目啟動(dòng)不了無法訪問, 這叫人情何以堪.

對(duì)于一天需要集成多少次數(shù), 并沒有一個(gè)明確的定義. 一般就是按照自己項(xiàng)目的實(shí)際需要來設(shè)置一定的頻率, 少則可能幾次, 多則可能達(dá)幾十次. 可以設(shè)置按照代碼的變更來觸發(fā)集成, 或者設(shè)置一個(gè)固定時(shí)間周期來集成, 也可以手工點(diǎn)擊集成的按鈕來 “一鍵集成”.

當(dāng)開始更改代碼時(shí)，開發(fā)人員會(huì)從代碼庫(kù)（如 SVN、Git 等）獲取當(dāng)前代碼庫(kù)的副本.

當(dāng)其他開發(fā)人員將更改的代碼提交到代碼庫(kù)時(shí), 此副本將逐漸停止反映代碼庫(kù)中的代碼. 代碼分支保持檢出的時(shí)間越長(zhǎng), 當(dāng)開發(fā)人員分支重新集成到主線時(shí), 多個(gè)集成沖突和故障的風(fēng)險(xiǎn)就越大.

當(dāng)開發(fā)人員向代碼庫(kù)提交代碼時(shí), 他們必須首先更新他們的代碼, 以反映代碼庫(kù)中的最新更改.

當(dāng)存儲(chǔ)庫(kù)與開發(fā)人員的副本不同, 他們必須要花時(shí)間來先處理沖突.

自動(dòng)化部署工作可以解放了集成、測(cè)試、部署等重復(fù)性勞動(dòng), 而且機(jī)器集成的頻率明顯可以比手工的高很多.

由于持續(xù)集成更早的獲取變更, 更早的進(jìn)入測(cè)試, 也就能更早的發(fā)現(xiàn)問題, 解決問題的成本顯著下降.

及早集成、及早測(cè)試減少了缺陷遺留到部署環(huán)節(jié)的機(jī)會(huì). 在某些情況下, 更早地查找錯(cuò)誤還會(huì)減少解決錯(cuò)誤所需的工作量.

如果集成服務(wù)器對(duì)代碼進(jìn)行構(gòu)建過程中發(fā)現(xiàn)錯(cuò)誤, 可以及時(shí)發(fā)送郵件或者短信提供給開發(fā)人員進(jìn)行修復(fù).

如果集成服務(wù)器在部署環(huán)節(jié)發(fā)現(xiàn)當(dāng)前版本有問題不可用, 集成服務(wù)器會(huì)將部署回退到上一個(gè)版本. 這樣服務(wù)器上始終都會(huì)有一個(gè)可用的版本.

人與機(jī)器的一個(gè)最大的區(qū)別是, 在重復(fù)性動(dòng)作上, 人容易犯錯(cuò), 而機(jī)器犯錯(cuò)的幾率幾乎為零. 所以, 當(dāng)我們搭建完成集成服務(wù)器后, 以后的事就交給集成服務(wù)器來打理吧.

持續(xù)集成縮短了從開發(fā)、集成、測(cè)試、部署各個(gè)環(huán)節(jié)的時(shí)間, 從而也就縮短了中間可以出現(xiàn)的等待時(shí)間. 持續(xù)集成, 意味著開發(fā)、集成、測(cè)試、部署也得以持續(xù).

集成服務(wù)器往往提供 Code review、代碼質(zhì)量檢測(cè)等功能. 對(duì)代碼不規(guī)范或者有錯(cuò)誤的地方會(huì)進(jìn)行標(biāo)識(shí), 也可以設(shè)置郵件、短信等進(jìn)行告警. 而開發(fā)人員通過 Code review 也可以持續(xù)提高編程的能力.