持續(xù)集成（Continuous Integration），也就是我們經(jīng)常說的 CI，是現(xiàn)代軟件開發(fā)技術的基礎。本文論述了當前軟件開發(fā)過程中存在的問題，講解了持續(xù)集成、持續(xù)集成服務器的概念，最終探討了為什么我們需要持續(xù)集成來解決這些問題。

當前軟件開發(fā)過程存在的問題

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

• 項目一開始是先劃分好模塊，分配模塊給相應的開發(fā)人員；
• 開發(fā)人員開發(fā)好一個模塊就進行單元測試；
• 等所有的模塊都開發(fā)完成之后，由項目經(jīng)理對所有代碼進行集成；
• 集成后的項目由項目經(jīng)理部署到測試服務器上，被交由測試人員進行集成測試；
• 測試過程中出現(xiàn) Bug 就提把問題記錄進行 Bug 列表中；
• 項目經(jīng)理分配 Bug 給相應的責任人進行修改；
• 修改完成后，項目經(jīng)理再次對項目進行集成，并部署到測試服務器上；
• 測試人員在下一次的集成測試中進行回歸測試；
• 通過通過之后就部署到生產環(huán)境中；
• 如果測試不通過，則重復上述“分配 Bug -> 修改 Bug -> 集成代碼 -> 部署到測試服務器上 -> 集成測試”工作。

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

1. Bug 總是在最后才發(fā)現(xiàn)

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

2. 越到項目后期，問題越難解決

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

3. 軟件交付時機無法保障

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

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

4. 程序經(jīng)常需要變更

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

5. 無效的等待變多

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

6. 用戶的滿足度低

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

持續(xù)集成、持續(xù)集成服務器的概念

那么好了，在上面論述的這些問題中，我們發(fā)現(xiàn)有些工作是無法避免的，比如測試工作、修改程序、集成工作、部署工作。但其實在整個工作流程上，是存在可以優(yōu)化的空間的，比如，集成測試的工作是否可以提前做？可否有自動化的手段來代替測試、集成、部署工作？圍繞這些，軟件行業(yè)的大師們提出“持續(xù)集成”口號。

1. 什么是持續(xù)集成、持續(xù)集成服務器

在軟件工程中，持續(xù)集成（CI）是指將所有開發(fā)者工作副本每天多次合并到主干的做法。 Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念，盡管在當時他并不主張每天多次集成。而 XP（Extreme programming，極限編程）采用了 CI 的概念，并提倡每天不止一次集成。

而持續(xù)集成服務器就是能夠采用自動化的手段，來解放人的雙手，實現(xiàn)項目持續(xù)集成的工具。與之配套的軟件有 TeamCity、Jenkins、Go 等。

2. 怎么樣才算是“持續(xù)”

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

3. 持續(xù)集成的工作流程

• 當開始更改代碼時，開發(fā)人員會從代碼庫（如 SVN、Git 等）獲取當前代碼庫的副本。
• 當其他開發(fā)人員將更改的代碼提交到代碼庫時，此副本將逐漸停止反映代碼庫中的代碼。代碼分支保持檢出的時間越長，當開發(fā)人員分支重新集成到主線時，多個集成沖突和故障的風險就越大。
• 當開發(fā)人員向代碼庫提交代碼時，他們必須首先更新他們的代碼，以反映代碼庫中的最新更改。
• 當存儲庫與開發(fā)人員的副本不同，他們必須要花時間來先處理沖突。

持續(xù)集成的好處

1. 解放了重復性勞動

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

2. 更快地修復問題

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

3. 更快地交付成果

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

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

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

4. 減少手工的錯誤

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

5. 減少了等待時間

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

6. 更高的產品質量

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

持續(xù)集成的最佳實踐

1. 頻繁檢出代碼

為了讓你本地的副本和代碼庫中的版本最小差異化，建議頻繁檢出代碼。有時候代碼沖突無可避免，但最小差異化最容易解決。而且，越早發(fā)現(xiàn)的問題，解決成本也最低。

2. 頻繁提交代碼

這個與第1條的原理類似，頻繁提交代碼，可以讓其他人的檢出副本和代碼庫中的版本最小差異化。

3. 減少分支，回歸主干

雖然代碼管理工具都支持分支的概念，但應盡量減少其使用。假設有多個分支并行，應及早將變更集成到主干中，而不是同時維護軟件的多個版本。主干作為軟件開發(fā)的工作版本。

4. 使用自動化構建

可以使用 Maven、Ant 等來實現(xiàn)自動化構建，這些工具可以幫助你在構建過程中實現(xiàn)自動化測試。前提是你有寫單元測試用例，比如 JUnit 等。

5. 提交自測

在提交工作之前，每個程序員必須本地集成所有的代碼，做一個完整的構建和運行，并通過所有單元測試。這樣就減少了集成測試在集成服務器上構建失敗的風險。

6. 當前狀態(tài)對于每個人都可見

集成服務器在持續(xù)集成過程中發(fā)現(xiàn)問題，應能發(fā)送告警給相關的干系人。同時，也可以在墻上等醒目的位置設置一個大屏顯示器，將集成服務器的狀態(tài)實時展現(xiàn)在大屏上，方便提醒組員“趕緊回去解決問題”！

持續(xù)集成可能會面臨的挑戰(zhàn)

1. 團隊人員思想上的抵觸

• 無法接受新事物：不管怎么樣，求穩(wěn)心態(tài)的人還是多。總是有人認為老的技術代表穩(wěn)定，新的事物往往會帶來問題。
• 認為手工集成也沒有多少工作量：不是所有的人都參與到了整個持續(xù)集成的環(huán)節(jié)，所以沒有辦法認識到問題全貌。

針對這個問題，可以通過設置一定的持續(xù)集成技術培訓、宣講得到改觀。

2. 管理層的抵觸

• 培訓持續(xù)集成需要投入資金啊，沒錢。
• 持續(xù)集成服務器要增加軟硬件成本啊，沒錢。
• 開發(fā)人員領了那么高的工資，多干活多加班應該啊。

針對這一點，可以從開發(fā)人員的成本和持續(xù)集成的投入（軟硬件）的成本上兩者做下估算。

3. 生產環(huán)境的復雜

• 比如部署的生成環(huán)境是在政務外網(wǎng)，無法從互聯(lián)網(wǎng)直接訪問等。

目前，這個是最麻煩的，還在研究中。初步設想是讓政務外網(wǎng)開辟一個白名單，給持續(xù)集成服務器設置一個單獨的通道。只是思路，未驗證。

當然，考慮到目前的工作的實際，可以先持續(xù)部署軟件到自己公司的演示服務器上，這樣，起碼先解決了客戶和產品經(jīng)理溝通所使用的原型問題。 畢竟，客戶真實使用的軟件在更新的頻率上可以適度的放寬。