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