持續集成是一種軟件開發實踐，即團隊開發成員經常集成它們的工作，通常每個成員每天至少集成一次，也就意味着每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發佈，自動化測試)來驗證，從而儘快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。
一些原則：
1. 所有的開發人員需要在本地機器上做本地構建，然後再提交的版本控制庫中，從而確保他們的變更不會導致持續集成失敗。
2. 開發人員每天至少向版本控制庫中提交一次代碼。
3. 開發人員每天至少需要從版本控制庫中更新一次代碼到本地機器。
4. 需要有專門的集成服務器來執行集成構建,每天要執行多次構建。
5. 每次構建都要100%通過。
6. 每次構建都可以生成可發佈的產品。
7. 修復失敗的構建是優先級最高的事情。
持續集成周期包括以下幾個步驟：
1.持續集成服務器不斷從版本控制服務器上檢查代碼狀態，看代碼是否有更新。
2.如果發現代碼有最新的提交，那麼就從版本控制服務器下載最新的代碼。
3.等代碼完全更新以後，調用自動化編譯腳本，進行代碼編譯。
4.運行所有的自動化測試。
5.進行代碼分析。
6.產生可執行的軟件，能夠提供給測試人員進行測試。
如果其中任何一個步驟失敗，就表示該Build失敗，持續集成服務器會給予相應的反饋。一般來說，持續集成服務器會有相應的管理界面，可以看到Build的狀態以及相應的信息，如果Build失敗，可以查看原因，是編譯失敗還是測試失敗。或者在每次Build後，持續集成服務器發郵件通知，從郵件中可以看到最新Build的狀態。當然，也可以自定義反饋方法，比如在ThoughtWorks中國，有個團隊的持續集成反饋就是火山燈，黃色表示正在進行Build，綠色表示Build成功，而紅色則表示Build失敗，一旦發現燈變紅了，所有人都不能提交代碼，而應該儘快修復該Build。還有一個團隊更有創意，用語音來進行反饋。如果Build成功，就會有語言提示說“Build XXXX成功”，如果失敗，就會有提示“Build XXXX失敗，是由XXX提交的”，被唸到名字的成員就得停下來修復這個Build。
持續集成實踐的目的不是減少Build失敗的次數，而是儘早發現問題，在最短的時間內解決問題，減少風險和浪費。如果想嘗試持續集成，首先需要的是持續集成服務器，比如CruiseControl或者VSTS；然後需要把現有的Build自動化，比如寫Ant腳本；最後就是在持續集成服務器上進行配置，比如配置版本控制，集成間隔時間，如何部署，如何反饋等。
本文出自：http://xp9802.iteye.com/blog/1217971 ，轉載時請務必保留此出處