你好,，歡迎來到Java基礎(chǔ)知識分解站，今天小編為猿猿們整理了持續(xù)集成的相關(guān)問題,。持續(xù)集成（Continuous Integration）,，也就是我們經(jīng)常說的 CI，是現(xiàn)代軟件開發(fā)技術(shù)的基礎(chǔ),。本文主要介紹當(dāng)前軟件開發(fā)過程中存在的問題,，講解了持續(xù)集成,、持續(xù)集成服務(wù)器的概念，最終探討了為什么我們需要持續(xù)集成來解決這些問題,。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 越到項(xiàng)目后期，問題越難解決

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

2. 軟件交付時(shí)機(jī)無法保障

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

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

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

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

4. 無效的等待變多

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

5. 用戶的滿足度低

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

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

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

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

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

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

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

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

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

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

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

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

  
  

0. 解放了重復(fù)性勞動

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

1. 更快地修復(fù)問題

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

2. 更快地交付成果

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

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

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

3. 減少手工的錯(cuò)誤

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

4. 減少了等待時(shí)間

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

5. 更高的產(chǎn)品質(zhì)量

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

0. 頻繁檢出代碼

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

1. 頻繁提交代碼

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

2. 減少分支,，回歸主干

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

3. 使用自動化構(gòu)建

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

4. 提交自測

在提交工作之前,，每個(gè)程序員必須本地集成所有的代碼，做一個(gè)完整的構(gòu)建和運(yùn)行,，并通過所有單元測試,。這樣就減少了集成測試在集成服務(wù)器上構(gòu)建失敗的風(fēng)險(xiǎn),。

5. 當(dāng)前狀態(tài)對于每個(gè)人都可見

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

0. 團(tuán)隊(duì)人員思想上的抵觸

• 無法接受新事物：不管怎么樣，求穩(wěn)心態(tài)的人還是多,?？偸怯腥苏J(rèn)為老的技術(shù)代表穩(wěn)定，新的事物往往會帶來問題,。

• 認(rèn)為手工集成也沒有多少工作量：不是所有的人都參與到了整個(gè)持續(xù)集成的環(huán)節(jié),，所以沒有辦法認(rèn)識到問題全貌。

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

1. 管理層的抵觸

• 培訓(xùn)持續(xù)集成需要投入資金啊,，沒錢,。

• 持續(xù)集成服務(wù)器要增加軟硬件成本啊，沒錢,。

• 開發(fā)人員領(lǐng)了那么高的工資,，多干活多加班應(yīng)該啊。

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

2. 生產(chǎn)環(huán)境的復(fù)雜

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

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

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

（完）

恭喜你今天又收獲了新知識

• 原文鏈接：http://mp.weixin.qq.com/s/CiTmzXbR-HXRRq2YM858qw

•