持續集成理論和實踐的新進展

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

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

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

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

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

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

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

　　詳細介紹了使用持續集成進行軟件開發的工作流程。

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

　　提出分階段構建的概念。

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

　　增加了持續部署的內容。

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

　　持續集成的流程

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

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

　　所有的代碼從干凈的狀態開始編譯。

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

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

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

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

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

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

　　修改產品代碼和添加修改自動化測試。

　　在自己的計算機上啟動一個自動化構建。

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

　　再重新做構建。

　　把修改提交到源碼倉庫。

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

　　只有這次構建成功了，才說明改動被成功的集成了。

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

　　配置管理

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

　　工具

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

　　分支策略

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

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

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

　　內容

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

　　任何人都可以找到一臺干凈的機器，連上網，通過一個命令就可以取得要構建所開發的系統需要的所有源文件。

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