當我們討論Jenkins文件結構的時候，要知道在基于像Jenkins這樣的圖形用戶界面工具和DevOps的基礎設施即代碼原則之間經常會發生阻抗失配(impedance mismatch)。

中培的龔老師認為，理解這個問題的一種方法是：雖然Jenkins任務描述器基于文本文件，但它們并不是改變任務描述的主要界面，web界面才是。這種方式利弊參半。

Jenkins的既存構建之上創建定制的解決方案很容易，并不要求你非常熟悉Jenkins。 另一方面，Jenkins的開箱即用缺乏我們在程序世界中常用的許多功能。例如繼承甚至定義函數這樣的基本功能在Jenkins里需要大量工作。

GitLab的構建服務器功能，用的是另一種方法。構建描述器從一開始就只是代碼。如果并不需要Jenkins提供的所有能力，GitLab的這個特性值得你一看。

按依賴順序構建 

因為構建的一部分可能會依賴于其他部分，許多構建工具都有構建樹的概念：為完成構建而有順序地構建依賴。

在像Maven這樣的工具里，構件圖來源于由我們為工件設置的依賴。另一個Java構建工具Gradle，也會在構建之前先創建一個構件圖。

Jenkins支持在web界面上可視化Maven的構建順序，在Maven術語里稱為反應器(reactor)。可惜，這個界面并不支持Make類型的構建。

構建階段

Maven構建工具的主要優勢就是它把構建流程標準化了。

這一點對大型企業來說非常有幫助，因為它不需要再發明自己的構建標準了。其他的

構建工具實現各種構建流程一般更加隨意。Maven的嚴苛有好有壞。有時，剛開始用Maven的人們會懷念像Ant那樣工具所帶來的自由。

你可以用任何工具來實現這些構建，但是當工具本身不強迫構建、測試和部署的標準順序時，很難還能保持習慣。

我們就應該注意的是，測試階段是非常重要的。持續集成服務器需要在捕捉錯誤方面表現出色，而自動化測試是實現這個目標的關鍵。

可選的構建服務器

雖然以我的經驗來看，Jenkins在構建服務器上是絕對的主流，但是它絕非不可替代。

Travis CI是一個托管方案，流行在開源項目中。Buildbot是一個用Python編寫和配置的構建服務器。ThoughtWorks出品的Go服務器是另外一種可選方案。Atlassian提供了Bamboo。GitLab現在也支持構建服務器功能了。

當評估不同的方案時，留意不要被供應商套牢( vendor lock-in)了。也要記住構建服務器并不會取代那些已經在本地開發機上表現良好的構建需求。

還有一個經驗法則：看看工具是否可以通過配置文件來配置。雖然管理人員容易被圖形化配置所打動，但是開發和運營人員不會喜歡被要求使用一個只能通過圖形用戶界面配置的工具。

校驗質量指標

構建服務器的一個用途是校驗軟件質量指標。Jenkins對此有一些內置的支持。可以在一個任務頁面上執行并可視化Java的單元測試。

另一個更高級的可選方案是使用Sonar代碼質量可視化器，參見下圖。Sonar測試在構建階段運行并傳送到Sonar服務器上，在那里進行存儲和可視化。

一臺Sonar服務器是一個讓開發團隊看到他們努力改良代碼庫的成果的好辦法。

Sonar服務器的缺點是有時會減緩構建速度。建議每天夜里運行一次Sonar構建。

構建服務器制造了大量可以顯示在公共顯示器上的數據。若是構建失敗的時候能夠立即察覺，就會有很大幫助。

第一步僅僅是連接一個類似資訊站( kiosk-like)那樣的顯示器，有一個web瀏覽器指向你構建服務器的web界面。Jenkins有許多插件可以為資訊站顯示提供簡化的任務概覽。它們有時被稱為信息輻射體( Xnformation rzadiators)。

連接構建狀態到其他類型的硬件上也很常見，例如熔巖燈或者多彩LED燈。

以我的經驗來看，這種類型的顯示可以讓人們對構建服務器充滿興趣。盡管保持長期使用比開始擁有更加困難。如果你想把屏幕放到一個不容易被看到的地方以避免分心，那么做這件事就變得毫無意義了。

慎重放置熔巖燈和屏幕的組合非常有幫助。熔巖燈并不常亮，所以沒那么吸引人。當一個構建失敗發生時，它亮起來了，于是你就知道你應該看一看構建信息輻射體了。熔巖燈甚至能夠表達構建質量的歷史記錄。當熔巖燈亮的時候，它會發熱，過一會兒，熔巖在燈里環繞。當錯誤被修復，燈冷卻了，但是熱量還會存在一小段時間，所以熔巖還會環繞一段時間，視修復構建錯誤的耗時而定。

想了解更多IT資訊，請訪問中培偉業官網：中培偉業