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