從技術層面上來講，"持續集成"的含義是指開發團隊中的每個成員都儘量頻繁地把他們所做的工作更改合入到源碼庫中，並且還要驗證新合入的變化沒有造成任何破壞。本文中，作者將介紹如何構建持續集成所需要的環境。
Agile可以說是近幾年來軟件工程界最"熱"的一個單詞，關於它的文章、書籍、討論不計其數。儘管如此，卻仍有大量的從業者對Agile存有誤解和困惑。Agile到底意味着什麼呢？僅僅是一些漂亮、時髦的宣傳嗎？到底怎樣纔算是Agile呢？做到了Agile能爲軟件開發團隊帶來什麼好處呢？類似的問題還有很多。
Agile其實根本不是一個什麼新鮮、時髦的東西，它已經存在了數十年之久了。在這數十年中，那些取得成功的軟件開發團隊無一不是敏捷開發團隊。他們在自己的軟件開發過程中大量應用了Agile的思想，只是沒有把他們的工作方式、價值觀念以及指導思想正式表述出來而已。到了2001年初，這種狀況得到了改善，一批在軟件開發領域奮戰了數十年的領袖和開發大師們（尤其是面向對象社團和Smalltalk社團的領袖）再也無法容忍由於對軟件本身的誤解以及官僚主義所造成的軟件開發方面的混亂，他們把自己數十年來對軟件以及團隊軟件開發的理解和經驗總結成了一份"Agile Manifesto"，以呼籲軟件從業者們應該以怎樣的態度來開發和認識軟件。Agile的所有思想基礎和價值取向全都包含在這份宣言之中。
但是這份宣言對於大多數人來講，仍然顯得有些缺乏可實踐性。作爲一個軟件開發團隊，我們可以接受敏捷宣言中的價值觀念，但是怎樣做纔是Agile呢？？？換句話說，Agile如何落實到團隊每天的開發工作中呢？幾乎每個試圖嘗試敏捷軟件開發的團隊，都曾經被這個問題所困擾過。從團隊日常的開發活動的角度來看，Agile就是： "Short Cycles that are test-driven and feedback-driven, yielding constant improvement."
其中，short cycle是核心。整個軟件開發活動應該被劃分成一系列短的迭代過程，每個迭代完成一定數目的features。迭代的週期應該儘量得短。更爲重要的是，迭代應該是由測試和反饋驅動（TDD和溝通）的。只有這樣，我們才能爲持續地改進（通過refactoring）提供一個良好的基礎和安全網絡。請注意，這個過程和一般所說的code-and-fix的本質不同在於：這裏的每個迭代週期產出的都是一個經過驗證的可用產品，只是可能功能不全，並且這是一個有意識的、持續的基於反饋的改進過程，而不是簡單的fix。其實所有成功的項目開發活動都是接近這個標準的，只不過Agile把它放在了最爲重要的位置上。
要想有效地達到上面所說的效果，除了需要一些技術方面的技能外（比如：重構技能，TDD技能等）。我們還需要一個能夠對上面這種形式的活動進行有效支撐的環境，這個環境應該是所有想取得成功的項目的基礎，也就是一個持續集成環境。持續集成爲有效地達到Agile提供了基礎。那麼什麼是持續集成呢？
  |
|
從技術層面上來講，"持續集成"的含義是指開發團隊中的每個成員都儘量頻繁地把他們所做的工作更改合入到源碼庫中，並且還要驗證新合入的變化沒有造成任何破壞。這裏的庫指的是受版本控制工具（比如：ClearCase或者CVS）管理的軟件源代碼儲存地。這裏的頻繁程度和團隊所開發的軟件類型有關，但是一般來說頻度應該不大於1個小時。
請注意，持續集成的概念和大家以前曾經聽說過的"每日構建"和"每晚構建"的概念有所不同。按照Martin Fowler的話來講，這個不同主要體現在三個方面：
- 持續集成在一天之中要頻繁地發生，而每晚構建卻每天發生一次。
- 每晚構建的目的是爲了產生一個穩定的可用發佈，而持續集成除了達成這個目標之外，還對集成的成功與否提供了快速的反饋。
- 每晚構建並沒有規定開發者應該check in的頻度，而持續集成爲了達到快速反饋的目的，鼓勵高頻度的check in。
大家可以看出，持續集成的高頻度check in和快速提供反饋的特性爲有效地達到Agile提供了一個堅實的技術基礎。可以這麼說，如果沒有一個好的持續集成環境作爲基礎，要想高效地進行團隊軟件開發幾乎是不可能的。那麼，如何構建起一個這樣的環境呢？在本文的後面，我將給出了一個詳細的教程爲你提供一步一步的詳細指導，但是在這之前，我們先來了解一下構建一個有效的持續集成環境所需要的工具。
|
|
高效地進行持續集成活動的一條有效途徑就是自動化，這一點不用說大家也都知道。那麼如何才能實現自動化呢？有沒有一些現成的工具可以直接拿來使用呢？答案是肯定的。除了那些價格昂貴的商用工具軟件外，還有很多簡單易用並且非常有效的Open Source免費軟件可用。對於這些開源的免費軟件，大家大可放心使用，因爲很多非常優秀的開源軟件都是在這些工具軟件所構建的持續集成環境中開發出來的。下面我對幾個比較重要的開源工具進行簡單的介紹。
- Eclipse：Eclipse是一個開源的IDE，是爲程序員量身定做的。它最大的特點在於它借鑑了Smalltalk開發環境的思想，可以把自己內部的工作原理通過某種方式展現在使用者面前，使用者只要遵循一些原則就可以根據自己的需要更改這個開發環境。在Eclipse中，這種機制是通過plug-in的方式運作的。通過這種方式，使用者可以方便地把開發過程中常用的工具無縫地集成起來，並以便於自己使用的方式呈現出來。比如：可以方便地把refactoring、JUNIT和CVS等工具集成到Eclipse這個統一的開發平臺中來，爲持續集成提供一個良好的操作平臺。
- CVS：CVS是一個開源的版本控制工具軟件，和一些價格昂貴的同類商業軟件相比，它提供的功能可謂不多，但是這些功能對於大多數的軟件開發團隊來說已經足夠了。CVS爲開發團隊提供了一個項目範圍內的時間機器。通過它，團隊可以方便、準確地獲取項目在指定時間的狀況。不僅如此，CVS還提供有tag和branch的功能，這些功能爲團隊進行多分支並行開發提供了基礎，並且不用擔心工作成果的丟失問題。
- CruiseControl：CruiseControl是一個持續構建過程框架，並且它對外提供了用於擴展的機制。使用CruiseControl的plugins機制，用戶可以方便地將各種需要的源碼控制工具和構建工具集成起來，並且可以針對當前和歷史構建狀態提供諸如email通知、Web顯示等對外接口。正是通過這個工具，實現了持續集成的可定製化和自動化。
好了，工具的介紹就到這裏，下面就可是我們的持續集成環境搭建之旅。本文不對Refactoring技術、Eclipse、JUnit以及CVS本身的知識做太多的介紹，主要集中在如何把這些工具集成起來構建一個持續集成環境上面，相關的基本知識讀者可以自行參考相關的書籍。