敏捷式軟體開發 (Agile Software Development)基礎: 持續整合環境的構建

敏捷意味著什麼

Agile可以說是近幾年來軟體工程界最"熱"的一個單詞，關於它的文章、書籍、討論不 計其數。儘管如此，卻仍有大量的從業者對Agile存有誤解和困惑。Agile到底意味著什麼 呢？僅僅是一些漂亮、時髦的宣傳嗎？到底怎樣才算是Agile呢？做到了Agile能為軟體Team Dev帶來什麼好處呢？類似的問題還有很多。

Agile其實根本不是一個什麼新鮮、時髦的東西，它已經存在了數十年之久了。在這數 十年中，那些取得成功的軟體Team Dev無一不是敏捷Team Dev。他們在自己的軟體開發過 程中大量應用了Agile的思想，只是沒有把他們的工作方式、價值觀念以及指導思想正式 表述出來而已。到了2001年初，這種狀況得到了改善，一批在軟體開發領域奮戰了數十年 的領袖和開發大師們（尤其是物件導向社團和Smalltalk社團的領袖）再也無法容忍由於 對軟體本身的誤解以及官僚主義所造成的軟體開發方面的混亂，他們把自己數十年來對軟 件以及團隊軟體開發的理解和經驗總結成了一份"Agile Manifesto"，以呼籲軟體從業者 們應該以怎樣的態度來開發和認識軟體。Agile的所有思想基礎和價值取向全都包含在這 份宣言之中。

但是這份宣言對於大多數人來講，仍然顯得有些缺乏可實踐性。作為一個軟體開發團 隊，我們可以接受敏捷宣言中的價值觀念，但是怎樣做才是Agile呢？？？換句話說， Agile如何落實到團隊每天的開發工作中呢？幾乎每個試圖嘗試敏捷式軟體開發 (Agile Software Development)的團隊，都 曾經被這個問題所困擾過。從團隊日常的開發活動的角度來看，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提供了基礎。那麼什麼是持續整合呢？

什麼是持續整合

從技術層面上來講，"持續整合"的含義是指Team Dev中的每個成員都盡量頻繁地把他 們所做的工作更改合入到源碼庫中，並且還要驗證新合入的變化沒有造成任何破壞。這裡 的庫指的是受版本控制工具（比如：ClearCase或者CVS）管理的軟體原始碼儲存地。這裡 的頻繁程度和團隊所開發的軟體類型有關，但是一般來說頻度應該不大於1個小時。

請注意，持續整合的概念和大家以前曾經聽說過的"每日構建"和"每晚構建"的概念有 所不同。按照Martin Fowler的話來講，這個不同主要體現在三個方面：

持續整合在一天之中要頻繁地發生，而每晚構建卻每天發生一次。

每晚構建的目的是為了產生一個穩定的可用發布，而持續整合除了達成這個目標之外 ，還對整合的成功與否提供了快速的反饋。

每晚構建並沒有規定開發人員應該check in的頻度，而持續整合為了達到快速反饋的目 的，鼓勵高頻度的check in。

大家可以看出，持續整合的高頻度check in和快速提供反饋的特性為有效地達到Agile 提供了一個堅實的技術基礎。可以這麼說，如果沒有一個好的持續整合環境作為基礎，要 想高效地進行團隊軟體開發幾乎是不可能的。那麼，如何構建起一個這樣的環境呢？在本 文的後面，我將給出了一個詳細的教程為你提供一步一步的詳細指導，但是在這之前，我 們先來瞭解一下構建一個有效持續整合環境所需要的工具。