持續集成理論和實(shí)踐的新進(jìn)展

　　最近雷鎮同學(xué)將Martin Fowler先生的著(zhù)名論文《持續集成》第二版翻譯成中文并發(fā)布出來(lái)，掀起了國內對于持續集成理論和實(shí)踐討論的新的高潮。筆者在本文中將全面對比持續集成論文前后兩版的異同，分析并展示ThoughtWorks在持續集成領(lǐng)域的理論和實(shí)踐方面的研究成果，以圖對國內企業(yè)實(shí)施持續集成起到參考和借鑒作用。需要說(shuō)明的是，本文所介紹的內容畢竟限于筆者的水平，并且主要是ThoughtWorks內部開(kāi)發(fā)和對外咨詢(xún)實(shí)踐的總結，所以未必對讀者所遇到的情況是適用的，請自行甄別。

　　《持續集成》第二版雖然是最近才翻譯出來(lái)，但是實(shí)際上Martin Fowler先生完成此文是在5年前的事情。這五年恰好是ThoughtWorks中國公司快速成長(cháng)的五年。在這五年內ThoughtWorks中國在持續集成領(lǐng)域也有很多的發(fā)展，這包括：著(zhù)名的持續集成工具Cruise主要是由中國公司負責開(kāi)發(fā)1; 中國公司幫助國內很多大中型企業(yè)完成持續集成實(shí)施和相關(guān)的流程改進(jìn);2009年中國公司的很多同事對于持續集成的度量進(jìn)行了深入的討論并且最終由胡凱將其實(shí)現為一款軟件iAnalysis;2010年至2011年成功的交付了從需求提供方到多個(gè)技術(shù)服務(wù)提供商的持續集成方案，以及企業(yè)級自動(dòng)化中心方案。所以，本文主要包括兩部分內容，一部分是通過(guò)對比第一版與第二版的異同介紹2000年到2006年之間持續集成領(lǐng)域的主要發(fā)展，另一部分則是介紹第二版發(fā)表之后持續集成領(lǐng)域的新進(jìn)展。讀者如果之前沒(méi)有閱讀過(guò)《持續集成》論文的第二版，建議將本文第一部分一同閱讀，因為本文并非對論文的重述，所以很多地方還需要參考原文中的內容。

　　第一部分 《持續集成》第一版與第二版

　　《持續集成》第一版由ThoughtWorks首席科學(xué)家Martin Fowler先生和Matthew Foemmel共同完成2，第二版由Martin Fowler先生更新。

　　《持續集成》的第一版中并沒(méi)有給出比較正式的定義，雖然作者在文中說(shuō)是借鑒了XP實(shí)踐中的術(shù)語(yǔ)，但是目前能看到的XP實(shí)踐中對持續集成的定義實(shí)際上大多數都是指向了Martin的文章。那么我們還是來(lái)看看第二版中給出的定義。

　　持續集成是一種軟件開(kāi)發(fā)實(shí)踐。在持續集成中，團隊成員頻繁集成他們的工作成果，一般每人每天至少集成一次，也可以多次。每次集成會(huì )經(jīng)過(guò)自動(dòng)構建(包括自動(dòng)測試)的驗證，以盡快發(fā)現集成錯誤。許多團隊發(fā)現這種方法可以顯著(zhù)減少集成引起的問(wèn)題，并可以加快團隊合作軟件開(kāi)發(fā)的速度。3

　　第二版相對于第一版增加了不少內容，其中最重要的幾點(diǎn)包括：

　　詳細介紹了使用持續集成進(jìn)行軟件開(kāi)發(fā)的工作流程。

　　突出了配置管理在持續集成實(shí)踐中的作用。

　　提出分階段構建的概念。

　　增加了持續集成報告的內容。

　　增加了持續部署的內容。

　　給出了引入持續集成的建議。

　　持續集成的流程

　　在持續集成領(lǐng)域，我們經(jīng)常會(huì )用到的一個(gè)術(shù)語(yǔ)就是“構建(Build)”。很多人認為“構建=編譯+鏈接(Build=Compile+Link)”，Martin在第一版中指出一次成功構建包括：

　　所有最新代碼從配置管理工具中取出(check out或者update)。

　　所有的代碼從干凈的狀態(tài)開(kāi)始編譯。

　　將編譯結果鏈接并部署，以備執行。

　　執行部署的應用并運行測試套。

　　如果上述所有操作沒(méi)有任何錯誤，沒(méi)有人工干預，并通過(guò)了所有測試，我們認為這才是一次成功的構建。

　　實(shí)際上，目前很多團隊對成功持續集成構建的定義基本上是符合上述定義的。這個(gè)定義的特點(diǎn)在于它是相對獨立的，它是一個(gè)從干凈狀態(tài)的源代碼最終獲得可運行的通過(guò)驗證的軟件的過(guò)程。

　　Martin在第二版中則在成功構建的基礎上給出了成功集成的定義。成功集成關(guān)注的不是一次“編譯+鏈接+部署+驗證”的過(guò)程，而是從開(kāi)發(fā)流程的角度介紹一次完整的在持續集成約束下的代碼提交過(guò)程4：

　　將已集成的源代碼復制一份到本地計算機。

　　修改產(chǎn)品代碼和添加修改自動(dòng)化測試。

　　在自己的計算機上啟動(dòng)一個(gè)自動(dòng)化構建。

　　構建成功后，把別人的修改更新到我的工作拷貝中。

　　再重新做構建。

　　把修改提交到源碼倉庫。

　　在集成計算機上并基于主線(xiàn)的代碼再做一次構建。

　　只有這次構建成功了，才說(shuō)明改動(dòng)被成功的集成了。

　　下圖展示了Martin對成功集成的定義：

　　配置管理

　　Martin在第一版中有兩處提及配置管理，分別是：?jiǎn)我淮a源(Single Source Point)和代碼提交(Checking In)。第二版中則包括：通過(guò)持續集成構建特性(Building a Feature with Continuous Integration)、只維護一個(gè)代碼倉庫(Maintain a Single Source Repository)、每人每天都要向主線(xiàn)提交代碼(Everyone Commits To The Mainline Every day)、每次提交都應在集成計算機上重新構建主線(xiàn)(Every Commit Should Build the Mainline on an Integration Machine)。不僅條目數量上增加明顯，作者提出的很多實(shí)踐都是基于配置管理來(lái)講的。

　　工具

　　配置管理是持續集成的輸入。在第一版中作者所推薦的配置管理工具是CVS，到第二版中作者推薦的配置管理工具已經(jīng)換成了SVN5(參見(jiàn)第二部分中的配置管理工具部分)。

　　分支策略

　　實(shí)現進(jìn)度與質(zhì)量的平衡是配置管理的重要目的。Martin在第二版中對濫用分支給出了警告：

　　盡量減少分支數量。典型的情況是保持一條主線(xiàn)，......，每個(gè)人都從這條主線(xiàn)開(kāi)始自己的工作。(對之前發(fā)布版本進(jìn)行Bug修正或者臨時(shí)性的實(shí)驗都是創(chuàng )建分支的正當理由。)

　　但是這里給出的建議對于大型團隊來(lái)說(shuō)并不十分合適。我們將在第二部分對于配置管理的分支策略進(jìn)行詳細描述。

　　內容

　　Martin在第一版中給出的原則是：

　　任何人都可以找到一臺干凈的機器，連上網(wǎng)，通過(guò)一個(gè)命令就可以取得要構建所開(kāi)發(fā)的系統需要的所有源文件。

原文轉自：http://kb.cnblogs.com/page/109735/