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

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

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

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

每次集成都通過自動化的構建 (包括編譯、發(fā)布和自動化測試) 來驗證, 從而盡快的發(fā)現(xiàn)集成錯誤. 許多團隊都發(fā)現(xiàn)這個過程可以大大減少代碼集成的問題, 讓團隊更快的開發(fā)內聚的軟件. 請注意, 持續(xù)集成不等于持續(xù)編譯.

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

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

開發(fā)人員開發(fā)好一個模塊就進行單元測試；

等所有的模塊都開發(fā)完成之后，由項目經理對所有代碼進行集成；

集成后的項目由項目經理部署到測試服務器上，被交由測試人員進行集成測試；

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

項目經理分配 Bug 給相應的責任人進行修改；

修改完成后，項目經理再次對項目進行集成，并部署到測試服務器上；

測試人員在下一次的集成測試中進行回歸測試；

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

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

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

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

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

正是因為我們無法及時修復 Bug, 或者是沒能在早期就修復 Bug, 從而令整個修復 Bug 的周期拉長了. 不管怎么樣, 我們不可能把明知存在 Bug 的軟件交付給客戶.

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

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

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

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

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

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

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

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

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

自動化部署工作可以解放了集成、測試、部署等重復性勞動, 而且機器集成的頻率明顯可以比手工的高很多.

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

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

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

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

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

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

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