cuiyi's blog（崔毅 crazycy）

持續集成(continuous integration)作為敏捷編程的基石現在已經被絕大多數的開發團隊所廣泛采用。而持續集成的工具現如今也是百花齊放，各有千秋，本文主要對比了在Java領域中比較常見的幾種CI server（因為公司要求統一整個公司的CI server）。如果想了解更多的工具，可以看這里：http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix，這個網頁集中了決大多數比較流行的CI server，但是我發現很多的內容已經落后于實際產品的功能了，所以如果要對比的話，可能要實際到產品的站點去看一下，最好還是下載下來運行起來看。

在本文中，我主要針對以下幾種CI Server作對比，這也是公司里各個項目組目前自行選用的（版本有點多，國內的多選用了一些open source的，而老外那邊用得比較多的是商用版本，CruiseControl和TeamCity是我加的，因為名氣非常大。）：

• CruiseControl (http://cruisecontrol.sourceforge.net/)
• Hudson (https://hudson.dev.java.net/)
• LuntBuild (http://luntbuild.javaforge.com/)
• TeamCity (http://www.jetbrains.com/teamcity/)
• AntHill Pro (http://www.anthillpro.com/)
• Bamboo (http://www.atlassian.com/software/bamboo/)
• QuickBuild (http://www.pmease.com/)

在持續集成領域，

==>Hudson作為OpenSource里持續集成的后起之秀，現在已經趕超了這兩個前輩，目前恐怕是使用最多的一個CI Server了。

而后面4個是商用的CI Server，

功能對比

CI Server在本質上就是一個定時調度器。我們配置一系列的項目，然后設定一個定時器，讓它干一些活，然后通知大家。所以很多公司都使用所謂Home-made的工具，用cron+Ant/Maven來做持續集成，這個就已經可以達到CI的最簡單的功能了。而使用工具，就是我們除了基本的編譯和通知功能以外，我們還有很多其它的需求，在我們公司里，選擇CI Server主要考慮以下幾點：

• 便于公司的統一管理（大約有200+ Projects需要統一管理）
• 對于項目本身進行流程管理: Daily Build -> QA Build -> Release Build
• 和公司AD（Active Directory）的連接以對用戶進行權限管理
• Continuous Testing的支持，即對于項目的Test要能產生出詳盡的報告以及收集Test的統計數據以作為項目的分析和考量
• Continuous Code Quality Analysis的支持，即能處理項目產生的Coverage報告，Code的static analysis報告，并且能收集這些報告的統計數據以作項目的分析和考量
• 與SCM工具的集成，我們公司主要有三種VCS，ClearCase, Subversion和StarTeam
• 與其它工具的集成，如bug tracking工具，IDE集成等等。

安裝CI

安裝是我們開始的第一步，同時也對各個CI server都有了初步的印象。按照各自的手冊，很快就裝好了，我基本上選擇的是Standalone的版本，就是不配置數據庫，使用自帶的，也不deploy到Tomcat或者其它容器，這點，基本上每個CI Server都非常簡單。所以也沒看出什么好壞來。這里不得不提一下AntHill，有點小家子氣，要download還得提交一個request，然后才能下載，安裝，有點煩。

配置項目

在大多數的CI Server中，絕大部分都是以Project或者Project Group來進行管理，只有LuntBuild和QuickBuild比較另類，它們使用了Configuration這個術語，意即一個配置。在配置一個典型的項目的時候，即只處理基本的一個流程：CheckOut, Build, Publish Artifacts，這些工具都完成的非常好，也非常簡單，我使用下來，覺得TeamCity的導航最方便，一目了然。而LuntBuild和QuickBuild在這方面稍顯人性化不足，這兩個工具都沒有使用wizard的模式。

下面，我接著實驗配置50個測試項目，這也就開始考驗一個CI Server的管理能力了（因為我們項目較多）。使用下來，我發現QuickBuild對于我而言，最實用。因為它使用Configuration而不是Project，并且QuickBuild是這些CI Server中唯一支持樹狀結構配置的。我可以把Configuration配置成Team A, Team B ...，然后根據實際情況，對每個Team配置任意多個子節點，孫節點（注意，Configuration的數目在QuickBuild的Community Edition里是要限制的，好像是最多16個）.

==>另外，QuickBuild的繼承關系使用起來也非常方便，如果要管理一個大型的CI Server，沒有這種繼承對我而言簡直是一種折磨。比如說用hudson來配置50個項目，我折騰了大半天，而用QuickBuild來，我大約只用了一個小時，我實際配置的Configuration（含有實際step定義的）只有3個，其它的都是繼承下來，然后修改了一下參數而已，而如果我們需要批量修改一系列的configurations的時候，則由于有繼承關系，通常我們只要去修改一下父節點的設置就可以了。TeamCity支持Project Group的概念，類似于一種樹形，但是還不完備，它只能分成兩級關系，即Project Group和Project。

==>另外QuickBuild所擁有的繼承的功能，在別的CI里沒有看到過，有的只是象TeamCity類似的copy project的功能。而QuickBuild在復制的能力上遠遠勝過其它的CI Server，它可以整個子樹拷貝，這也就意味著，我可以配置一個公司用的template configuration樹，然后復制出A部門，B部門，C部門，等等等等。對于不同項目之間的區別則通過變量來控制，贊一個！TeamCity在配置的方便上真得是沒話說，非常直觀，最酷的是象JUnit，NUnit這樣的Tests，連Ant腳本都不需要寫了，它直接就可以找出項目里的unit tests，這個在其它的工具里也沒有看到過。至于CruiseControl，Hudson，Bamboo等則是中規中矩，無甚亮點。

這個環節，QuickBuild和TeamCity勝出。

另外配置一個項目要配的就是項目持續集成的流程管理，在我們這里，基本上是這樣一個流程: Daily Build -> QA Build -> Integration Build -> Release Build。所謂Daily Build，顧名思義，就是每天一次的，由development team管理以保證項目的順暢執行，然后經過一段時間后，development team要提交到QA那邊進行測試，通常是2個星期到一個月左右，隨項目大小不等，QA測試結束之后，如果沒有重大的問題，則提交作Integration Test，以保證在模擬的實際環境中能正常工作，最后，如果沒有什么問題的話則作Release Build以形成發布版本。對于公司里有一些Team使用敏捷編程的，則需要增加所謂的Commit Test Build，也就是developer在作每一個checkin的時候自動觸發一個build，以保證build不會被這個checkin破壞（包括不會破壞unit tests和code quality)。這也是所謂的要作continuous testing和continuous code quality analysis，這些都是通過利用JUnit, NUnit，CheckStyle, PMD，Cobertura，FxCop等工具來實現的。我們在后面也會講到，這里略過。這個環節里，個人比較喜歡AntHill Pro和QuickBuild，這兩個工具都是比較強調流程的，尤其是AntHill Pro更是將其作為賣點。AntHill Pro以工作流的模式來定義這個流程，一個項目可以定義多個的workflow，對應于我們的case，就是定義Daily Build的workflow，定義QA Build的workflow，等等，然后在作promote的時候，通過選擇不同的workflow來達到目的。而QuickBuild則是利用已有的configuration的概念，定義不同的Configuration，然后在Configuration的setting里定義一個或多個要promote的configurations。要作promote的時候，則通過點擊某個build的promote按鈕將其promote到指定的configuration上去，也很方便。使用AntHill的模式，概念上很清晰，因為我們要作的是流程管理嘛，所以workflow會聽起來比較容易接受。而QuickBuild則是把它綁定在Configuration上，使用起來比較簡單，但是找起來要費點事，至少對于我而言是這樣。Hudson也有類似的流程管理，但是它是自動的，而promote在我們這里是需要人來作review的，也就是說要人去參與，判斷究竟使用哪個版本來promote，所以在我們這里，不是很合適。

在配置項目這個環節里，個人感覺QuickBuild比較靈活，既可以做到很簡單的配置，也可以做到非常復雜的配置，而且配置起來方便性非常好。只是術語與其它的CI Server有些不同，需要熟悉一下。

Build功能

CI Server最重要的就是Build本身的功能，包括SCM的連接，用戶的權限管理，Build工具的支持。首先我們來看看SCM的支持。

SCM支持

在這些CI Server中，AntHill Pro和Hudson支持的種類最多，尤其是Hudson，基本上市面上的SCM都有所支持。對于象比較常見的Subversion，CVS，ClearCase，StarTeam，SourceSafe等，各家都已經支持了。而在上一項目中表現較好的QuickBuild，則屬于在SCM里支持最少的一家，它還不支持git，Team Foundation Server，這個目前已經很流行的兩種SCM，實在有些遺憾。不過瑕不掩瑜，QuickBuild在支持SCM的時候，由于使用變量的支持，卻是多家CI Server中最靈活的一家，它可以使用變量來配置SCM的URL，而其它的，則是通過定義一個基本的URL，然后針對不同項目來定義各自的SCM repository。而QuickBuild還有一個它自有的QuickBuild Repository，用于在不同的Configuration中傳遞artifacts，實際用起來也很方便，比如說我們在一個項目里要用到別的項目的artifacts，那么就可以定義一下這個repository。當然，這個功能也可以通過Maven的repository來完成來達到相同的目的。TeamCity也提供了類似的機制，只不過TeamCity的Repository其實就是一個Ivy的擴展。

SCM的數據在這些CI Server中都有體現，從每一個Build的change sets到歷史統計。說明現在大家都很重視對于這些數據的收集和分析。其中TeamCity能直接從Web頁面上直接調用IDE來打開這些改動的文件是一大亮點，畢竟是做IntelliJ的公司啊！

用戶管理

這個基本上是每個CI Server的必備功能了，基本上都是既可以用內置的數據庫管理（Hudson好像沒用數據庫），又可以連接LDAP服務器。我只是簡單測試了一下，沒有深入，也就沒有什么發言權了。

Build的Dependencies管理 (Dependent Builds)

在實際的項目中，我們常常會出現項目之間的依賴關系，比如說A項目依賴于B項目，B項目依賴于C項目。所以當我們要編譯A項目的時候，我們需要先編譯C項目，然后編譯B項目，最后再來編譯A項目，這樣做的好處顯而易見，就是保證我們總是使用最新開發的code來編譯一個版本，如果發生了什么問題，我們也可以很容易的知道究竟是哪個項目break了整個build的流程。這個功能基本上所有的這些CI Server都有提供，而能力各有千秋。TeamCity在這里屬于最弱的一個，它只能通過定義Ivy來達到Artifacts在不同項目中的依賴管理，而AntHill Pro，Bamboo和QuickBuild則都有提供兩種類型的dependency管理，即artifacts和項目本身的依賴管理。不過TeamCity卻有另外的殺手锏，就是導入項目的功能，它支持從IntelliJ的項目，Maven的項目中直接導入創建這種依賴關系。

分布式Build Pool

由于公司的項目繁多，平臺繁多，對于一個項目需要分布到不同的平臺去編譯，測試，這時候就需要建立一個Build Pool了，基本上上述各家的CI Server都已經支持了這種分布式的build pool，其實質是利用了grid computing技術來進行管理。也就是一個build server帶上一群的build agent，然后把build的任務分布到不同的agent上去執行。在這里不得不再贊一個QuickBuild了（呵呵，這個QuickBuild好像給人驚喜不斷啊），其實QuickBuild的agent與其它家的倒沒什么不同，只不過就是一個computing unit，關鍵在于QuickBuild里配置一個configuration，它使用了step的概念（這個QuickBuild的術語倒是不少嘛），這個step在AntHill Pro里也存在，關鍵在于這個step是可以分布的，也就是說，我配置一個項目的時候，可以定義一系列并行的分布式的step，這樣對于管理和收集artifacts非常方便，我們可以定義Test On Windows, Test On Mac, Test On Linux，然后設置一下運行這些step的時候需要什么類型的agent，QuickBuild就可以把這些任務分布到這些平臺的agents上去運行了。而其它家的可能是因為收費的方式，象TeamCity，一個build只能在一個agent上運行，我如果要做到同樣的效果，就需要定義出三個項目，然后讓這三個項目在不同的agents上運行，最后，還要再定義一個項目，讓這個項目去收集它們的artifacts，非常麻煩。Bamboo和AntHill也類似于TeamCity。而Hudson在這塊的能力很弱，個人感覺不如其它的產品強大，而且使用起來也更復雜一些。

Report功能和統計

上述各家CI SERVER都提供了Report的功能和統計的功能，在這個領域里，Hudson毫無懸念的是支持報告類型最多，最全的（誰叫咱OpenSource呢，有的是人開發）。Bamboo屬于支持報告類型最少的，不過也有很多第三方的plugin供選擇。我們所關心的幾個reports都有被各家支持，其中QuickBuild的report給我的感覺最華麗，不過好像是參考google analytics來的，從界面上看和analytics簡直就是一個翻版。在使用上，QuickBuild和TeamCity的最方便，直接點報告中的鏈接就可以作一些過濾。在統計信息方面，各家對tests的統計都非常完備，這也從一個側面反應出test driven現在那是深入人心啊。在支持Test Driven方面，TeamCity是力拔頭籌，得益于開發IntelliJ的經驗，TeamCity不僅可以自動尋找出項目中的unit tests（你不用在Ant腳本里調用junit task，或者在Maven里調用surefire），而且對于上次運行失敗的test cases，它可以在下次build中自動先運行，這樣就可以避免一個build運行了很久才發現上次失敗的test還沒有被更正過來呢，強！

另外，要提一下的是QuickBuild中那個Build的Dashboard我非常喜歡，對于一個項目當前的狀況可以一目了然，有多少個tests成功了，多少失敗了，多少被fix了，多少還沒有fix，總之，信息很豐富，不過就是配置起來有點復雜，需要我去一個報告一個報告去加step，如果能做到TeamCity的程度，簡直就是完美了。

對于其它的CI Server則是亮點不多（其實也很強，只不過是對比而言，我覺得TeamCity和QuickBuild更強，更好）。

與第三方工具的集成

在與第三方工具的集成中，Hudson遙遙領先，是所有CI Server里Plugin最多的。可以和FaceBook，Google Calendar，Twitter，反正基本上你能想到的，它都有。不過對于我們而言，好多Plugin沒有太大的價值。Bamboo在與它自己的幾個產品中集成度也非常好，比如說Jira，Wiki，Clover等。這幾個我們公司都有用到，在這點上非常理想。

價格

不得不考慮一下價格的因素，好像記得有人說過，Price is nothing, but price is everything，尤其在這個金融危機的年代里。這點，勿庸置疑，OpenSource永遠是最好的。而在商用的這幾個里QuickBuild最便宜，它使用的是Site License，一個Site收$2999，AntHill最貴，我詢問了一下，按我的配置，隨便搞搞就要$10000了，TeamCity的入門也很便宜，$1999帶3個agents，可是針對我們的情況，算了一下也要上$8000了（它是按agent收費的），Bamboo也很貴，按照它的功能而言，我覺得性價比不是很好。

總結

綜合各方面因素的考慮，我們最終選擇了QuickBuild，雖然這個產品名聲不是很大，不過想想它的客戶中，不乏象Cisco，HP這樣級別的公司，應該還是可以值得信賴的吧。另外就是我們使用下來覺得它還是擁有諸多亮點，對于我們的統一管理來說，可謂是方便至極。另外價格方面考慮也很不錯。當然如果你的團隊不是很大，那么選擇QuickBuild的Community Edition和TeamCity的Professional Edition都是非常值得的，這兩者都是免費的，而且QuickBuild的Community Edition功能沒有任何裁剪，只是限制了一下configuration的數目，非常適合要求比較高而項目不是很多的團隊。

好了，有太多太多需要討論的東西了，CI這個領域現在還處于高速發展階段，本文純屬探討，歡迎大家拍磚。由于時間有限，對每個產品了解的不是很深入，錯誤在所難免，如果我有什么地方不是很準確，也歡迎告訴我。