簡單地說，持續集成就是快速且高頻率地自動構建項目的所有源碼，並為項目成員提供豐富的反饋信息。這句話有很多關鍵的詞：
·快速：集成的速度要盡可能地快，開發人員不希望自己的代碼提交半天之後才得到反饋。
·高頻率：頻率越高越好，例如每隔一小時就是個不錯的選擇，這樣問題才能盡早地被反映出來。
·自動：持續集成應該是自動觸發並執行的，不應該有手工參與。
·構建：包括編譯、測試、審查、打包、部署等工作。
·所有源碼：所有團隊成員提交到代碼庫裡的最新的源代碼。
·反饋：持續集成應該通過各種快捷的方式告訴團隊成員最新的集成狀態，當集成失敗的時候，反饋報告應該盡可能地反映失敗的具體細節。
一個典型的持續集成場景是這樣的：開發人員對代碼做了一些修改，在本地運行構建並確認無誤之後，將更改提交到代碼庫。具有高配置硬件的持續集成服務器每隔30分鐘查詢代碼庫一次，發現更新之後，簽出所有最新的源代碼，然後調用自動化構建工具（如Maven）構建項目，該過程包括編譯、測試、審查、打包和部署等。然而不幸的是，另外一名開發人員在這一時間段也提交了代碼更改，兩處更改導致了某些測試的失敗，持續集成服務器基於這些失敗的測試創建一個報告，並自動發送給相關開發人員。開發人員收到報告後，立即著手調查原因，並盡快修復。
圖11-1形象地展示了整個持續集成的過程。
通過圖11-1可知，當持續集成服務器構建項目成功後，還可以自動將項目構件部署到Nexus私服中。
一次完整的集成往往會包括以下6個步驟：
1）持續編譯：所有正式的源代碼都應該提交到源碼控制系統中（如Subversion），持續集成服務器按一定頻率檢查源碼控制系統，如果有新的代碼，就觸發一次集成，舊的已編譯的字節碼應當全部清除，然後服務器編譯所有最新的源碼。
2）持續數據庫集成：在很多項目中，源代碼不僅僅指Java代碼，還包括了數據庫SQL腳本，如果單獨管理它們，很容易造成與項目其他代碼的不一致，並造成混亂。持續集成也應該包括數據庫的集成，每次發現新的SQL腳本，就應該清理集成環境的數據庫，重新創建表結構，並填入預備的數據。這樣就能隨時發現腳本的錯誤，此外，基於這些腳本的測試還能進一步發現其他相關的問題。
圖11-1 持續集成流程
3）持續測試：有了JUnit之類的框架，自動化測試就成了可能。編寫優良的單元測試並不容易，好的單元測試必須是自動化的、可重複執行的、不依賴於環境的，並且能夠自我檢查的。除了單元測試，有些項目還會包含一些依賴外部環境的集成測試。所有這些測試都應該在每次集成的時候運行，並且在發生問題的時候能產生具體報告。
4）持續審查：諸如Checkstyle和PMD之類的工具能夠幫我們發現代碼中的壞味道（Bad Smell），持續集成可以使用這些工具來生成各類報告，如測試覆蓋率報告、Checkstyle報告、PMD報告等。這些報告的生成頻率可以低一些，如每日生成一次，當審查發現問題的時候，可以給開發人員反饋警告信息。
5）持續部署：有些錯誤只有在部署後才能被發現，它們往往是具體容器或者環境相關的，自動化部署能夠幫助我們盡快發現這類問題。
6）持續反饋：持續集成的最後一步的反饋，通常是一封電子郵件。在重要的時候將正確的信息發送給正確的人。如果開發者一直受到與自己無關的持續集成報告，他慢慢地就會忽略這些報告。基本的規則是：將集成失敗報告發送給這次集成相關的代碼提交者，項目經理應該收到所有失敗報告。
持續集成需要引入額外的硬件設置，特別是對於持續集成服務器來說，性能越高，集成的速度就越快，反饋的速度也就越快。持續集成還要求開發者使用各種工具，如源碼控制工具、自動化構建工具、自動化測試工具、持續集成軟件等。這一切無疑都增加了開發人員的負擔，然而學習並適應這些工具及流程是完全值得的，因為持續集成有著很多好處：
·盡早暴露問題：越早地暴露問題，修復問題代碼的成本就越低。持續集成高頻率地編譯、測試、審查、部署項目代碼，能夠快速地發現問題並及時反饋。
·減少重複操作：持續集成是完全自動化的，這就避免了大量重複的手工勞動，開發人員不再需要手動地去簽出源碼，一步步地編譯、測試、審查、部署。
·簡化項目發佈：每日高頻率的集成保證了項目隨時都是可以部署運行的，如果沒有持續集成，項目發佈之前將不得不手動地集成，然後花大量精力修復集成問題。
·建立團隊信心：一個優良的持續集成環境能讓團隊隨時對項目的狀態保持信心，因為項目的大部分問題區域已經由持續集成環境覆蓋了。
既然持續集成有那麼多優點，現在讓我們開始動手架設自己的持續集成環境吧！