本文由Markdown語法編輯器編輯完成。

1. 持續整合的概念

持續整合（Continuous Integration）的概念有很多不同的版本，持續整合的出現是為了配合敏捷開發（相對於瀑布開發）的速度和效率而產生的一個用於編譯、測試、釋出、部署的工具。

為什麼叫持續呢？因為編碼人員每天都會向專案提交程式碼，因此專案原始碼每天都會發生改變，為了能夠驗證最新的程式碼是否能夠被成功編譯，是否會影響前面迭代已經通過的自動化測試case，是否能夠打出完整的可執行包供測試人員進行測試……。通過每天，甚至是每次提交程式碼後的持續整合，可以很快地得到反饋，並且易於追溯，即使出了問題也很容易知道是由於哪一位開發人員的提交而導致的。

持續整合（CI）是一種實踐，可以讓團隊在持續的基礎上收到反饋並進行改進，不必等到開發週期後期才尋找和修復缺陷。

通俗一點兒說：
就是指對於開發人員的每一次程式碼提交，都自動地把Repository中所有程式碼Check out到一個空目錄，並且自動執行所有Test Case。如果成功則接受這次提交，否則告訴所有人，這是一個失敗的Revision。

持續整合一般通過編寫好的python等指令碼，自動完成一系列整合所需要的步驟。從程式碼的check out, 構建專案工程，編譯原始碼，生成可執行包或安裝檔案，壓縮打包，上傳到公司或專案組的FTP等位置……

如果不想每次提交都去整合的話，可以選擇在一個固定的時間點去整合，比如每天晚上等專案組的所有成員都已經把當天的程式碼提交完畢後，啟動整合。當第二天上班的時候，測試人員會去FTP下載最新的專案包，開始測試開發人員前一天提交的程式碼是否正確。這也是Daily Build的概念來源，即每日構建。

2. 持續整合的工具

有一篇文章介紹了持續整合的八大工具，分別是：

• Hudson
• CruiseControl
• Continuum
• QuickBuild
• Bamboo
• Jenkins
• TeamCity
• CI-Eye

我在三年半的工作生涯中，接觸過的兩個持續整合工具分別是Bamboo和Jenkins，因此對這兩個持續整合工具比較親切，但是真正瞭解得很少。一時，這個工具一般都是自動執行，很少需要人的參與，除非前一天構建失敗後，需要登入工具去下載失敗的log；二來，這個也主要是專案經理和測試組會經常訪問的工具，開發人員一般只負責提交程式碼到SVN即可。

但是，不管是哪一個持續整合工具，它本質上只不過是一個定時器，時間一到，做你腳本里讓它去做的事。如果，想要擴充套件持續整合的作用，則需要將這個工具與其他的工具結合，才能顯示出持續整合的本色。

比如，如果想增加測試工具，選擇JUnit, JWebUnit, Selenium等；
想檢查程式碼標準，需要用checkstyle, sonarqube等程式碼規範檢查工具；
想了解測試覆蓋率，可以用Istanbul, JCoverage等工具；
想打包生成二進位制檔案，要用Ant, Make之類的工具。

參考連結：