問題
在軟件行業發展的初期，軟件項目中最棘手、最緊張的時刻就是集成。單獨能工作的一些模塊被組裝在一起，系統整體卻常常失敗，而且很難找到失敗的原因。
解決辦法
解決辦法的關鍵在于更為頻繁地進行集成。
它給項目帶來了完全不同的感覺。項目的可見性變得好了很多，因為問題能夠更快地檢測出來。引入缺陷和發現缺陷之間的時間間隔變短，就更容易發現缺陷，您可以很容易地看見改變了什么，以方便找到問題的根源。當它與良好的測試程序配合時，可以大大減少缺陷的數量。結果是，開發者在調試上花的時間減少了，在增加功能上花的時間更多了，他們相信自己是在一個堅實的基礎上開發軟件。
持續集成意味著：
● 所有開發者都先在他們自己的工作站上執行私有構建，然后再將他們的代碼提交到版本控制庫中，從而確保他們的變更不會導致集成構建失敗。
● 開發者每天至少向版本控制庫提交一次代碼。
● 集成構建每天在一臺獨立的計算機上進行多次。
● 每次構建都必須 100%通過測試。
● 生成可以進行功能測試的產品（如 WA R、配件、可執行程序等）。
● 修復失敗的構建是優先級最高的事情。
● 某些開發者復查構建生成的報告，如編碼標準報告和依賴分析報告，尋找可以改進的地方。
最佳實踐
為缺陷編寫測試
當缺陷被發現時，找出并隔離有問題的代碼，為了修復缺陷，我們基本上需要破壞測試，先編寫一個會失敗的測試用例，然后不斷執行這個測試（在修復缺陷的過程中），直到測試不再失敗為止。
讓組件測試可重復
數據庫對于測試來說是相當沉重的依賴關系，所以您有兩種選擇：要么盡量地進行模擬，在盡可能長的時間內完全避免使用數據庫，要么使用數據庫并承受其開銷。實現這種測試最容易的方法是使用某種xDbUnit 這樣的數據庫填充框架（如
針對.NET 的NDbUnit、針對 Java 的DbUnit 、針對 Python 的PDbSeed ）。這些框架將數據庫的數據集抽象到 XML 文件中，然后為開發者提供細粒度的控制，即在測試過程中如何將這些數據填充到數據庫中。