持續整合：什麼應該自動化？

一、什麼是持續整合（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以及構建工具的廣泛支援而被許多Team Dev所接受。而開發自動化專家 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之類的工具啦。

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

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