從技術層面上來講，"持續內建"的含義是指開發團隊中的每個成員都盡量頻繁地把他們所做的工作更改合入到源碼庫中，并且還要驗證新合入的變化沒有造成任何破壞。本文中，作者将介紹如何建構持續內建所需要的環境。
靈活意味着什麼
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本身的知識做太多的介紹，主要集中在如何把這些工具內建起來建構一個持續內建環境上面，相關的基本知識讀者可以自行參考相關的書籍。