_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程

1、 文本復(fù)制檢測(cè)報(bào)告單(全文標(biāo)明引文)檢測(cè)文獻(xiàn):作者:檢測(cè)范圍:21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程徐萌 中國學(xué)術(shù)期刊網(wǎng)絡(luò)出版總庫 中國博士學(xué)位論文全文數(shù)據(jù)庫/中國優(yōu)秀碩士學(xué)位論文全文數(shù)據(jù)庫中國重要會(huì)議論文全文數(shù)據(jù)庫 中國重要報(bào)紙全文數(shù)據(jù)庫中國專利全文數(shù)據(jù)庫 互聯(lián)網(wǎng)資源 英文數(shù)據(jù)庫(涵蓋期刊、博碩、會(huì)議的英文數(shù)據(jù)以及德國Springer、英國Taylor&Francis 臺(tái)學(xué)術(shù)文獻(xiàn)庫 優(yōu)先出版文獻(xiàn)庫互聯(lián)網(wǎng)文檔資源個(gè)人比對(duì)庫 1900-01-01至2013-03-24 期刊數(shù)據(jù)庫等)時(shí)間范圍:可能已提前檢測(cè)，檢測(cè)時(shí)間：2013-3-16 14:25:07，檢測(cè)結(jié)果：8.

2、1%1. 21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程_第1部分總字?jǐn)?shù)：6024文字復(fù)制比：14.7%(884)(0)1持續(xù)集成在現(xiàn)代軟件開發(fā)中的應(yīng)用與研究6.3%徐仕成(導(dǎo)師：楊邦榮) - 中南大學(xué)碩士論文- 2007-05-01是否引證：是2基于變更管理的持續(xù)集成研究與應(yīng)用6.3%相(導(dǎo)師：袁兆山) - 合肥工業(yè)大學(xué)碩士論文- 2009-04-01是否引證：是3基于AOP的集成測(cè)試方法研究及其在信息科研系統(tǒng)持續(xù)集成中的應(yīng)用4.8%康乃元(導(dǎo)師：徐建良) - 中國海洋大學(xué)碩士論文- 2010-04-15是否引證：是4基于MIPS的嵌入式Linux系統(tǒng)開發(fā)環(huán)境的設(shè)計(jì)與實(shí)現(xiàn)2

3、.3%邱烽(導(dǎo)師：王東;林貴旭) - 上海交通大學(xué)碩士論文- 2011-06-01是否引證：否5自動(dòng)化測(cè)試平臺(tái)Safe的設(shè)計(jì)與實(shí)現(xiàn)2.0%白赫鵬(導(dǎo)師：王方石) - 北京交通大學(xué)碩士論文- 2011-06-01是否引證：否6基于TeamCity的Web項(xiàng)目持續(xù)集成方案2.0%李婧; - 軟件導(dǎo)刊- 2009-08-30是否引證：否- 1 -總文字復(fù)制比：4%去除引用文獻(xiàn)復(fù)制比：0.6%去除本人已發(fā)表文獻(xiàn)復(fù)制比：4% 單篇最大文字復(fù)制比：1.5% 重復(fù)字?jǐn)?shù)： 1033 總字?jǐn)?shù)： 25552單篇最大重復(fù)字?jǐn)?shù)： 381 總段落數(shù)： 3前部重合字?jǐn)?shù)：951疑似段落最大重合字?jǐn)?shù)：884 疑似段落數(shù)：3后

4、部重合字?jǐn)?shù)：82疑似段落最小重合字?jǐn)?shù)：67 指標(biāo)：剽竊觀點(diǎn) 自我剽竊一稿多投過度引用整體剽竊重復(fù)發(fā)表剽竊文字表述 表格：0腳注與尾注：48 14.7%（884）21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程_第1部分（總6024字） 0.6%（67）21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程_第2部分（總10904字） 1%（82）21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程_第3部分（總8624字） （注釋：無問題部分文字復(fù)制比部分引用部分） ADBD2013R_20130324124531201303241248062005568

5、73813檢測(cè)時(shí)間：2013-03-24 12:48:06 1引言 1.1課題研究背景 軟件信息業(yè)的蒸蒸日上，使得電子軟件被社會(huì)的各個(gè)領(lǐng)域所廣泛應(yīng)用，而軟件產(chǎn)品的質(zhì)量也就毋庸置疑的成為了人們非常在意的重要因素。實(shí)際上，對(duì)于軟件來講，無論在開發(fā)的過程中應(yīng)用了什么樣的方法或技術(shù)，在最終的軟件產(chǎn)品中都會(huì)出現(xiàn)一些錯(cuò)誤或者缺陷。也許隨著開發(fā)技術(shù)的進(jìn)步、開發(fā)語言的逐步升級(jí)、開發(fā)方式慢慢的進(jìn)步，軟件產(chǎn)品的質(zhì)量會(huì)越來越好，但是想要完全修復(fù)軟件中的錯(cuò)誤也是不可能的。因此，軟件的發(fā)展永遠(yuǎn)也不能達(dá)到人們對(duì)軟件的要求水平，而這些產(chǎn)生的錯(cuò)誤也就需要軟件測(cè)試過程來發(fā)現(xiàn)，測(cè)試能夠決定一個(gè)軟件項(xiàng)目的質(zhì)量。國外很多公司對(duì)軟件測(cè)

6、試都非常的重視，尤其是美國著名的微軟公司，他們?cè)陂_發(fā)軟件的過程中，測(cè)試人員的數(shù)量一般情況是開發(fā)人員的1.5倍到2.5倍左右，表1-1是微軟公司在開發(fā)Exchange 2000和Windows 2000時(shí)的人員配置情況。 表1-1 美國微軟公司軟件測(cè)試人員分布 隨著軟件測(cè)試?yán)碚撘约皯?yīng)用研究工作的不斷深入，軟件測(cè)試也逐漸的經(jīng)歷了以下的好幾個(gè)發(fā)展歷程，每一個(gè)發(fā)展階段也代表了軟件測(cè)試慢慢走向成熟： 1. 20世紀(jì)60年代，在軟件工程建立前，測(cè)試是為了證明程序開發(fā)的正確性。 2. 20世紀(jì)70年代，產(chǎn)生了Ad-hoc testing，意思是測(cè)試者一邊測(cè)試一邊設(shè)計(jì)測(cè)試的內(nèi)容，沒有在測(cè)試之前建立完整的計(jì)劃和

7、測(cè)試周期表，也并不對(duì)測(cè)試結(jié)果進(jìn)行記錄和保存，因此那時(shí)的測(cè)試不能保證準(zhǔn)確性，與前期的調(diào)試并沒有很大的區(qū)別。 3. 1979年， Glenford Myers的The Art of Software Testing，對(duì)測(cè)試重新進(jìn)行了定義，他認(rèn)為軟件測(cè)試過程是一個(gè)程序或者系統(tǒng)，目標(biāo)是為了發(fā)現(xiàn)缺陷和錯(cuò)誤。 4. 20世紀(jì)80年代初期，軟件測(cè)試開始著重于質(zhì)量，其內(nèi)涵也變得有所不同，表明軟件測(cè)試不只是一個(gè)發(fā)現(xiàn)錯(cuò)誤的過程 ，還應(yīng)該包括評(píng)估軟件質(zhì)量和功能的一個(gè)大范圍，同時(shí)也制定了一些軟件測(cè)試標(biāo)準(zhǔn)。 5. 20世紀(jì)90年代后期，軟件開發(fā)人員開始關(guān)注一些過程管理對(duì)于軟件測(cè)試的影響，形成了各種測(cè)試模型，也標(biāo)志著測(cè)試

8、能力在慢慢走向成熟。 6. 進(jìn)入21世紀(jì)，人們?cè)絹碓秸J(rèn)識(shí)到了軟件測(cè)試的重要性，甚至掀起了軟件開發(fā)工作應(yīng)該要以軟件測(cè)試為主要內(nèi)容的思潮 。 在經(jīng)歷了這些發(fā)展階段之后，針對(duì)不同的發(fā)展階段，軟件測(cè)試的含義和涵蓋范圍都在不斷的發(fā)生著變化。而軟件測(cè)試不僅僅是找錯(cuò)而已，還需要有計(jì)劃的進(jìn)行，而且越早的發(fā)現(xiàn)軟件的錯(cuò)誤，花費(fèi)的成本也就越低。 軟件測(cè)試分為很多類型，比如，按照測(cè)試的對(duì)象來分包括單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。根據(jù)每一個(gè)測(cè)試的流程和階段都要使用不一樣的測(cè)試工具或者系統(tǒng)，而且還需要隨時(shí)對(duì)其進(jìn)行維護(hù)。在軟件測(cè)試階段，集成測(cè)試是其中的重要一步，它是在單元測(cè)試完成之后進(jìn)行的，作用是保證軟件系統(tǒng)中各個(gè)

9、模塊能夠正常銜接工作的重要階段，還能彌補(bǔ)單元測(cè)試過程中無法完成的工作。集成測(cè)試開始的越早，故障發(fā)現(xiàn)的就越早，消除故障的成本就會(huì)減少。但是在軟件開發(fā)過程中遇到的主要風(fēng)險(xiǎn)也是在集成問題上，許多軟件開發(fā)項(xiàng)目的最終失敗都是因?yàn)樵谧詈蠹蓵r(shí)出現(xiàn)問題。 持續(xù)集成的出現(xiàn)解決了上述的問題，它是伴隨著敏捷軟件開發(fā)而建立的，現(xiàn)在已經(jīng)被大部分的軟件企業(yè)的開發(fā)團(tuán)隊(duì)所接受，但是它的價(jià)值并沒有真正的體現(xiàn)出來，原因是開發(fā)者缺乏對(duì)持續(xù)集成系統(tǒng)的了解，而開發(fā)團(tuán)隊(duì)又很少有能在應(yīng)用持續(xù)集成時(shí)出現(xiàn)問題的解決方法和經(jīng)驗(yàn)，因此，對(duì)持續(xù)集成的研究就從未停止過。 1.2課題研究現(xiàn)狀及意義 Kent Beck在1996年提出了極限編程，也就是

10、大家所熟知的XP的概念，他在 Extreme Programming Explained: Embrace Change（解析極限編程擁抱變化）一書中闡述了極限編程的12個(gè)最佳實(shí)踐，持續(xù)集成在初期時(shí)就是開始于XP中的12個(gè)最佳實(shí)踐之一。盡管Kent Beck提出了持續(xù)集成這個(gè)概念，但是因?yàn)閄P剛開始并沒有受到業(yè)內(nèi)的普遍認(rèn)可，很多人對(duì)此集成方法產(chǎn)生質(zhì)疑，并且他在書中也僅僅是提出了實(shí)踐持續(xù)集成的大概思想，并且他當(dāng)時(shí)提出的方法在極限編程思想的基礎(chǔ)上，他認(rèn)為采用持續(xù)集成實(shí)踐必須在XP的軟件開發(fā)模式的環(huán)境下進(jìn)行，但是在那個(gè)環(huán)境下軟件行業(yè)的開發(fā)者們還都不太能夠接受和認(rèn)可極限編程開發(fā)模式，因此，大家對(duì)持續(xù)集

11、成的誤解也由此產(chǎn)生。 2000年，ThoughtWorks公司的首席科學(xué)家同時(shí)也是極限編程思想的發(fā)起者之一的Martin Fowler以“Continuous Integration（持續(xù)集成）”為題寫了一篇享譽(yù)業(yè)內(nèi)的文章，他將持續(xù)集成描述為：持續(xù)集成是一種軟件開發(fā)實(shí)踐，即團(tuán)隊(duì)的成員們經(jīng)常集成他們的工作，每個(gè)成員每天至少集成一次，這導(dǎo)致每天發(fā)生多次集成。每次集成都通過自動(dòng)化的構(gòu)建（包括- 2 -一種敏捷的Web軟件快速開發(fā)工具的設(shè)計(jì)與實(shí)現(xiàn) 汪滟(導(dǎo)師：程文青) - 華中科技大學(xué)碩士論文- 2007-06-01 1.2% 是否引證：否 8 快速原型法在軟件開發(fā)中的應(yīng)用 1.2% 梅燦華,孟慶全

12、- 淮南職業(yè)技術(shù)學(xué)院學(xué)報(bào)- 2003-02-15 是否引證：否 9 極限編程研究與應(yīng)用 0.9% 王向陽(導(dǎo)師：陳珉) - 武漢大學(xué)碩士論文- 2004-05-08 是否引證：是 10 基于極限編程方法的教育軟件項(xiàng)目開發(fā) 0.6% 汪灝;陳丹敏;楊建豪; - 軟件導(dǎo)刊- 2012-03-31 是否引證：否 原文內(nèi)容 7 測(cè)試）來驗(yàn)證，從而盡快檢測(cè)出集成錯(cuò)誤。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過程會(huì)大大減少集成問題，讓團(tuán)隊(duì)更夠更快地開發(fā)內(nèi)聚的軟件 。他是在Thoughtworks公司軟件項(xiàng)目持續(xù)集成實(shí)踐的基礎(chǔ)上詳細(xì)介紹了持續(xù)集成實(shí)踐的應(yīng)用。他了Kent Beck的一部分觀點(diǎn)，并且認(rèn)為就算是不采用采用極限編程的開發(fā)

13、模式，應(yīng)用持續(xù)集成實(shí)踐模式來進(jìn)行軟件的開發(fā)和管理都是有必要的。不過他只是在文章當(dāng)中提到了要實(shí)現(xiàn)持續(xù)集成所需要的幾個(gè)重點(diǎn)問題以及其基礎(chǔ)的理論，并沒有說明如何來實(shí)現(xiàn)這些實(shí)踐。這篇文章的出現(xiàn)并流行，讓持續(xù)集成的價(jià)值慢慢被發(fā)現(xiàn)和認(rèn)可，但是在實(shí)際項(xiàng)目中如何真正使用持續(xù)集成方式，還是存在著很多問題 。 國外的軟件企業(yè)相比于我們國家對(duì)持續(xù)集成的研究和應(yīng)用開始較早，大部分的大型軟件公司都陸續(xù)研制出了符合自己軟件開發(fā)模式的持續(xù)集成工具和產(chǎn)品。例如Thoughtworks公司就推出了它的CruiseControl系列持續(xù)集成專用工具，該工具的誕生很大程度上推進(jìn)了持續(xù)集成研究領(lǐng)域的發(fā)展。雖然我國對(duì)于持續(xù)集成的應(yīng)用研

14、究也在慢慢進(jìn)步，但是相比于發(fā)達(dá)國家，還有比較大的差距。中國敏捷軟件開發(fā)大會(huì)（AgileChina）一直把持續(xù)集成作為討論的熱門話題，但是集中以發(fā)表出現(xiàn)的問題為主，很少有切實(shí)可行的解決方案。此外，國際軟件組織定期都會(huì)舉行Continuous Integration and Testing Conference（持續(xù)集成和測(cè)試會(huì)議），主題就是有關(guān)持續(xù)集成的研究和應(yīng)用，并且從2007年起每年都會(huì)舉行，在會(huì)議中有許多項(xiàng)目都得到了很大的進(jìn)展。Jesper Holck和 Niles Jorgensen就指出了：“持續(xù)集成的應(yīng)用為FreeBSD和Mozilia這兩個(gè)大型的軟件項(xiàng)目提供了很好的質(zhì)量保證”。 目

15、前，持續(xù)集成已經(jīng)應(yīng)用到了全球85%以上的軟件開發(fā)項(xiàng)目中。例如，微軟公司在擁有上百萬甚至上千萬的代碼的軟件開發(fā)項(xiàng)目中仍然能夠每天都做持續(xù)集成，這也就證明了持續(xù)集成是非常有價(jià)值而且重要的。 在互聯(lián)網(wǎng)行業(yè)，軟件更新?lián)Q代的非?？欤粩嘧兓能浖_發(fā)模式下，每一個(gè)軟件開發(fā)公司都想趕在行業(yè)內(nèi)發(fā)布自己的最新產(chǎn)品，時(shí)間就是金錢，怎樣在最短的開發(fā)周期內(nèi)就能開發(fā)出最優(yōu)秀的產(chǎn)品、獲得更多用戶的信賴和喜歡成為了互聯(lián)網(wǎng)企業(yè)追求的目標(biāo)?，F(xiàn)如今國內(nèi)外比較大型的開發(fā)公司如Google、百度、阿里巴巴等，都引入持續(xù)集成方法以此來降低軟件開發(fā)過程中的風(fēng)險(xiǎn)以及不斷改進(jìn)和提高軟件的質(zhì)量。 Google是互聯(lián)網(wǎng)公司中的龍頭老大，同時(shí)它

16、的持續(xù)集成技術(shù)也是行業(yè)的領(lǐng)先者。谷歌公司有著很強(qiáng)大的自動(dòng)化測(cè)試設(shè)施來確保軟件開發(fā)過程中集成測(cè)試階段的順利進(jìn)行，而且也減少了測(cè)試人員在部署、運(yùn)行、分析測(cè)試結(jié)果等方面的工作量和精力 ，能把更多的時(shí)間放在開發(fā)上，提升軟件開發(fā)效率，谷歌公司也在不斷的升級(jí)持續(xù)集成系統(tǒng)以更好的改善其功能。 百度在國內(nèi)的互聯(lián)網(wǎng)公司中屬于佼佼者，它在2009年開始實(shí)施敏捷開發(fā)實(shí)踐，2010年在各個(gè)產(chǎn)品開發(fā)項(xiàng)目中普及持續(xù)集成模式，獲得了很大的成效。在持續(xù)集成過程中建立一套完整可靠的產(chǎn)品發(fā)布流程，力爭(zhēng)對(duì)每一個(gè)測(cè)試階段都實(shí)現(xiàn)自動(dòng)化，對(duì)所有階段進(jìn)行嚴(yán)格的版本控制，開發(fā)團(tuán)隊(duì)每一個(gè)成員都要對(duì)自己提交的變更負(fù)責(zé)任，并且以同樣的方式進(jìn)行各種

17、環(huán)境部署，并對(duì)次系統(tǒng)不斷的更新改進(jìn)，通過持續(xù)集成建立一條全自動(dòng)的測(cè)試流水線。自從引入持續(xù)集成后，百度公司的產(chǎn)品發(fā)布周期也縮短了很多，由引入前的九天減少為三天，極大程度的縮減了測(cè)試周期和人工的耗時(shí)如圖1-1。 圖1-1 百度公司引入持續(xù)集成前后對(duì)比圖1.3課題來源 本課題是源于筆者在海信傳媒網(wǎng)絡(luò)技術(shù)實(shí)習(xí)期間遇到的軟件開發(fā)中的問題： 1. 集成時(shí)間滯后帶來缺陷修復(fù)成本較大 在實(shí)際項(xiàng)目開發(fā)的最開始階段，就會(huì)有很多問題，但是往往卻是到最后集成時(shí)才會(huì)發(fā)現(xiàn)問題，大部分的軟件項(xiàng)目都是大型復(fù)雜的，就會(huì)導(dǎo)致開發(fā)人員一般要花大量的時(shí)間和精力來尋找項(xiàng)目中的問題和Bug的根源所在，就算是順利的找到了原因出在什么地方，

18、最后都會(huì)由于涉及了很多的模塊和功能，需要對(duì)軟件整個(gè)系統(tǒng)做出更改，這個(gè)過程不僅會(huì)浪費(fèi)開發(fā)人員的時(shí)間也會(huì)導(dǎo)致項(xiàng)目無法按期完成，造成巨大的經(jīng)濟(jì)損失。根據(jù)行業(yè)經(jīng)驗(yàn)，如果在編碼階段Bug的修復(fù)成本為1，那么在軟件提交上線之后，修復(fù)Bug的成本就將達(dá)到401000！Bug發(fā)現(xiàn)的越晚，修復(fù)成本越大。 2. 集成次數(shù)有限帶來缺陷不能充分暴露 在目前海信傳媒的整個(gè)軟件開發(fā)過程中，集成的次數(shù)往往只有一次，即僅僅在各模塊編碼結(jié)束之后才進(jìn)行一次集成，由此帶來的問題就是由于模塊間有著很強(qiáng)的交互性，軟件的Bug不能被充分暴露出來。 以傳媒公司的SmartTV3.4項(xiàng)目為例，在項(xiàng)目研發(fā)過程中，軟件質(zhì)量是通過文檔評(píng)審（Doc

19、ument Review）-代碼走查 （Code Review）-單元測(cè)試（UT）-集成測(cè)試（LIT）-系統(tǒng)測(cè)試（SIT）各個(gè)階段來保障的。如圖1-2所示，在項(xiàng)目前期，經(jīng)過文檔評(píng)審（Document Review）、代碼走查（Code Review）和單元測(cè)試（UT），大約48%的Bug已經(jīng)在前期被修復(fù)。但是仍然有32%的Bug在后期的集成測(cè)試階段（LIT）才被發(fā)現(xiàn)。這正是由于各模塊在提交LIT之前缺少必要的集成導(dǎo)致的，如果能夠在開發(fā)階段盡早集成、進(jìn)行多次的集成，那么就可以完全充分的認(rèn)識(shí)到軟件存在的問題。 圖1-2 海信傳媒公司軟件開發(fā)各階段的Bug比例圖 3. 集成測(cè)試完全依靠手工致使效率低

20、下 在公司項(xiàng)目開發(fā)的過程中，一方面，研發(fā)部門對(duì)于軟件產(chǎn)品的版本質(zhì)量控制不夠，導(dǎo)致前期的UT測(cè)試、CodeView不充分 ，導(dǎo)致在集成測(cè)試階段發(fā)現(xiàn)大量的問題；另一方面，研發(fā)內(nèi)部對(duì)于版本沒有控制的手段，導(dǎo)致版本發(fā)布頻繁。這就給集成測(cè)試部門帶來了極大的測(cè)試壓力。由于目前的集成測(cè)試大部分依賴于手工完成，因此測(cè)試部門就需要全員投入，往往需要加班才能完成測(cè)試任務(wù)，人員的高負(fù)荷投入也使得測(cè)試過程中出現(xiàn)錯(cuò)誤和忽略錯(cuò)誤的幾率增大。 以公司的SmartTV3.22項(xiàng)目為例，EPG（電子節(jié)目菜單）在一周之內(nèi)總共提交了9個(gè)版本，每提交一次版本就需要對(duì)大約 - 3 - 100條測(cè)試用例進(jìn)行一歸測(cè)試，在短時(shí)間內(nèi)需要所有的

21、測(cè)試工程師進(jìn)行大量和反復(fù)的手工測(cè)試，造成測(cè)試人員苦不堪言。 4. 現(xiàn)有集成模式帶來開發(fā)進(jìn)度不可控 由于在現(xiàn)有軟件開發(fā)過程中把模塊集成和集成測(cè)試置于整個(gè)項(xiàng)目開發(fā)周期的相對(duì)靠后階段，因此在沒有進(jìn)行集成測(cè)試時(shí) ，開發(fā)人員對(duì)整個(gè)項(xiàng)目的開發(fā)進(jìn)度和狀況都不是很清楚，一般都是由每個(gè)團(tuán)隊(duì)成員自己估計(jì)完成的百分比，但是這種估計(jì)肯定是不完全準(zhǔn)確的，就會(huì)給項(xiàng)目帶來很大的風(fēng)險(xiǎn)。 目前傳媒公司幾乎所有的項(xiàng)目采用的都是瀑布式的開發(fā)模式，這種瀑布式的開發(fā)模式實(shí)際上是一種順序模式，它將軟件開發(fā)的每一個(gè)階段都嚴(yán)格劃分，并要求在開始下一階段的工作之前必須完成上一階段的所有工作，各階段之間存在嚴(yán)格的順序性和依賴性。 在軟件開發(fā)的流

22、程中，集成測(cè)試是影響項(xiàng)目質(zhì)量的一個(gè)重要因素。瀑布集成是在編碼完全結(jié)束之后才開始，處于整個(gè)開發(fā)周期相對(duì)靠后的階段，一旦集成測(cè)試中發(fā)現(xiàn)Bug，需逐級(jí)回溯來重新確認(rèn)。而且目前項(xiàng)目的開發(fā)人員都是各自獨(dú)立工作，集成測(cè)試是最后所有開發(fā)人員把每一個(gè)模塊的全部代碼提交后才進(jìn)行的，這種方法可以適用于比較簡(jiǎn)單和早期的軟件開發(fā)過程中 ，但是隨著集團(tuán)智能化戰(zhàn)略的推進(jìn)，公司承擔(dān)著越來越多的系統(tǒng)開發(fā)任務(wù)。軟件應(yīng)用的復(fù)雜性日益提高、軟件功能的交互性越來越強(qiáng)、軟件需求的變更也越來越頻繁，開發(fā)人員之間的分工合作越來越深，相互依賴程度也越來越高，幾乎沒有各自完全獨(dú)立工作的模塊，因此，這種模式會(huì)給后期的集成工作帶來了很大的風(fēng)險(xiǎn)。在

23、這種背景下，尋求更好的開發(fā)模式和集成策略就成為目前較為迫切的需求，也是本文所關(guān)注的焦點(diǎn)。 如果能夠引入持續(xù)集成實(shí)踐，就可以避免了上述遇到的問題，但是基于當(dāng)前研發(fā)部門的情況，進(jìn)行持續(xù)集成實(shí)踐還存在著以下幾個(gè)問題： 1. 雖然開發(fā)團(tuán)隊(duì)已經(jīng)認(rèn)識(shí)到原有集成模式的缺點(diǎn)并且開始認(rèn)識(shí)到持續(xù)集成的優(yōu)點(diǎn)和價(jià)值，但是由于缺少對(duì)持續(xù)集成真正內(nèi)涵的理解，也不能正確的應(yīng)用和實(shí)施持續(xù)集成。 2. 持續(xù)集成的成功案例不夠多，很少有實(shí)際軟件項(xiàng)目的實(shí)踐指導(dǎo)。 3. 很多管理層認(rèn)為持續(xù)集成可以通過開發(fā)者手動(dòng)來完成，而忽略了它的真正意義。 面臨以上的幾點(diǎn)問題，為了使持續(xù)集成能夠在軟件開發(fā)項(xiàng)目中得到有效用，本課題希望通過對(duì)持續(xù)集成的

24、研究以及在海信傳媒的實(shí)際項(xiàng)目中的試驗(yàn)經(jīng)驗(yàn)，能夠讓更多的開發(fā)者們對(duì)持續(xù)集成的理論有更深刻的認(rèn)識(shí)，理解它的真正內(nèi)涵和價(jià)值，并且能把持續(xù)集成最后應(yīng)用到各自的開發(fā)項(xiàng)目中，收獲它所帶來的成功的喜悅。 1.4 課題的研究工作 第一章首先介紹了本文的研究背景情況、持續(xù)集成在業(yè)內(nèi)的現(xiàn)狀和選擇此課題的意義，并說明了本研究是基于本人在海信傳媒公司的項(xiàng)目經(jīng)歷而進(jìn)行的。 第二章比較了常用軟件開發(fā)模型的集成方式： “Big-Bang”集成方式，“迭代遞增”方式，以及微軟公司的“每日構(gòu)建”模式，然后提出了現(xiàn)代敏捷軟件開發(fā)與持續(xù)集成的概念，并比較了每日構(gòu)建和持續(xù)集成的不同。 第三章本章首先對(duì)持續(xù)集成的概念做了具體的解釋，然

25、后深入研究了持續(xù)集成的基礎(chǔ)理論和工作方式，最后總結(jié)了持續(xù)集成在現(xiàn)代企業(yè)軟件開發(fā)中的重要價(jià)值，為后面的深入研究提供了動(dòng)力。 第四章建立了持續(xù)集成的系統(tǒng)架構(gòu)，并對(duì)持續(xù)集成系統(tǒng)的各個(gè)構(gòu)建工具做了細(xì)致的討論，然后最終對(duì)選擇的持續(xù)集成構(gòu)建工具進(jìn)行分析。 第五章提出了基于Jenk的具體設(shè)計(jì)方案，包括了版本控制的實(shí)現(xiàn)、自動(dòng)化測(cè)試的構(gòu)建和安裝Jenk的方法和配置，然后給出了該方案最后在項(xiàng)目中的初期實(shí)施效果。最后分析了在實(shí)施持續(xù)集成實(shí)踐的過程中可能會(huì)出現(xiàn)的很多誤區(qū)。 - 4 -腳注和尾注 1. 袁冰，操云甫Web客戶端應(yīng)用程序性能測(cè)試自動(dòng)化研究計(jì)算機(jī)測(cè)量與控制200412(8)：732-734. 2. Will

26、iam ELewis?軟件測(cè)試與持續(xù)質(zhì)量改進(jìn)M人民郵電，2010. 3. 張大方，李瑋軟件測(cè)試技術(shù)與管理湖南：湖南，2007，12. 4. Glenford，J.MThe Art of Software Testing MJohnWiley&Sons，Inc，2004. 5. 陳宏剛，熊明華，林斌等編著.軟件開發(fā)過程與案例北京：清華大學(xué)，2003. 6. Kent Beck Extreme Programming Explained：Embrace ChangeAddison-Wesley，Pearson Education，2000. 7. Amr Elssamadisy，Gregory S

27、challiol Recognizing and responding to bad smells in extreme programming. Proceedings of the 24th International Conference on Software Engineering，2002. 8. Matrin Fowler，Matthew FoemmelContinuous Integration EB/OLhttp:/www. martinfowler. com/articles/Continuoushitegration.html，2000. 9. CruiseControl

28、 EB/OL/. 10. Continuous Integration Testing Conference./index.php，2006. 11. Jesper Holck，Niels JorgensenContinuous integration and quality assurance: a case study of two open source projectsFree/open Source Software Development. Idea Group Publ

29、ishing， 2005. 12. 陳剛，羌鈴鈴軟件項(xiàng)目開發(fā)中的持續(xù)集成研究.項(xiàng)目管理結(jié)束，2011，9(12). 第六章總結(jié)本文的所有研究?jī)?nèi)容，提出了本方案的可行性，并對(duì)后期的工作做出了長遠(yuǎn)的展望。1.5 本章小結(jié) 本章首先介紹了整篇本章的研究背景情況，以及持續(xù)集成在業(yè)內(nèi)的現(xiàn)狀和為什么選擇此課題的意義，并闡述了課題的來源：說明了本研究是基于本人在海信傳媒公司的項(xiàng)目經(jīng)歷而進(jìn)行的，最后歸納總結(jié)了本文的研究工作，并對(duì)每一章都做了概括 ，讓讀者對(duì)后續(xù)的研究工作有一個(gè)大體的輪廓和概念。 2 軟件開發(fā)模型與集成方式的對(duì)比研究 目前，一般的大型軟件產(chǎn)品都由幾百萬甚至上千萬行代碼構(gòu)成，例如：windows9

30、5的操作系統(tǒng)源代碼就達(dá)到大約1100萬行之多。整個(gè)系統(tǒng)能否正常工作都與這千萬行的代碼密切相關(guān)，任何一行出問題都可能導(dǎo)致系統(tǒng)，并且每個(gè)部分之間又相互影響。至今為止，已經(jīng)出現(xiàn)了很多種的軟件開發(fā)模型和集成，而每一種模式都有各自的特點(diǎn)，它們?cè)诘挚癸L(fēng)險(xiǎn)和和降低項(xiàng)目的不確定性上都體現(xiàn)著不同的作用，他們之間的關(guān)系也密不可分，相互又都有著交叉關(guān)系。但是總結(jié)一下在軟件集成時(shí)我們要考慮的方面無疑也就是幾下幾點(diǎn)： 1.2.3.整合各個(gè)模塊時(shí)會(huì)不會(huì)出現(xiàn)數(shù)據(jù)的丟失。每個(gè)分模塊集成時(shí)是否會(huì)出現(xiàn)互相干擾。 每個(gè)小模塊獨(dú)自可以正常工作，但是集成后是否會(huì)出現(xiàn)問題。在軟件飛速發(fā)展的這幾十年中，尋找更好的軟件開發(fā)方法和有效的集成方

31、式一直是軟件工程領(lǐng)域研究的熱點(diǎn)，在這個(gè)過程中不斷的涌現(xiàn)出了很多種的開發(fā)模型和集成方式。下面就選擇幾個(gè)典型的例子來比較一下各種模型和集成方式的特點(diǎn)?！癇ig- Bang”、“迭代遞增”和“每日構(gòu)建”這三種集成方式都是業(yè)內(nèi)研究和討論的熱點(diǎn)，也代表著集成領(lǐng)域的發(fā)展。比較這三種集成模式之后也就對(duì)持續(xù)集成的思想起源有了更加深刻的認(rèn)識(shí)。 2.1 常用軟件開發(fā)模型的集成方式比較 2.1.1 “瀑布模型”與“ Big-Bang”集成模式 Wton Royce在1970年首先提出了著名的“瀑布模型”，直到20世紀(jì)80年代的初期，這種模型都是被很廣泛的應(yīng)用到各個(gè)軟件開發(fā)過程中的。Wton Royce倡導(dǎo)采用結(jié)構(gòu)化

32、的設(shè)計(jì)方法，將產(chǎn)品功能的實(shí)現(xiàn)和設(shè)計(jì)分開，力求把過程變得簡(jiǎn)單化，同時(shí)也方便開發(fā)人員分工協(xié)作。瀑布模型的整個(gè)過程分為六個(gè)階段：計(jì)劃、需求、設(shè)計(jì)、編譯、測(cè)試和維護(hù)，而且各個(gè)階段是必須按照順序進(jìn)行，就好像瀑布的水流一樣，自頂而下的落下，瀑布模型也是由這個(gè)形象的比喻而得名，圖2-1展示了它的工作方式。 圖2-1 瀑布模型 由上圖可以看出，這種模型設(shè)定了軟件開發(fā)過程中每一項(xiàng)工作都要按照次序進(jìn)行，當(dāng)前的過程要接受上一級(jí)過程的執(zhí)行結(jié)果，完成了本級(jí)的工作后要對(duì)結(jié)果進(jìn)行分析和審核，如果審核通過了，那么就接著進(jìn)行下一級(jí)的過程，不通過則回到初始階段修改瀑布模型。瀑布模型注重軟件開發(fā)的階段性，開始于第一個(gè)階段的計(jì)劃和根

33、據(jù)客戶的需求而做的系統(tǒng)需求分析，最后結(jié)束于對(duì)產(chǎn)品的測(cè)試，雖然瀑布模型很重視測(cè)試階段，但是往往會(huì)出現(xiàn)的問題是當(dāng)項(xiàng)目的測(cè)試結(jié)果交付給客戶時(shí)會(huì)發(fā)現(xiàn)整個(gè)開發(fā)人員在對(duì)客戶的要求有很大的偏差，導(dǎo)致最后的功能雖然實(shí)現(xiàn)了，但是客戶仍然是不滿意的。一般情況，這種系統(tǒng)設(shè)計(jì)問題要到最后測(cè)試階段才能被發(fā)現(xiàn)，增加了項(xiàng)目開發(fā)的風(fēng)險(xiǎn)。出現(xiàn)問題后就會(huì)導(dǎo)致項(xiàng)目不能按期限完成而增加額外的開發(fā)時(shí)間、需要返工或者隨之帶來的費(fèi)用上的增加，最后導(dǎo)致進(jìn)度變緩慢。瀑布模型中系統(tǒng)設(shè)計(jì)和需求說明書存在的問題是很難再開發(fā)項(xiàng)目的初期就被發(fā)現(xiàn)的，只有第一次運(yùn)行集成測(cè)試和驗(yàn)收測(cè)試時(shí)才會(huì)發(fā)現(xiàn)初始的設(shè)計(jì)和需求有問題。瀑布模型雖然有著一些缺點(diǎn)，但是如果軟件項(xiàng)

34、目規(guī)模小、有著很明確的目標(biāo)、需求和功能很簡(jiǎn)單明了，那么采用這種瀑布模型是一個(gè)很不錯(cuò)的選擇。但是對(duì)于現(xiàn)代企業(yè)軟件開發(fā)的復(fù)雜性，它的劣勢(shì)也就凸顯而來了。 通過分析瀑布模型，我們很容易的發(fā)現(xiàn)了它的缺陷和問題： 1. 瀑布模型對(duì)用戶需求的準(zhǔn)確性要求很高，只有做到這一點(diǎn)才能開展后續(xù)階段的工作，但是在實(shí)際開發(fā)中，這幾乎是不可能，也是很難實(shí)現(xiàn)的。 2. 模型的每個(gè)階段擁有很強(qiáng)的依賴性和次序性。只有確保當(dāng)前階段工作的順利完成而且結(jié)果正確才能進(jìn)行下一個(gè)階段的工作，但是如果遇到最后階段出現(xiàn)錯(cuò)誤的話，很可能需要追溯到它之前的許多階段。假如在軟件開發(fā)的后期集成時(shí)發(fā)現(xiàn)問題 ，這樣將要付出很高的代價(jià)來查找問題的根源。 3

35、. 瀑布模型最大的缺陷也就是無法適應(yīng)需求的改變，在開發(fā)中總結(jié)的一些實(shí)踐經(jīng)驗(yàn)無法重新加入到初期的系統(tǒng)需求上 ，這樣就會(huì)帶著風(fēng)險(xiǎn)進(jìn)行后期的開發(fā)，失去了今早糾正隱患的機(jī)會(huì)。 - 5 - 2. 21110233023_徐萌_信息科學(xué)與工程學(xué)院_電子與通信工程_第2部分總字?jǐn)?shù)：10904 文字復(fù)制比：0.6%(67)(0) 瀑布模型在軟件開發(fā)中的應(yīng)用及其局限性 羅孟華;李軍;黃益輝; - 才智- 2009-03-20 0.6% 是否引證：否 原文內(nèi)容 1 13. ConradiR， Fuggetta A Improving software process improvement IEEE Softwa

36、re， 2002， 12(4)：92- 99. 14. 王向陽極限編程研究與應(yīng)用：碩士學(xué)位論文武漢：武漢大學(xué)2004. 正是由于上述的缺陷也把這種集成方式稱為 “Big-Bang”集成方法，它是一種非增量式集成。這種方法規(guī)定開發(fā)人員必須把所有模塊按照需求一次性全部整合起來，然后進(jìn)行整體測(cè)試。然而“Big-Bang”集成方法的缺陷就是，在進(jìn)行集成測(cè)試的時(shí)候可能會(huì)發(fā)現(xiàn)很多的bug，每個(gè)bug的定位和改正非常困難，很容易產(chǎn)生混亂狀態(tài)，并且在改正一個(gè)錯(cuò)誤的同時(shí)還有可能會(huì)引入其他新的錯(cuò)誤。在小型應(yīng)用系統(tǒng)中，整個(gè)軟件系統(tǒng)由不太多的單元模塊組成，它可能就是一種比較好的方法，但是隨著軟件行業(yè)日漸蓬勃發(fā)展，規(guī)模

37、也越來越大，大部分的情況都是開發(fā)比較復(fù)雜的軟件，這時(shí)，就需要我們尋找其他更好的集成方式。2.1.2 Rational統(tǒng)一過程與“迭代遞增”集成模式 Rational統(tǒng)一過程(Rational Unified Process，簡(jiǎn)稱RUP)是由Rational軟件公司（現(xiàn)在Rational已經(jīng)被IBM并購）創(chuàng)造的開發(fā)模型，它定義了產(chǎn)品開發(fā)的每一個(gè)過程都可以被認(rèn)為是一個(gè)完整的迭代，而每一次迭代之后就會(huì)產(chǎn)生一個(gè)穩(wěn)定、可執(zhí)行發(fā)布的版本，這個(gè)過程中包括涉及版本的所有活動(dòng)包括其周邊因素。一個(gè)迭代過程分為：確定產(chǎn)品需求、系統(tǒng)分析設(shè)計(jì)、測(cè)試和實(shí)施的流程。RUP還認(rèn)為每次迭代產(chǎn)生的版本都是該產(chǎn)品最終版本的其中一個(gè)

38、子集，也是最終產(chǎn)品所有功能中的一部分。按照RUP的設(shè)計(jì)方法，一個(gè)大型項(xiàng)目的開發(fā)過程就會(huì)有很多次的迭代過程，而且每一次只需要考慮整個(gè)項(xiàng)目中的一部分需求，并建立在前一次已經(jīng)成功迭代的基礎(chǔ)上進(jìn)行，只對(duì)當(dāng)前的過程進(jìn)行分析、設(shè)計(jì)、測(cè)試和實(shí)施等工作。RUP就是用這種變迭發(fā)的方法來進(jìn)行，這樣每次迭代都可以對(duì)原有功能進(jìn)行一部分的更新和增加，照這種迭代遞增方式進(jìn)行下去，最后一次成功的迭代也就意味著最終版本的產(chǎn)生。 其流程如圖2-2所示： 圖2-2 RUP示意圖 RUP 的軟件開發(fā)過程在時(shí)間上被分為四個(gè)順序的階段，分別是：Inception （初始階段）、 Elaboration（細(xì)化階段） 、 Construc

39、tion（構(gòu)造階段）和Transition（交付階段）。Steve McConnell這樣形容道：“這些階段就好像是從雪山頂上開始滾雪球，雪球會(huì)越來越大”，因此把這種集成方法稱之為“迭代遞增”集成方式。 相比于“Big-Bang”集成模式，“迭代遞增”集成軟件設(shè)計(jì)靈活檢驗(yàn)、修改方便，還提供了可以提早采取預(yù)防措施的機(jī)會(huì)，很大程度上增加了項(xiàng)目的成功率，有助于均衡整個(gè)開發(fā)過程的負(fù)荷，流程可在迭代過程中得到改進(jìn)和精煉，能夠更加容易的確定bug的位置。并且允許代碼的變更、隨時(shí)能夠優(yōu)化系統(tǒng)的需求，然后通過向業(yè)務(wù)人員展示迭代后系統(tǒng)產(chǎn)生的新功能，開發(fā)人員可以很快的從業(yè)務(wù)部門搜集對(duì)于本產(chǎn)品的反饋，盡早的修正之前

40、對(duì)需求理解的偏差，以確保最終的產(chǎn)品版本能夠滿足客戶的要求和目標(biāo)。其次這種迭代遞增可以逐步集成。在傳統(tǒng)的集成過程中，一般會(huì)要求一次性集成系統(tǒng)中所有的模塊，項(xiàng)目越復(fù)雜集成工作就會(huì)占到整個(gè)項(xiàng)目開發(fā)中的越大比例，有時(shí)會(huì)達(dá)到40%左右。 在迭代模型中集成是不間斷的，系統(tǒng)功能也是每集成一次增加一部分，因此每次的工作量和難度相對(duì)來講也都是比較低的。因此，這種方式不僅可以盡早降低項(xiàng)目風(fēng)險(xiǎn)還可以增加開發(fā)團(tuán)隊(duì)的熱情，因?yàn)樗麄兠刻於伎梢钥吹侥軌蛘９ぷ鞯南到y(tǒng)，從而設(shè)計(jì)出質(zhì)量更高的產(chǎn)品。每次迭能上的瓶頸。 成的新版本產(chǎn)品都可以進(jìn)行測(cè)試，企業(yè)也就可以在測(cè)試結(jié)果中及早的發(fā)現(xiàn)缺陷并改正性如果在新一次的迭代中出現(xiàn)問題，那么意

41、味著這個(gè)錯(cuò)誤一定是出現(xiàn)在新功能的模塊上或者是新代碼和原有代碼的接口上 ，這樣一來bug也就更容易定位，可以準(zhǔn)確的知道應(yīng)該到哪里查找錯(cuò)誤的根源。具體來說，每一次迭代的問題都會(huì)是少量的、不會(huì)是多個(gè)問題的相互作用，而且在接口上產(chǎn)生的問題越多，迭代遞增模式的優(yōu)越性越明顯，減少開發(fā)人員用在調(diào)試上的時(shí)間和精力，可以很大程度上提高開發(fā)效率。 由此可見，“迭代遞增”集成方式有諸多的有點(diǎn)，但是在實(shí)踐的時(shí)候會(huì)經(jīng)常遇到兩個(gè)典型的誤區(qū)：“迭而不增”與“增而不迭”。“迭而不增”就是每次毫無效率的簡(jiǎn)單重復(fù)的迭代，而“增而不迭”又回歸到類似瀑布模型的集成方式，如圖2-3所示。 圖2-3 “迭而不增”和“增而不迭”模式 這是

42、因?yàn)椤暗f增”集成模式并不能量化每次迭代之間的時(shí)間間隔，更不可能量化新一次迭代的工作量，因而經(jīng)常會(huì)造成迭代版本之間并沒有新功能的增加或者很長一段時(shí)間不進(jìn)行新功能模塊的集成測(cè)試這兩個(gè)問題。 微軟公司就建立了一個(gè)新的集成方式（每日構(gòu)建），可以避免出現(xiàn)以上的兩個(gè)問題，是在集成領(lǐng)域的又一大突破和創(chuàng)新。2.1.3 微軟過程模型與“每日構(gòu)建”集成模式 微軟過程模型 (Microsoft Solution Framework, MSF)是由世界上最著名的軟件公司微軟公司建立的，它是基于自身的企業(yè)軟件開發(fā)實(shí)踐設(shè)計(jì)的一個(gè)準(zhǔn)則。微軟公司作為計(jì)算機(jī)軟件的領(lǐng)導(dǎo)者，成立近四十年以來開發(fā)了Windows操作系統(tǒng)等眾多軟

43、件 ，微軟把MSF應(yīng)用到了所有的軟件產(chǎn)品從最初的產(chǎn)品需求分析和策劃到試用版發(fā)行最后到正式版本發(fā)布，微軟的成功也證明了微軟過程模型的成功。微軟過程模型是一種遞進(jìn)式的、階段性的軟件開發(fā)模型，從“生命周期”來看，MSF分為分析、計(jì)劃、開發(fā)、穩(wěn)定和發(fā)布五個(gè)階段，每一個(gè)階段均涉及到了產(chǎn)品管理、程序編譯、測(cè)試、發(fā)布等活動(dòng)，各個(gè)階段的結(jié)束都意味著一個(gè)里程碑式的進(jìn)步。 微軟過程模型與RUP相似，是以“迭發(fā)”為主題，系統(tǒng)設(shè)計(jì)、文檔、計(jì)劃、代碼和其他的活動(dòng)成果都是以迭代形式出現(xiàn)。MSF的主要思想是以建立核心功能為出發(fā)點(diǎn)，然后其他的小功能逐漸后續(xù)被加入，這也就是MSF的發(fā)布策略。一般情況，對(duì)一個(gè)小型的軟件產(chǎn)品，只需

44、要一個(gè)版本，但是微軟公司建議把這個(gè)產(chǎn)品仍然分成很多個(gè)版本，這樣可以在開發(fā)的過程中找到改進(jìn)的機(jī)會(huì)，而且版本的發(fā)布也不需要按照順序進(jìn)行，多個(gè)版本中間可以有重疊，發(fā)布周期也是隨時(shí)根據(jù)項(xiàng)目的類型、規(guī)模、策略和客戶需求的不同而不同。MSF 模型采用的這種遞進(jìn)式的版本發(fā)布策略要求開發(fā)小組在每一次的迭代過程中保證有新的功能 出現(xiàn)，這樣就會(huì)高效的提高產(chǎn)品的質(zhì)量而且也便于項(xiàng)目管理者了解產(chǎn)品開發(fā)過程并能隨時(shí)調(diào)整開發(fā)的方向。 微軟過程模型也是因?yàn)樗募煞绞蕉雒?，那就是每日?gòu)建(Daily Build)，從字面意思便可以知道，它是要求每天自動(dòng)地、完整地構(gòu)建整個(gè)代碼庫，這樣也就解決上面提到的“迭代遞增”中的兩個(gè)誤區(qū)

45、，原因是每日構(gòu)建很明確的規(guī)定了兩次迭代的時(shí)間間隔為一天、每天的工作量作為迭代之間的增量，這樣同時(shí)也解決了“Big-Bang”模式的缺陷，還優(yōu)化了“迭代遞增”的優(yōu)勢(shì)。 2.2 敏捷軟件開發(fā)模型與持續(xù)集成模式 盡管微軟過程模型有很多優(yōu)點(diǎn)，但是隨著經(jīng)濟(jì)全球化的進(jìn)行帶動(dòng)著軟件業(yè)也飛速的發(fā)展，軟件開發(fā)也有了更多的需求和特點(diǎn)，那就是能夠在開發(fā)過程中快速高效的進(jìn)行，在這種情形下出現(xiàn)了一些新的軟件開發(fā)模式，敏捷軟件開發(fā)模型(Agile Methodologies)就是其中的一個(gè)典型例子。敏捷開發(fā)是一種替代傳統(tǒng)的項(xiàng)目管理和瀑布模型的軟件開發(fā)方式，它可以通過增加迭代工作的節(jié)奏，以一種沖刺式的過程來幫助開發(fā)團(tuán)隊(duì)?wèi)?yīng)對(duì)

46、開發(fā)的不可預(yù)測(cè)性。敏捷開發(fā)方法提供了一個(gè)評(píng)估整個(gè)開發(fā)生命周期方向的機(jī)會(huì)，包括每一個(gè)環(huán)節(jié)的要求、設(shè)計(jì)、測(cè)試的實(shí)施，這種方式極大地降低了開發(fā)成本并能夠縮短上市時(shí)間，因?yàn)樗麄冊(cè)陂_發(fā)的同時(shí)集成測(cè)試也在發(fā)生。面對(duì)開發(fā)過程中需求的變化，敏捷開發(fā)方法的策略是盡量減少變動(dòng)，下面是它的一些實(shí)踐方法： 1. 爭(zhēng)取在第一到第三周就發(fā)布產(chǎn)品的第一個(gè)版本，以獲得第一時(shí)間的反饋結(jié)果。2. 應(yīng)用最簡(jiǎn)單的解決方案，這樣有助于日后的修改。 3. 不斷地改進(jìn)設(shè)計(jì)以增加產(chǎn)品的功能，提高設(shè)計(jì)的質(zhì)量。 4. 持續(xù)地集成，不停地進(jìn)行產(chǎn)品測(cè)試，以便減少開發(fā)后期集成測(cè)試和修改的代價(jià)。5. 邀請(qǐng)用戶參與軟件的全過程，并在其中起著重要的作用。

47、敏捷開發(fā)中的其中一個(gè)成功實(shí)踐就是持續(xù)集成，開發(fā)團(tuán)隊(duì)經(jīng)常集成他們的工作，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。其流程如圖2- 4所示，開發(fā)人員每一次遷入新代碼，持續(xù)集成模塊都會(huì)自動(dòng)從源碼管理器獲得最新源碼，然后順序執(zhí)行之前規(guī)定的任務(wù)，先是編譯，成功了則進(jìn)行單元測(cè)試，接下來進(jìn)行代碼檢查，只要哪一步失敗了則終止過程。最后不管能否順利進(jìn)行整個(gè)集成過程 ，與項(xiàng)目相關(guān)的工作人員都可以到DashiBoard集成報(bào)告服務(wù)器查看分析結(jié)果和詳細(xì)信息，同時(shí)也會(huì)收到電子郵件的相關(guān)消息。圖2-4 持續(xù)集成示意圖 從上圖不難看出持續(xù)集成在本質(zhì)上和每日構(gòu)建是相似的，但是仔細(xì)分析就會(huì)發(fā)現(xiàn)他們?cè)陬l率和對(duì)結(jié)果的反饋上還是有一些差異的： 1.

48、持續(xù)集成的集成頻率比每日構(gòu)建要頻繁，現(xiàn)在普遍應(yīng)用的持續(xù)集成系統(tǒng)一般就是過幾小時(shí)就集成幾次，這樣每天都會(huì)進(jìn)行多次，但是具體還要視實(shí)際情況來定。 2. 持續(xù)集成的目的是為了得到第一時(shí)間的反饋，而每日構(gòu)建是以得到一個(gè)穩(wěn)定發(fā)布的版本為目的，但是在開發(fā)人員修復(fù)過導(dǎo)致持續(xù)集成失敗的bug之后也會(huì)得到一個(gè)成功的版本。 3. 持續(xù)集成非常鼓勵(lì)開發(fā)人員盡快提交變更，每日構(gòu)建則沒有。2.3 本章小結(jié) 比較了常用軟件開發(fā)模型與集成方式：瀑布模型與“Big-Bang”集成方式，RUP與“迭代遞增”方式，以及MSF和“每日構(gòu)建”模式，然后提出了最流行的現(xiàn)代敏捷軟件開發(fā)與持續(xù)集成的優(yōu)勢(shì)，并比較了持續(xù)集成與每日構(gòu)建的區(qū)別。

49、 3 持續(xù)集成研究與價(jià)值3.1 持續(xù)集成概述 持續(xù)集成(Continuous Integration)一詞來源于極限編程(Extreme Programming)，是一種十分重要的工程實(shí)踐過程。著名的軟件開發(fā)領(lǐng)域大師Martin Fowler，同時(shí)也是Thoughtworks首席科學(xué)家發(fā)在他發(fā)表的一篇著名的文章Continuous Integration中對(duì)持續(xù)集成進(jìn)行了定義并倡導(dǎo)各大軟件公司開始實(shí)施持續(xù)集成應(yīng)用實(shí)踐。在軟件產(chǎn)品的開發(fā)過程中，一個(gè)項(xiàng)目會(huì)被劃分為很多的模塊，而各個(gè)模塊是由很多的開發(fā)人員分別對(duì)其進(jìn)行編譯，在所有模塊都編寫成功后集成到一起進(jìn)行整合測(cè)試，這也就是比較傳統(tǒng)和常用的開發(fā)方式

50、。但是這種集成模式有很多潛在的問題和風(fēng)險(xiǎn)：比較典型的就是當(dāng)開發(fā)人員對(duì)各自模塊運(yùn)行無錯(cuò)誤、無缺陷之后集成到一起會(huì)出現(xiàn)很多問題，而此時(shí)必然是已經(jīng)接近軟件開發(fā)的后期，留下可以排查bug的時(shí)間不會(huì)很充裕，定位錯(cuò)誤的根源更是難上加難，則會(huì)造成開發(fā)停滯不前，軟件開發(fā)可能會(huì)面臨失敗，帶來巨大的損失和影響。持續(xù)集成則是完全自動(dòng)化的過程，它代替了原來的人工手動(dòng)操作，包括下載代碼、執(zhí)行測(cè)試用例、分析測(cè)試結(jié)果等，它使得一天中集成多次成為可能，幾個(gè)小時(shí)就可以提交多次，同時(shí)確保每一次地操作都不會(huì)破壞原有的構(gòu)建。這種方式可以將每次代碼的更新快速的反饋給開發(fā)團(tuán)隊(duì)，能夠使問題在最早的時(shí)候發(fā)現(xiàn)并留給開發(fā)人員充足的時(shí)間解決，而且

51、每一輪變更后出現(xiàn)的bug僅僅是由最新一次的更新帶來的，問題會(huì)比較容易定位和改善，很大程度上提高了軟件開發(fā)的效率， 緩解了測(cè)試工作帶來的繁重的工作負(fù)擔(dān)。 持續(xù)集成的出現(xiàn)在使得軟件集成問題的解決方法得到了很大程度的進(jìn)步，越來越多的開發(fā)人員慢慢的開始關(guān)注持續(xù)集成 ，通過各種成功的實(shí)踐也證明了持續(xù)集成能夠滿足軟件開發(fā)人員的需求。為了提升持續(xù)集成的技術(shù)水平，也使持續(xù)集成在軟件開發(fā)行業(yè)得到更為廣泛的使用，對(duì)持續(xù)集成實(shí)踐的研究和應(yīng)用都有著特別重要的現(xiàn)實(shí)意義。 一般情況，持續(xù)集成有著幾下幾個(gè)原則： 1. 設(shè)立一個(gè)版本管理軟件來保證開發(fā)人員提交的代碼能夠順利的進(jìn)行構(gòu)建集成，比較常見的版本控制軟件有Subvers

52、ion、CVS 、IBM Rational Clear Case等。 - 7 - 2. 能夠確保版本控制庫定期會(huì)有更新，這就需要開發(fā)者及時(shí)提交代碼，而且開發(fā)人員也必須定期地從源碼庫中更新代碼到本地。 3. 要有一個(gè)專門的CI服務(wù)器作為設(shè)備保障，因?yàn)樗浅掷m(xù)集成的“大腦”用來執(zhí)行各種構(gòu)建工作的核心。它的工作啟動(dòng)方式既可以通過變更來觸發(fā)，也可以根據(jù)實(shí)際情況來設(shè)計(jì)定時(shí)啟動(dòng)的周期，比如可以半個(gè)小時(shí)執(zhí)行一次構(gòu)建。 4. 必須確保每一次集成構(gòu)建最后都能成功。如果出現(xiàn)構(gòu)建失敗了，需要馬上查找發(fā)生的問題和bug的根源，修復(fù)完成之后要再次啟動(dòng)構(gòu)建，直到成功的集成所有的代碼為止。 3.2 持續(xù)集成系統(tǒng)的工作方式

53、上面已經(jīng)簡(jiǎn)單的介紹了持續(xù)集成的一些概念和流程，下面具體說明一下持續(xù)集成是怎樣工作的：負(fù)責(zé)各自模塊開發(fā)的人員把各自本地編譯的新代碼提交到版本庫，就會(huì)觸發(fā)到服務(wù)器開始工作，首先版本控制軟件會(huì)自動(dòng)更新代碼庫中的代碼，然后把更新后的所有代碼提取到另外的一個(gè)空目錄中自動(dòng)運(yùn)行規(guī)定的測(cè)試用例，在一些版本控制工具中，也有分成不同的分支空間在進(jìn)行測(cè)試的。如果測(cè)試成功則接受這次提交，成為一個(gè)新的版本，否則反饋給開發(fā)團(tuán)隊(duì)，這是一個(gè)失敗的版本。 持續(xù)集成最重要的就是能夠完成徹底的自動(dòng)化和頻繁的更新，因此需要采用持續(xù)集成服務(wù)器軟件來實(shí)現(xiàn)，也就是像一個(gè)定時(shí)調(diào)度器，它會(huì)監(jiān)視著代碼庫中的所有代碼，類似一個(gè)監(jiān)視器來檢查代碼的狀

54、態(tài)，觀察是否有更新，每當(dāng)發(fā)現(xiàn)原有的代碼庫發(fā)生了變化，持續(xù)集成服務(wù)器就會(huì)自動(dòng)地運(yùn)行編譯和所有的集成測(cè)試，然后還會(huì)記錄并制作成分析報(bào)告反饋給開發(fā)的人員，便于對(duì)整個(gè)代碼情況的了解。圖3-1就是持續(xù)集成工作機(jī)制原理圖： 圖3-1持續(xù)集成工作機(jī)制原理圖 由這幅圖可以看出，持續(xù)集成工作是從“心跳檢測(cè)”開始的，如果到了設(shè)置好的輪詢時(shí)間檢測(cè)版本管理器就會(huì)判斷源碼是否發(fā)生了變化，無變化則繼續(xù)等待下一次輪詢，有變化的話則更新源碼到本地服務(wù)器然后執(zhí)行構(gòu)建（包括編譯、靜態(tài)檢查、執(zhí)行單元測(cè)試、打包、測(cè)試部署等步驟），最后在網(wǎng)頁顯示出本次構(gòu)建的結(jié)果，以郵件方式發(fā)送構(gòu)建結(jié)果個(gè)工作機(jī)制。這樣每個(gè)開發(fā)人員都會(huì)很清楚的知道了軟件

55、開發(fā)的狀況。 3.3 持續(xù)集成的價(jià)值 ，然后循環(huán)往復(fù)這Mckey and Company（麥肯錫咨詢公司）的一項(xiàng)調(diào)查研究總結(jié)了一則規(guī)律：一個(gè)好的軟件開發(fā)流程可以在很大程度上提高企業(yè)的產(chǎn)品生產(chǎn)效率，相反，一個(gè)壞的開發(fā)流程甚至能搞垮一家公司。在調(diào)查中發(fā)現(xiàn)，發(fā)展較好較快的軟件公司中 94%都在應(yīng)用持續(xù)集成實(shí)踐，而做的不是很好的公司則沒有或者很少應(yīng)用持續(xù)集成的構(gòu)建。美國微軟公司的軟件部門經(jīng)理也指出：持續(xù)集成就是軟件項(xiàng)目存活的“心跳”，心跳如果停止，那么意味著軟件開發(fā)項(xiàng)目也就馬上面臨死亡。由以上兩個(gè)例子可以看出持續(xù)集成對(duì)于現(xiàn)代企業(yè)軟件開發(fā)的發(fā)展有著非常重大的價(jià)值和意義。下面對(duì)持續(xù)集成的價(jià)值總結(jié)如下： 1

56、. 最大程度降低軟件開發(fā)過程中的風(fēng)險(xiǎn) 一個(gè)大型的軟件項(xiàng)目會(huì)由很多個(gè)研發(fā)團(tuán)隊(duì)分工合作，這樣一個(gè)項(xiàng)目就會(huì)分成很多細(xì)小的模塊進(jìn)行分別各自開發(fā)，最后他們把各自的代碼組合起來并進(jìn)行集成測(cè)試，但是基本上得到的結(jié)果都是有錯(cuò)誤的，項(xiàng)目越復(fù)雜錯(cuò)誤可能也會(huì)越多，這會(huì)浪費(fèi)很多的時(shí)間用來調(diào)試和修改，而bug的根源會(huì)在此時(shí)由于軟件的復(fù)雜性而很難找到和定位。如果采用持續(xù)集成這種每天進(jìn)行多次集成的方法并同時(shí)進(jìn)行測(cè)試和分析就有助于今早的檢查缺陷，隨時(shí)了解軟件的健康狀況，減少最后時(shí)刻的大問題，最大程度的降低開發(fā)的風(fēng)險(xiǎn)，也能減少隱患的存在。 2. 減少人工的重復(fù)工作 自動(dòng)化的持續(xù)集成過程可以把重復(fù)的、大量的人力工作讓機(jī)器去實(shí)現(xiàn)，這樣就不用花費(fèi)很多的人工費(fèi)用，也能夠節(jié)省花在測(cè)試上的時(shí)間和工作量，能讓開發(fā)人員更關(guān)注開發(fā)過程中更迫切需要解決和更有價(jià)值的事情上。 3. 隨時(shí)可生成發(fā)布的軟件 持續(xù)集成最顯著的特點(diǎn)就是它可以允許隨時(shí)發(fā)布可發(fā)布的軟件，如果不進(jìn)行持續(xù)集成我們理論上認(rèn)為軟件產(chǎn)品的質(zhì)量是可靠的而且沒有風(fēng)險(xiǎn)，但是并沒有依據(jù)和證明，而客戶最認(rèn)可的則是可以發(fā)布的實(shí)際的產(chǎn)品。持續(xù)集成還能對(duì)這些軟件進(jìn)行進(jìn)一步的更新和改動(dòng)，然后將這些變更和原有的代碼進(jìn)行集成，如果不能順利集成，出現(xiàn)的問題也會(huì)馬上反饋給開發(fā)者并盡快的得到分析和修復(fù)方法