持續內建(CI)、自動化建構和自動化測試--初探 .

此文章是為了總結前一段時間由于Maven2的學習而引起的一個持續內建的學習。

一、什麼是持續內建（Continuous Integration）？

     這個概念到底是怎麼定義，說實話很多不同的版本。這裡我就把我了解的什麼叫持續內建說下，其實持續內建是為了配合靈活開發的速度和效率而産生的一個用于編譯、測試、釋出、部署的工具。為什麼叫持續呢？其實就是編碼人員送出了源碼，那麼該工具就可以進行編譯，測試等一系列運作。怎麼能夠讓編碼人員很快的知道編碼的異常。

二、工具的選擇 ：Maven2、 Hudson（CruiseControl可以考慮）、SVN

首先我們來看看這個環境是怎麼運作的吧！ 編碼人員将代碼送出到SVN，那麼Hudson就監控到SVN有更新，那麼Hudson就去SVN取出更新的源碼。取出後就交給Maven去編譯、測試、釋出等操作。

一、什麼是持續內建（Continuous Integration）？

這個名詞已經在軟體開發領域持續了N年，一個比較簡單的定義如下：

持續內建（CI）是一種實踐，可以讓團隊在持續的基礎 上收到回報并進行改進，不必等到開發周期後期才尋找和修複缺陷。

通俗一點兒說：

就是指對于開發人員的每一次代碼送出，都自動地把Repository中所有代碼Check out到一個空目錄，并且自動運作所有Test Case。如果成功則接受這次送出，否則告訴所有人，這是一個失敗的Revision。

更具體的解釋可以參考Martin fowler的Continuous Integration  。

二、持續內建的價值與成本

有句時髦的話，叫做“存在即為合理”。既然持續內建已經存在了這麼長的時間，而且沒有消失的迹象，那就是有價值的東西。

那麼它的價值何在？有人概括如下：

(1) 減小風險；(2) 減少手動過程；(3) 生成建構結果；(4) 安全感。

而持續內建的成本在于對持續內建代碼的維護成本和內建的時間成本。因為随着項目進行，軟硬體環境會越來越複雜，成品代碼也會不斷膨脹。此時，需要團隊而修改或增加原有的測試代碼，以适應這些變化，同時，每次內建所需時間也會變長，這就是持續內建的成本。

某個blog中提道：“這種內建是如此的頻繁，多少次的代碼Commit就有多少次持續內建。前提是內建的成本很低，或者說是完全自動化的。”

三、持續內建應該自動化什麼呢？

我們要以盡可能少的成本來獲得盡可能多的價值。這就要考慮哪些自動化是必要的啦。

Jez Humble提到至少有六點要做到自動化，

它們分别是(1)自動化的運作測試；

(2) 自動産生可部署的二進制成品；

(3) 自動将成品自動部署到近似生産環境；

(4) 自動為CodeBase打上标簽；

(5) 自動運作回歸測試；

(6)自動生成度量報告。

四、持續內建伺服器的選擇

在進行持續內建實踐前，應當正确的選擇并配置持續內建伺服器。比較成熟的持續內建伺服器包括：CruiseControl, Anthill, Bamboo, TeamCity, Continuum 等。CruiseControl作為開源産品，以其對于各種SCM（源碼管理，制造業上是供應鍊關系管理）以及建構工具的廣泛支援而被許多開發團隊所接受。而開發自動化專家 Duvall 采用一緻的評估标準和很多說明性示例，介紹了一些開源 CI 伺服器，包括 Continuum、CruiseControl 和 Luntbuild。并指出“要根據 自己的 具體技術和政策需求對工具進行分析”。并用以下五個名額來評估CI工具，它們分别是：(1)  特性；(2)  可靠性；(3)  壽命；(4) 目标環境；(5) 易用性。結果如下表：

而CruiseControl是我唯一真正用過的持續內建工具，它現在靈活而又強大功能也讓我瞠目，而且配置與管理也較兩年前容易得多啦。

為什麼說它強大呢？因為你隻要想得到的問題，它也都會有所考慮。朋友的Blog上有些CruiseControl的最佳實踐足以證明這一點，隻要你肯去實踐。

五、隻有持續內建伺服器是遠遠不夠的

正如Jez Humble所說，CruiseControl和其它的CI工具本質上隻不過是一個定時器，時間一到，做你讓它做的事情。是以，必然要有其它工具與其結合，方顯持續內建的本色。這些工具又是什麼呢？

想測試的話，你就要用一些測試工具，如JUnit，JWebUnit，Selenium等等；

想檢查代碼标準的話，你就要用checkstyle等代碼規範檢查工具；

想要了解測試覆寫率的話，你可能就要用到JCoverage啦。

當然，想得到二進制檔案，就要用到Ant，Make之類的工具啦。

六、最重要的事：實踐與反思

也許這些東西大家都知道，而且有些人可能已經實踐過啦。無論這些實踐的結果是怎樣的，一定不要忘記總結和反思。如果這些實踐成功了，不要把它歸功于這個工具，而是要總結一下為什麼會成功，如果你願意的話，還可以和大家分享一下。如果這些實踐失敗了，也不要把它歸功于這個工具，而是要反思一下，是否正确地使用了這個工具，團隊成員是否都喜歡這個工具，為什麼？