對我來說，解釋持續集成最簡單的方法就是用一個簡單的例子來示范開發一個小 feature。現在假設我要完成一個軟件的一部分功能，具體任務是什么并不重要，我們先假設這個 feature 很小，只用幾個小時就可以完成。（我們稍后會研究更大的任務的情況。） 一開始，我將已集成的源代碼復制一份到本地計算機。這可以通過從源碼管理系統的 mainline 上 check out 一份源代碼做到。 如果你用過任何源代碼管理系統，理解上面的文字應該不成問題。但如果你沒用過，可能會有讀天書的感覺。所以我們先快速解釋一個這些概念。源代碼管理系統將項目的所有源代碼都保存在一個“倉庫（repository）”中。系統的當前狀態通常被稱為“mainline”。開發者隨時都可以把mainline復制一份到他們自己的計算機，這個過程被稱為“check out”。開發者計算機上的拷貝被稱為“工作拷貝（working copy）”。（絕大部分情況下，你最終都會把工作拷貝的內容提交到mainline上去，所以兩者實際上應該差不多。） 現在我拿到了工作拷貝，接下來需要做一些事情來完成任務。這包括修改產品代碼和添加修改自動化測試。在持續集成中，軟件應該包含完善的可自動運行的測試，我稱之為自測試代碼。這一般需要用到某一個流行的 XUnit 測試框架。 一旦完成了修改，我就會在自己的計算機上啟動一個自動化 build。這會將我的工作拷貝中的源代碼編譯并鏈接成為一個可執行文件，并在之上運行自動化測試。只有當所有的 build 和測試都完成并沒有任何錯誤時，這個 build 過程才可以認為是成功的。 當我 build 成功后，我就可以考慮將改動提交到源碼倉庫。但麻煩的情況在于別人可能已經在我之前修改過 mainline。這時我需要首先把別人的修改更新到我的工作拷貝中，再重新做 build。如果別人的代碼和我的有沖突，就會在編譯或測試的過程中引起錯誤。我有責任改正這些問題，并重復這一過程，直到我的工作拷貝能通過 build 并和 mainline 的代碼同步。 一旦我本地的代碼能通過 build，并和 mainline 同步，我就可以把我的修改提交到源碼倉庫。 然而，提交完代碼不表示就完事大吉了。我們還要做一遍集成 build，這次在集成計算機上并要基于 mainline 的代碼。只有這次 build 成功了，我的修改才算告一段落。因為總有可能我忘了什么東西在自己的機器上而沒有更新到源碼倉庫。只有我提交的改動被成功的集成了，我的工作才能結束。這可以由我手工運行，也可以由 Cruise 自動運行。 如果兩個開發者的修改存在沖突，這通常會被第二個人提交代碼前本地做 build 時發現。即使這時僥幸過關，接下來的集成 build 也會失敗掉。不管怎樣，錯誤都會被很快檢測出來。此時首要的任務就是改正錯誤并讓 build 恢復正常。在持續集成環境里，你必須盡可能快地修復每一個集成 build。好的團隊應該每天都有多個成功的 build。錯誤的 build 可以出現，但必須盡快得到修復。 這樣做的結果是你總能得到一個穩定的軟件，它可能有一些 bug，但可以正常工作。每個人都基于相同的穩定代碼進行開發，而且不會離得太遠，否則就會不得不花很長時間集成回去。Bug被發現得越快，花在改正上的時間就越短。