使用SVN+CruiseControl+ANT實現(xiàn)持續(xù)集成
自己當時所在團隊的處境(使用.NET開發(fā))，一個不到十個人的研發(fā)團隊在保證正常開發(fā)進度同時需要并發(fā)支持四、五十個項目問題處理，經(jīng)常為了程序版本沖突、日常測試版本、發(fā)布版本提供等重復(fù)枯燥無味的手工勞動，導(dǎo)致團隊成員身心俱疲。經(jīng)歷這樣痛苦的一段時間，終于忍受不了，通過命令行實現(xiàn)了包括獲取、編譯、發(fā)布過程的集成，大大減輕版本編譯的時間，此時還能見到團隊成員一邊編譯程序一邊聊天輕松的笑臉，這就堅定了自己持續(xù)集成的做法，不過可笑是當時自己對持續(xù)集成沒有任何的概念，只是當時的狀況逼自己走了集成之路。
這個工具在經(jīng)歷半年使用進行了一次升級，提供了更多的選項功能，參見升級版本介紹。另外隨著公司業(yè)務(wù)的發(fā)展，2009年自己負責推出一個基于JAVA的產(chǎn)品平臺，這個平臺中包括了七八個子系統(tǒng)。一個困難就出現(xiàn)在我們面前，為了保持以前每周一次發(fā)版，每次編譯發(fā)布都需要兩三個小時，為了擺脫這種困局找了很多資料，學(xué)習(xí)了很多新的思想，對比了很多工具，最終使用了基于CruiseControl(以下簡稱CC)實現(xiàn)持續(xù)集成。
1. 持續(xù)集成概念
對于持續(xù)集成（Continuous Integration）這個術(shù)語源自 XP（極限編程）的一個最佳實踐，隨著XP近幾年的推廣持續(xù)集成被大家認可并實踐，但持續(xù)集成并非 XP 的專利，持續(xù)集成完全可以應(yīng)用在采取非XP 方法的項目里面。持續(xù)集成也不是一個新的概念，在這個術(shù)語出現(xiàn)之前，日創(chuàng)建（daily build）提供同樣的含義，這個典型的代表就是微軟，他們每天的工作都開始于每日零點的版本構(gòu)建。持續(xù)集成和日創(chuàng)建主要區(qū)別就在于實施的頻率上，隨著 XP 社區(qū)的大師級人物 Martin Fowler等人所著《Continuous Integration》為其正名，持續(xù)集成這個術(shù)語就越來越多地出現(xiàn)在原來日創(chuàng)建出現(xiàn)的位置。
2. 持續(xù)集成優(yōu)點
在傳統(tǒng)開發(fā)模式中項目按照模塊進行劃分，等開發(fā)完成后再集成到一起進行測試，這種開發(fā)方法在小規(guī)模程序開發(fā)過程中并沒有太大的不足。但隨著軟件技術(shù)的發(fā)展，軟件規(guī)模也在擴大，軟件需求越來越復(fù)雜，軟件已經(jīng)不能簡單地通過劃分模塊方式來開發(fā)，因為很多Bug在項目早期就存在了，如果在最后集成的時候才發(fā)現(xiàn)問題，開發(fā)者需要在集成階段花費大量的時間來尋找Bug，由于軟件的復(fù)雜性，需要花費大量的時間進行定位，甚至有些需要調(diào)整底層架構(gòu)。在這個階段的除蟲會議（bug meetings）特別多，會議的內(nèi)容基本上都是討論 bug 是怎么產(chǎn)生的，最后往往發(fā)展成為不同模塊的負責人互相推諉責任。
持續(xù)集成最大的優(yōu)點是可以避免這種傳統(tǒng)模式在集成階段的除蟲會議。持續(xù)集成主張項目的開發(fā)人員頻繁的將他們對源碼的修改提交(check in)到一個單一的源碼庫，并 驗證這些改變是否對項目帶來了破壞，持續(xù)集成包括以下幾大要點：
訪問單一源碼庫，將所有的源代碼保存在單一的地點（源碼控制系統(tǒng)）， 讓所有人都能從這里獲取最新的源代碼，提倡開發(fā)人員頻繁提交修改過的代碼。
支持自動化創(chuàng)建腳本，使創(chuàng)建過程完全自動化，讓任何人都可以只輸入一條命令或者幾次點擊就完成系統(tǒng)的創(chuàng)建。
測試完全自動化，要求開發(fā)人員提供自測試的代碼，讓任何人都可以只輸入一條命令或者幾次點擊就運行一套完整的系統(tǒng)測試。
支持自動化部署，能夠按照不同的要求發(fā)布到測試、發(fā)布服務(wù)器，提供測試環(huán)境和發(fā)布程序包；
自動提供集成信息，按照不同情況提供通過郵件、報告等方式提供每次集成結(jié)果，并且提供發(fā)布平臺大家能輕易看到集成的進度和結(jié)果
持續(xù)集成的關(guān)鍵是完全的自動化，自動讀取源代碼、編譯、測試、部署、信息發(fā)布。對于每次成功的創(chuàng)建，要求在這個自動化過程中的每一步都不能出錯，而最重要的一步是測試，只有最后通過測試的創(chuàng)建才是成功的創(chuàng)建。
在持續(xù)集成里面創(chuàng)建不再只是傳統(tǒng)的編譯那么簡單，創(chuàng)建還應(yīng)該包括自測試，自測試的代碼是開發(fā)人員提交源碼的時候同時提交的，是針對源碼的單元測試，將所有的這些自測試代碼整合到一起形成測試集，在所有的最新的源碼通過編譯之后還必須通過測試集的測試才算是成功的創(chuàng)建。這種測試的主要目的是為了驗證創(chuàng)建的正確性，McConnell 稱之為“冒煙測試”，在持續(xù)集成里面，這叫做集成驗收測試Build Verify Test，簡稱 BVT。BVT 測試是質(zhì)量的基礎(chǔ)，QA 小組不會感受到 BVT 的存在，他們只針對成功的創(chuàng)建進行測試（如功能測試）。
持續(xù)集成有一個與直覺相悖的基本要點，那就是“ 經(jīng)常性的集成比偶爾集成要好”。Martin Fowler 認為對于持續(xù)集成來說，集成越頻繁，效果越好 ，如果你的集成不是經(jīng)常進行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶爾才進行一次（一周甚至一個月）， 等到集成階段發(fā)現(xiàn)bug，然后找原因解決bug，會耗費你大量的時間與精力，而且這種方式有點像傳統(tǒng)的集成模式，這違背了持續(xù)集成的初衷。
根據(jù) Martin Fowler 的觀點，項目 bug 的增加和時間并不是線性增長的關(guān)系，而是和時間的平方成正比，兩次集成間隔的時間越長，bug 增加的數(shù)量越是超過你的預(yù)期，解決 bug 付出的工作量也越大，而你越覺得付出的工作量越大，你就越想推遲到以后去集成，企圖到最后一次性解決問題，結(jié)果 bug 產(chǎn)生的就更多，導(dǎo)致下一次集成的工作量更大，你越感覺到集成的痛苦，就越將集成的時間推后，最后形成惡性循環(huán)。
需要注意的是從項目的一開始就引入持續(xù)集成可以盡早的發(fā)現(xiàn) bug，但是并不代表持續(xù)集成可以幫你抓到所有的 bug。持續(xù)集成的排錯能力取決于測試技術(shù)，眾所周知，無法證明已經(jīng)經(jīng)過測試的代碼就已經(jīng)找到了所有的錯誤。
前面列舉了持續(xù)集成這么多優(yōu)點，但是創(chuàng)建一個持續(xù)集成的環(huán)境技術(shù)上是比較復(fù)雜的，也需要一定的時間，關(guān)鍵是在于持續(xù)集成可以“及時”抓到足夠多的 bug，從根本上消除傳統(tǒng)模式的弊端，這就已經(jīng)值回它的開銷了。
ThoughtWorks 公司開放了其持續(xù)集成的工具CC的源代碼，持續(xù)集成對于大部分開發(fā)人員來說就不再只是停留在口頭上的漂亮的術(shù)語，任何人在掌握了持續(xù)集成的基礎(chǔ)理論后，都可以使用CC來體會持續(xù)集成在項目開發(fā)中的巨大威力。
3. 集成框架
下個圖描述持續(xù)集成的硬件環(huán)境，圖中包括了一臺獨立的源碼庫服務(wù)器以及開發(fā)人員的終端（同時也是源碼庫服務(wù)器的客戶端），出自對性能的考慮，建議CC 在一臺獨立的服務(wù)器上運行。當然你可以將 CC 放在發(fā)布服務(wù)器上甚至某個開發(fā)人員的終端上。
4. CC內(nèi)部工作架構(gòu)
下圖是CC系統(tǒng)內(nèi)部工作架構(gòu)圖：
CC主要依賴Build Loop循環(huán)構(gòu)建實現(xiàn)，通過讀取Config.xml配置文件信息，在每次輪詢中完成源代碼的檢測、編譯，然后把編譯的版本發(fā)布Web容器中，以此同時把日志信息、發(fā)布結(jié)果通過RSS、郵件、網(wǎng)站等形式發(fā)布給干系人。
4.1. Build Loop
前面在討論持續(xù)集成的時候講到其最重要的特征之一是自動化，而 CC 的 Build Loop 就是為支持自動化而設(shè)計的，Build Loop 也是 CC 的核心。
Build Loop 從字面上理解就是循環(huán)創(chuàng)建的意思，CC 提供了一個守護進程( daemon)，該進程自動根據(jù)配置的時間間隔（也可以指定某個具體時間）讀取 CC 配置文件并進行循環(huán)創(chuàng)建（build cycle），每次 CC 都會重新加載配置文件（修改了配置文件不用重新啟動 CC）。
Build Loop 過程中所做的工作如下：訪問源碼控制系統(tǒng)，查看是否有代碼被修改，如果有，獲取源碼的新版本，并根據(jù)配置對源碼進行一次 Build，創(chuàng)建一個日志文件，最后向開發(fā)人員通知 build 的結(jié)果，活動圖如下：
因為 Build Loop 是根據(jù)配置文件的內(nèi)容來進行的，根據(jù)上面 BuildLoop 所做的工作，我們可以猜出配置信息主要應(yīng)該包括：定時創(chuàng)建的時間和源碼庫的訪問信息（檢查源碼變化情況），創(chuàng)建任務(wù)信息（如指定 Ant 文件）， 記錄日志（創(chuàng)建結(jié)果），通知（通知的內(nèi)容可以定制）。
4.2. CC 插件（Plugin）
CC 設(shè)計思想是one-size-fits-all，也 就是CC 是由一個很精?。?但是很強大）的核心（ Build Loop）以及一些外部插件組成，這給使用者提供了很大的擴展空間，使用者可以根據(jù)需要擴展 CC的功能（提供新的插件），而且 CC 是開源項目，你還可以查看源碼并修改CC提供的插件。CC提供了六種不同類型的插件：Listener、Bootstrappe、Modificationset、Schedule、Log以及Publisher，CC 的配置是圍繞這些插件展開的，下面對這些插件進行一個簡單的介紹：
Listener：用于處理一些項目有關(guān)的事件；
Bootstrapper：在 CC 進行創(chuàng)建之前運行，是創(chuàng)建前的準備工作
Modificationset：訪問源碼控制系統(tǒng)（如 CVS，VSS，ClearCase 等等），查看源碼自上一次 Build 之后是否被修改過，并據(jù)此決定是否需要進行下一次 Build。
Builder：對項目進行創(chuàng)建，熟悉 ANT 的使用者應(yīng)該很清楚創(chuàng)建的含義，這里簡單提一下，一次典型的創(chuàng)建包括了對項目源碼的編譯，測試，打包
Schedule：設(shè)置輪詢時間并且指定使用ANT編譯所使用的配置文件地址
Publisher：用于發(fā)布創(chuàng)建的結(jié)果，可以通過 email 的方式通知開發(fā)人員。
原文鏈接：http://www.cnblogs.com/shishanyuan/archive/2011/09/15/2176850.html
【編輯推薦】
