持續集成工具的選擇-裝載(2)

　　另外配置一個項目要配的就是項目持續集成的流程管理，在我們這里，基本上是這樣一個流程: 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在這塊的能力很弱，個人感覺不如其它的產品強大，而且使用起來也更復雜一些。

原文轉自：http://www.kjueaiud.com