既然認為它是好的，就要發揮到極限，這是XP的思想。
持續集成無疑是一種非常好的方法，那么在實際的軟件開發過程中就應該把它的好發揮到極限，但就我自己經歷過的項目以來，只在一個項目中真正的較好的實現了持續集成，不知道大家的情況是怎么樣？持續集成的最出名的代表還是MS的Daily Build和冒煙測試了。
持續集成的好處1、集成變得自動化，不依賴人工。
這點好處對于項目是多工程的情況下特別的明顯，可以想想，一個項目在多工程的情況下，如果不是 自動集成部署，而需要人手工的話，需要耗費多大的精力，對于單工程的項目來說這點可能不是那么的明顯。
2、盡早的發現集成出現的錯誤。
在不做持續集成的情況下，項目通常也許是在一個迭代的后期才開始將所有人做的東西進行集成，這個時候才暴露出集成的問題，這個時候再去查就已經非常困難了，因為東西已經很多了，采用持續集成可一定程度減少這個問題，因為持續集成保證了每次都只是小部分的集成，出現問題的話也知道范圍被鎖定在一個小的部分，而且通常可通過單元測試、功能測試以及集成測試來保證在持續集成進行時盡早發現錯誤，提醒導致持續集成失敗的相關人員。
3、不斷的發布新的可運行版本。
這點無論是對于開發人員、項目管理人員和客戶帶來的好處都是很明顯的，對于開發人員來說每天可以通過這個版本看到自己所完成的任務，增強任務完成的滿足感；對于項目管理人員來說則可以看到項目的開發在按計劃的進行；對于客戶來說，可以盡早的看到系統以確定和需求的符合性。
持續集成的實現
既然持續集成這么好，那就在項目中引入持續集成吧，怎么樣讓項目變得可進行持續集成呢？在開源界中對于持續集成有非常多的良好的支持工具，對于持續集成而言，通常是兩個部分：
項目自動部署項目自動部署的工具可選擇采用ant或maven，通過將之前項目手動部署的步驟翻譯為ant或maven的編譯腳本來完成項目的自動部署，當然，這要求對于ant或maven一定程度的熟悉，不過無論是ant還是maven都很容易上手，同時可能會需要對原有工程進行一定的改造，如采用maven一般都需要先把引用的包全部歸入一個 倉庫中。
一個項目的自動部署腳本有些時候可能很簡單，有些時候會很復雜，所有有些自動部署腳本真的是可能需要寫上個一天，但這是非常值得的。
在自動部署腳本編寫完畢后，就可以通過命令或在IDE中直接部署就可完成整個項目的自動部署的動作。
通常項目自動部署的過程需要有這么幾步：
1、清空以往的編譯。
2、編譯項目工程。
3、運行項目工程中的單元測試。
4、部署工程。
5、如為多工程的項目則其他工程也需要重復上面的1、2、3、4步驟。
6、運行功能測試。
7、生成項目網站(以便查看項目的代碼情況、測試運行情況等)(可選)。
在自動部署完成時，即可看到項目的運行版本，同時從項目網站中可了解項目的代碼情況、測試的運行情況等。
項目持續集成項目持續集成的工具可選擇采用luntbuild或cruisecontrol(簡稱cc)，兩者各有千秋，這里不進行比較。項目持續集成需要根據項目所需要的持續集成的情況來編寫相應的持續集成腳本(luntbuild可通過web管理界面完成，cc通過編寫腳本完成)，通常項目持續集成的腳本會涉及到這些：
1、決定是采用版本管理工具(cvs)感知的方式或每日定時(nightly-build、daily-build)進行持續集成的方式，如決定采用版本管理工具感知的方式，需要確定對于版本管理工具狀態獲取的頻率，如每隔20分鐘檢查一下是否有更新。
2、持續集成進行，首先是從版本管理工具中獲取最新的系統版本，接著就是調用項目自動部署腳本完成項目的自動部署(luntbuild和cc都可直接的調用ant或maven腳本)。
3、合并自動部署后的測試結果到日志中(這點在cc中是要做的，對luntbuild不清楚)。
4、根據自動部署的結果通知相關的人員(email、jabber等等都可以)。
在腳本編寫完成后，啟動工具項目即可進行持續集成了，可以通過持續集成的網站去查看項目的持續集成情況，其中會包含持續集成執行過程的信息、測試執行的情況、持續集成的統計分析等。
總的來說搭建項目的持續集成環境不會太困難，只要對ant或maven、luntbuild或cc有一定的熟悉，同時明白項目手動部署是如何進行的。
關于工具的使用可以參見幾個工具的網站，同時也可
滿江紅.開源參考上的《持續集成實踐之cruisecontrol》。
經驗總結
從03年開始在自己所經歷的項目中就開始實行持續集成，但最終執行的好的只有一個項目，到底是什么原因呢？在這些項目中項目的持續集成環境都是搭建好了的，但就是沒執行好，總結下來發現的問題就在于：
1、開發人員沒有對持續集成形成足夠的重視。
在幾個項目中都是因為持續集成在失敗后就沒人去調好，因為在開發人員本機運行是好的，放入CVS后由于持續集成進行時的環境不一樣確實是有可能會造成失敗的，但持續集成失敗后無人重視，導致之后的持續集成一直就沒什么意義。
2、缺乏足夠的測試。
導致了項目即使持續集成成功了但可運行版本中仍然是有N多的bug，這說明持續集成是非常需要單元測試、功能測試的支撐的，否則意義將大打折扣。
還有一個是持續集成通常需要耗費很長的時間，web型系統的持續集成通常需要重啟web應用服務器；第一個問題倒是可以通過采取增量方式進行持續集成來解決，但由于不是工具直接支持的，所以這塊實現還是比較麻煩的；第二個問題就比較麻煩了，反正在我自己經歷的項目中這個問題一直沒很好的解決，通常是需要在持續集成結束后人工手動的啟動web應用服務器(我試著在cc腳本的最后去啟動應用服務器，仍然是無效的)。
無論如何，持續集成帶來的好處是非常明顯的，值得去做，既然是好的，就要把它發揮到極限(對持續集成給予足夠的重視、增加測試)，那就讓我們在項目中實現持續集成吧！