軟體整合並不是一個新的問題或者概念，當一個人獨立開發一個產品的時候，比如做畢業設計的時候，根本就不存在軟體整合，更不用去考慮持續整合！可到了三五個人、七八條槍，進行團隊開發的時候，這個問題就不得不去考慮了！特別是在傳統的瀑布式開發中，模組開發是獨立進行，當各個模組都完整開發完了之後，再進行模組間的整合，很多噩夢都發生在這個時候：介面不統一，模組間對需求的理解不一致……
往往要磨上十天半個月才能搞定！
Martin Fowler（ThoughtWorks公司的那個“大鬍子”）對持續整合的註解如下：
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day.
Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more
rapidly.
我覺得可以這樣簡單理解：及早地將開發人員的代碼整合起來，通過各種工具來及時地發現代碼中存在的問題，以確保代碼品質的穩定性和準確性，讓Agile第二宣言Working Software得以實現！
下面我們按照Martin Fowler的思路來介紹持續整合：
1）Maintain a Single Source Repository
一般來說，工程都是以團隊的形式進行開發的。一個工程的檔案都是以千百計算的，如果需要手工去跟蹤、同步這些檔案，那無疑是天方夜譚。於是原始程式碼控制工具應運而生。開源的原始程式碼控制工具有CSV，Subversion等，個人感覺Subversion比較好用，另外由IBM
Rational出品的Clearcase功能更是強大，不過不是很便宜。我們可以在這些原始程式碼控制工具上面建立一個工程的Stream，然後大家便可以在這個Stream上面建立自己的Child
Stream, 在代碼進行改動之後，我們就將這些代碼Deliver到程式碼程式庫，代碼的管理工具會為我們做代碼的同步工作。這樣大家就可以基於最新的代碼進行開發。
2)Automate the Build
從拿到原始碼到變成一個可啟動並執行系統，這中間要經過一個複雜的過程。一個簡單的過程大概有：編譯/打包原始碼，將打包好的包拷貝到伺服器下面，然後啟動或者重啟伺服器，這是簡單到有點“HelloWorld”的感覺。即使在這麼簡單的過程中，還得開啟IDE才能讓編譯原始碼方便些，可在整合的伺服器中，一般是不會使用IDE的。開發人員“懶惰”的特性迫使他們開發新工具來完成這一煩人的過程。Java社區開發出Ant，.NET社區開發出Nant，現在還有MSBuild。通過這些工具，我們可以將這些複雜、重複、單調、無聊的工作通過一些配置交由工具去完成。由於Ant的功能確實很強大，以後再找時間補充Ant的使用。
3)Make Your Build Self-Testing
在傳統的開發模式中，當build一個版本出來之後，我們往往需要叫上所有的人（因為是分模組開發），花上幾個鐘頭，在系統上進行人工測試。而鬱悶的是：即使進行了人工測試，表面上看似沒有問題了，可保證不了後台邏輯的正確性。我們不是有Automake the Build嗎，那我們就可以往裡面加進一些自動化測試的任務。這些自動化測試在build的過程中，檢測代碼的邏輯的正確性、分析代碼的複雜度、指出代碼潛在的危險性，測試系統功能的完整性和準確性，測試系統的行為等等。當然，不是說我們往Ant指令碼裡面加進幾條命令就可以完成這些功能，而是需要我們在寫功能代碼的同時或者之前，編寫相應的測試代碼，這就是前面說的Test
Driven Development（TDD，測試驅動開發）,先寫測試，再寫實現！一般來說，測試包括了後台邏輯測試(一般用NUnit),測試前台指令碼邏輯（Javascript的指令碼一般用JsUnit），測試頁面功能行為正確性（一般用Selenium），分析代碼的複雜度（可以用PMD），分析代碼潛在的危險性（用FindBugs）。
4)Everyone Commits Every Day
整合很多時候是為了溝通，告訴其他開發人員自己已經做了那些代碼的改動。及時的溝通在團隊開發中的重要性是不容置疑的。所以我們要儘快地將自己代碼的改動提交。但代碼提交之前，一定要確保自己代碼的正確性，至少讓系統可以跑起來。而不是說代碼一有改動，就不管三七二十一，把代碼弄上去就行了，這樣對整個團隊來說，cost會更大！所以是否每一天都要提交代碼呢，我覺得要具體問題具體分析！
5)Every Commit Should Build the Mainline on an Integration Machine
前面說到每天都提交代碼，這就會帶來一個問題：在提交代碼之前，未必有去拿到最新代碼，即使拿到最新代碼，由於開發環境的不同，也可能沒發現什麼問題。於是代碼上去了，另一位同事去拿最新代碼，有可能整個系統都跑不起來。所以，我們還需要一個整合的機器，它負責在每次代碼提交之後，去擷取最新的代碼，然後根據設定去運行相應的測試，看看這次提交的代碼有沒有什麼問題。這樣，便可以在下一個同事拿到新代碼之前發現問題，並相應的owner去處理，減少更多額外的工作。CruiseControl（由Thoughworks公司開發的，並貢獻給開源社區）這個工具便可以做到這一點：它能夠監聽程式碼程式庫有沒有代碼變更，如果有的話，便可以拿到最新代碼，然後去運行相應的測試工作。關於CruiseControl的使用，可以看看官網上面的說明，後面可能會獨立介紹一下。
6)Keep the Build Fast
前面我們說了，持續整合就是為了更快、及早地發現問題。所以如果一次整合需要耗費幾個小時，甚至一天（聽說Microsoft一個build就要一天，還是分布式的），那就失去了持續整合的意義了。所以要讓每次提交代碼觸發的整合動作越快越好，XP（極限編程）的大綱說每次build在10分鐘以內是最理想的。但其實很多時候很難做到的，一個UAT都往往要佔據幾分鐘的時間，重啟伺服器的時間也是不可或缺的，所以我覺得這個快得根據不同的項目而論。
7)Test in a Clone of the Production environment
測試就是為了檢查產品的使用方式，所以整合機器的環境搭建最好是跟最終產品的環境一致，比如說：相同的資料庫，相同的伺服器，相同的作業系統等等。
8)Everyone can see what’s happening
持續整合就是一種溝通，那我們應該讓所有的人即時地、方便地看到持續整合的情況。一種比較簡便的辦法是安裝一個JCCTray(http://jcctray.sourceforge.net/
) , 配置響應的參數，啟動它之後，可以在案頭的右下方看到一個圓球的表徵圖，當表徵圖是綠色的，說明最近一次的持續整合是成功的，當表徵圖是紅色的，說明最近一次的整合是失敗的，而當它是黃色的時候，說明持續整合進行中中。下面的表徵圖顯示最近一次的整合是有問題的：
還有一種就是用一盞燈來顯示，紅綠黃的意思跟上面一樣，具體可以看http://www.pragmaticautomation.com/cgi-bin/pragauto.cgi/Monitor/Devices/BubbleBubbleBuildsInTrouble.rdoc
9)Automate Deployment
當拿到新代碼，經過測試，發現沒有問題，這時應該進行自動部署。比如自動部署到QA環境等，很多伺服器的自動部署都可以用Ant任務來完成的，所以具體的伺服器得去查看相應的Ant任務。
前面按照Martin Fowler的思路，介紹了持續整合的整個過程。個人覺得持續整合不僅僅在Agile是必須的，在傳統的開發模式中，有了持續整合，也是對整個開發有很多的協助，特別是提高代碼的穩定性和正確性。
後面應該會陸續就自己在使用持續整合的一些工具過程中的一些想法記錄下來。
