由于有許多持續集成服務(CI)服務器可以選擇,所以很難決定哪個適應自己。在 讓開發自動化 系列的第二篇文章中,開發自動化專家 Duvall 采用一致的評估標準和很多說明性示例,介紹了一些開源 CI 服務器,包括 Continuum、CruiseControl 和 Luntbuild。
在我腦海里,我至少能想到 12 種在當前市場上可用的 CI 服務器,包括商業的和開源的。雖然它們都試圖自動進行軟件構建的過程,但是都有各自的優點和不足。而且,有太多工具可供選擇的不良后果就是很難決定究竟應該選擇使用哪個。
在選用自動化過程的工具時,要時刻記住的就是:工具要 確實適用。選擇錯誤的工具可能會限制整體的靈活性,會導致執行簡單動作反而需要更長時間,或者會把人鎖定在特定的支持工具或過程。
通常,對一個新工具的決策分析可以歸結如下:
我聽說 Tim 在使用 Acme Inc 的工具,而且我認為 Tim 是個聰明人。所以,我也要使用 Acme Inc 的工具?,F在我也是個聰明人了。
![]() |
反過來,如果您問 Tim 為什么 他選擇使用 Acme Inc 的工具,您可能會發現是他的公司強制要求使用的。這就是為什么重要的是要根據 自己的 具體技術和政策需求對工具進行分析。如果不這么做,可能就會選擇到不符合需求的工具,甚至更糟糕的是,不能帶來任何幫助的工具。
在決策的時候,通常多數人都會把重點放在工具的特性上。但是要記住,雖然特性的確重要,但還有其他指標需要考慮。在我的實踐中,我發現以下五個指標在評估工具時最有幫助:
![]() |
|
而且不要忘記,客觀地 檢查這五個方面也是重要的。
說到 CI 服務器的特性,應當考慮該工具與版本控制系統的集成、處理構建平臺(例如 Ant 和 Maven)的能力以及提供反饋和報告的能力。而且不要忘記檢查其他特性,例如構建標號和管理項目的依賴項。最后,在需要做一些特定的增強時,理解產品的可擴展性會很有幫助。
表 1 詳細說明了每個特性:
特性 | 解釋 |
---|---|
版本控制系統集成 | 如果工具不支持您所使用的特定版本控制系統,您真的會為它編寫一個定制集成么? |
構建工具集成 | 在選擇 CI 服務器時,需要考慮目前或將要使用哪個構建工具。對于 Java™ 編程,有兩個自然的選擇:Ant 和 Maven,幾乎所有 CI 工具都支持它們。如果構建系統既不是 Ant 也不是 Maven,那么 CI 工具支持從命令行運行程序的功能么? |
反饋和報告 | 想想老話 “如果樹倒在森林中,能有人聽到么?” 如果構建失敗,會有人知道么?如果沒人知道,那么使用 CI 工具的目的是什么?所有的 CI 工具都提供一些通知機制,但是哪個最適合您呢?電子郵件?即時消息?RSS? |
標號 | 有些開發團隊喜歡跟蹤構建,給構建一個唯一的標號,這樣日后就能找到具體的構建實例。如果這對您來說很重要,那么要注意只有少數 CI 服務器提供了這個功能。 |
項目依賴項 | 某些情況下,在構建了一個項目之后,可能需要構建其他依賴項目。有些 CI 服務器支持這個特性,有些不支持。 |
易于擴展 | 擴展工具當前的功能有多容易?是否用插件就可以實現簡單的擴展,還是總得修改代碼? |
從特性的角度來說,以上提到的幾點在選擇所需要的正確的 CI 服務器時,至關重要。
因為下載和使用開源 CI 服務器很簡單,所以可以試用產品來判斷它的可靠性。而且,在工具的可靠性和它在市場上的時間之間,通常存在一些相關性。使用新產品時,就會冒著有未發現的 bug 的風險。而且,用戶群是發現工具出現的問題的優秀資源。大量的問題貼子或者過多的復雜問題,就表示用戶對這個工具的意見較大。
因為我這里討論的服務器是開源的,所以很容易發現下載的人數,這也會是產品健康程度的一個指示。用戶少可能意味著反饋渠道少,可能需要換個地方看看。
在下載 CI 服務器之前,了解這個服務器未來的前景會有幫助。簡單地說,使用已經死亡或正走向死亡的產品不是個好主意??梢詸z查該工具已經出現了多少年、在它的用戶群中是否有正常數量的活動。就像可以從用戶群來判斷產品的可靠性一樣,活躍的社區是工具未來前景良好的征兆。
CI 服務器不能在 所有 環境下工作。需要考慮服務器支持哪個操作系統以及具體的系統需求。例如,如果工具是用最新版本的 Python 編寫的,那么需要確定這個版本 Python 能夠用于自己的操作系統。
產品的易用性可能是最主觀的指標。有些人愿意手工修改配置文件,而有些人想讓所有管理任務都在應用程序中執行,例如 Web 控制臺。有些服務器要求從一個屏幕單擊到下一個屏幕來執行簡單的管理,而其他服務器則提供了直觀的向導。
如果想理解 CI 服務器的具體細節,那么漂亮的管理 Web 表單就不重要了;但是,如果人手不足、工作繁忙,那么可能不會想在管理 CI 服務器上花太多時間。
記住我在這節討論的五個方面,再來看一下三個 CI 服務器:Apache 的 Continuum、CruiseControl 和構建管理服務器 Luntbuild。
Continuum 是最新的 CI 服務器之一,也是值得關注的一個新進入者。Continuum 的安裝和配置很簡單:只要下載和釋放 ZIP 文件,運行命令行程序,就可以運行了?;?Web 的界面使得配置項目很容易。而且,還不需要安裝 Web 服務器,因為 Continuum 內置了 Jetty Web 服務器。并且,Continuum 可以作為 Windows 服務運行,還在應用程序的某些部分嵌入了上下文敏感的文檔,從而提供了很多幫助。
![]() |
|
在使用 Continuum 時會注意到的第一件事就是它的易用性。能夠在幾分鐘之內就把服務器運行起來并讓它去查詢修改。實際上,在 Windows 上啟用 Continuum 只需要四步:
Continuum 內置支持五個版本控制系統:Subversion、CVS、StarTeam、Bazaar 和 Perforce。也部分地支持其他版本控制工具,例如 Visual Source Safe 和 ClearCase。 Continuum 還支持四種構建機制:Ant、Maven1、Maven2 和 Shell(命令行)。
在第一次訪問 Continuum Web 應用程序時,默認是 guest 帳戶。guest 提供了對所有項目的只讀存取,沒有管理或配置項目的能力。但是,可以很容易地創建 Administrative 用戶,然后設置一些適用于所有項目的屬性。
圖 1 顯示了管理頁面,它提供了管理所有項目的 Continuum 設置的能力,包括創建 Admin 帳戶、構建的輸出和部署目錄:
對 Continuum 進行配置讓它監視項目也非常簡單。簡單到僅僅是選擇期望的構建平臺,例如 Ant 或 Maven2,然后把 Continuum 指到期望的版本控制系統。
圖 2 顯示了設置 Ant 項目時需要填充的字段:
在保存了這個信息之后,Continuum 每小時查詢版本控制系統一次??梢孕薷捻椖康脑O置,查詢得更頻繁或更少些。我們在這里談到的是 持續 集成,我建議每五 分鐘檢查修改一次,而不要每小時一次。
默認情況下,在使用 Ant 時,Continuum 在項目的根目錄查找項目的 build.xml 文件。如果使用不同的名稱或者這個文件不在項目的根目錄,可以修改這個設置。
雖然 Continuum 還是 CI 舞臺上的新人,但是它以其易用性和對當前眾多流行的版本控制系統和構建工具的支持,還是給這一領域帶來了巨大的沖擊。我希望在未來的版本中會有添加和查看報告的功能。
原文轉自:http://www.anti-gravitydesign.com