使用 Jenkins 實現軟件開發的持續集成

轉自：http://www.ibm.com/developerworks/cn/java/j-lo-jenkinsintegrate/

Jenkins 是一種易於使用的持續集成系統，它可使開發者從繁雜的集成過程當中解脫出來，專一於更爲重要的業務邏輯實現。同時 Jenkins 能實施監控集成中存在的錯誤，提供詳細的日誌文件和提醒功能，還能用圖表的形式形象地展現項目構建的趨勢和穩定性。本文主要介紹了傳統開發中的存在的一些問題及 Jenkins 在開發流程中的優點，並用實例爲你們詳細介紹了自動化持續集成的開發步驟。

 

傳統開發流程存在的一些問題

開發團隊在平常工做中，主要是圍繞着需求、編碼、代碼提交、打 build、分配環境、安裝 build、BVT(Build Verification Test)、發現 defect、修復並提交新代碼，而後重複進行打 build 到 BVT 測試的工做，在這個過程當中，大部分工做的串連仍是須要人工進行操做，且軟件開發週期比較漫長。

對於以上存在的問題，分析起來主要有如下幾個緣由：

首先，傳統的開發團隊中須要一個專門從事 build 構建的人員，負責整個開發團隊的代碼集成，並打包成應用程序，再進行 BVT。這個過程很是耗時，重複性高，週期長。由於 build 構建的人員須要等待全部開發人員完成代碼的交付後才能夠進行這部分的工做，而在實際開發過程當中，每每在代碼交付前還存在一些問題，不但使得 build 構建的工做須要加班或者延期，且這樣等待完成的 build 再拿到測試部門進行測試，開發人員再進行缺陷修復，再到產品交付，整個軟件開發週期會耗用更多時間。

其次，每次構建 build 的過程當中，雖然構建 build 自己是能夠實現代碼自動化的，可是在作完 build 後須要上傳到一個公共的地址，再分配環境進行安裝。安裝完成後的 BVT，須要在每次 build 構建後反覆的一次次進行，這些過程包含了太多流程重複及人工資源佔用。

面對以上存在問題，咱們使用 Jenkins 持續集成卻能夠實現整個流程的自動化，即自動構建 build，上傳到指定地址，再下載安裝包到指定的環境中進行安裝，並進行 BVT 測試。這個流程能夠設置每日定時進行，這樣就能夠加快整個開發過程，使得每一個開發人員更好的掌握和控制開發流程。

 

回頁首

Jenkins 是什麼？

簡單的說，Jenkins 是一種基於 Java 開發的持續集成工具，前身稱做Hudson，它是一個開源軟件項目，提供了用於監控持續重複工做的軟件平臺。Jenkins 發佈和運行的形式都很簡單，您能夠去 Jenkins 官網下載安裝包後，只需一個「java -jar jenkins.war」命令就能將其運行起來。

 

回頁首

Jenkins 持續集成在開發流程中的優點

持續集成開發的流程相對於傳統方法有不少不一樣，在軟件開發流程中有不少優點：

第一，快速迭代。

因爲 Jenkins 集成開發開發過程當中，整個流程能實現自動化，每日能夠自行生成新的 build，在軟件項目被分紅多個子項目後，這些子項目多是一些獨立運行的小項目，也多是互相聯繫的。因爲每一個功能能夠一點點的加在 build 中，那麼這樣就能保證每次的新 build 能夠交付新的功能，保障測試人員能一直有最新的 build 進行測試，從而使產品的缺陷可以在更早的時間裏被發現，開發人員修復起來也更加容易，甚至能夠在修復產品的過程當中避免後續可能隨之產生的問題，確保產品在整個的開發過程當中更加積極、有效。同時，經過快速迭代，開發人員能夠對產品的用戶和市場趨勢保持較強敏感度，且產品也在不斷的迭代中越發成熟，可使用戶持續保持最好體驗感；

第二，適應變化。

因爲持續集成開發過程當中代碼是每日集成生成 build, 產品功能是逐步增長的，這樣使得開發人員能夠積極應對軟件需求的多變性。根據用戶的需求能夠隨時增長新的功能而不會對整個項目產生過多的影響，根據用戶的反饋狀況及時調整開發方向，下降項目風險，保證市場競爭力。這樣，經過用戶的評價和反饋來更好的完善、適應市場變化而生產出的產品纔是最有生命力的產品，Jenkins 持續集成開發流程，無疑給實驗室的開發人員提供了很多的看法與幫助；

第三，創建團隊信心和提升開發人員的創新能力。

傳統的開發流程須要在項目經理的管理下，嚴格地按照計劃進行，長期過程當中，這種模式會限制開發成員的創新能力。Jenkins 集成開發能夠持續不斷的發現問題，測試和驗證功能模塊的開發程度，加強開發人員對整個開發過程的瞭解和信心，同時還能快速實現開發人員的創新想法，及時在用戶那裏獲得反饋，而且還能夠在迭代的過程當中不斷優化。這些均可以帶給開發人員更多的機會嘗試和信心鼓勵，對於產品的最終完成起着很是重要的做用。

綜上所述，這些優點給整個軟件開發團隊帶來的好處是不可小覷的。那麼如何將 Jenkins 自動化持續集成應用到開發流程的實際工做中呢？下面咱們經過一個示例來演示具體的操做步驟。

 

回頁首

Jenkins 自動化持續集成開發的步驟

安裝 Jenkins

關於如何下載並安裝的內容在上文介紹 Jenkins 部分已經有交代過，在此再也不重複闡述。然而，須要注意的是，在安裝前，須要檢查機器的 JRE 版本是否在 1.6 或以上，若不是，須要升級或下載新版本後才能保證 Jenkins 的正常運行。

啓動 Jenkins

經過命令行進入安裝包所在的目錄，運行「java - jar jenkins.war」命令來啓動 Jenkins。成功啓動後的界面狀態以下圖所示。

圖 1. Jenkins 成功啓動

訪問 Jenkins

訪問 Jenkins 的方式分爲兩種：第一種是在安裝 Jenkins 的機器上訪問，即 master 上直接訪問，使用的地址爲：http://localhost:8080；第二種是在其它任何一臺機器上遠程訪問，使用的地址爲：http://IP:8080，這裏的 IP 是指 Jenkins 安裝所在的機器 IP 地址。在實際應用中，用戶能夠根據須要任意選擇一種訪問方式，並且，多個不一樣的用戶能夠同時訪問一個共同地址互不干擾地進行本身的操做，能夠說 Jenkins 提供的這種訪問方式給用戶帶來了很大的便捷。

創建 Jenkins 自動化持續集成項目

建議開發部門能夠選用一臺固定的物理機或者虛擬機做爲安裝 Jenkins 的機器，機器須要有鏈接外網的功能，這樣方便下載和更新一些須要使用的插件。

安裝插件

通常狀況下，常使用到以下這些插件：

vSphere Plugin：針對那些使用了 vSphere 虛擬化的基礎設施，這個插件提供了實現「雲」功能的工具。

SSH Plugin：這個插件使用 SSH 協議執行遠程 shell 命令。

RTC Plugin：這個插件集成了 IBM 的 Rational Team Concert(RTC) 與 Hudson。

Team Concert Plugin：集成了 Rational Team Concert。

Multijob Plugin：這個插件是一個將多個項目鏈接在一塊兒的插件。

創建項目一：Request Build

即從統一代碼庫下載最新代碼，自動構建應用程序包，上傳到統一的地址。

構建程序包有兩種方法，一種是使用 RTC Plugin 和 Team Concert Plugin 來鏈接開發人員代碼所在的統一代碼庫。咱們能夠建立一個 Job，選擇 Job 類型是 Build a free-style software project，將 Project name 命名爲 Request Build，並選擇在 master 上執行這個 Job。採起這種方式的時候，須要在 Job 進行配置以前，進入 Configure System 配置系統信息，以下圖所示：

圖 2. 系統配置中 RTC 的信息

系統信息配置完成後，再對 Request Build Job 進行設置。Source Code Management 配置的信息以下圖所示：

圖 3. 項目 Request Build 中 Source Code Management 的配置

這種方式中的代碼資源管理是經過開發人員使用本身的帳戶鏈接到 RTC，從 RTC 抓取最新代碼到 master 上的 Jenkins 目錄中，Jenkins 會建立一個 workspace 來存放這些代碼。

接下來，再將抓取的代碼在 master 上自動構建成應用程序包，須要使用到 build XML 文件和相關的屬性信息。而後，繼續在 Request Build Job 的 Build 選項中進行設置，以下圖所示：

圖 4. 項目 Request Build 中 Ant 相關的配置

上圖中設置的 Properties 信息只是一個示例，讀者須要根據 build 過程當中使用的具體值來進行修改。

到這裏，項目一設置完成，保存後點擊 Build now 按鈕就能夠 kick off Build 了。至此，咱們講的都是採用第一種方式來完成項目一的任務。然而對於第二種方式，簡單來講，就是將 Jenkins 代碼管理的工做用命令來實現，這涉及到構建程序包的開發人員的工做內容，不是本文的重點，故而不詳細敘述如何來寫這樣的命令，讀者有興趣能夠自行研究。

因爲第二種是利用已經完成的，包含着能實現代碼管理和構建程序包命令的文件來實現自動下載代碼和構建程序包的工做，因此先假設這個文件名爲 requestBuild.bat 或者 requestBuild.sh。一樣，咱們在 Jenkins 上建立一個叫 Request Build 的 Job，選擇在 master 上執行任務的話，本文中的 master 是 windows 機器，因此文件爲 requestBuild.bat。在 Build 選項中選擇 Execute Windows batch command，填入執行 requestBuild.bat 的 bat command，保存 Job 後點擊 Build now 就能夠進行代碼下載和構建程序包的過程了。

這樣項目一的任務就完成了。讀到這兒您可能會有疑問，打好的安裝包是怎麼上傳到特定的地址呢？關於這個問題，是 kick off Build 的內容，在 build XML 文件和圖 4 Properties 中有設置。

創建項目二：Download build to install server(Specific build)&Install build

即 download Build 到須要安裝的環境上，自動安裝軟件。

這個任務分爲兩個 Job 來實現，第一個 Job 命名爲 Download build to install server(Specific build)，主要是從上文中提到的特定地址下載須要的文件到安裝環境上。一樣，這裏指定這個 Job 在 master 上執行。爲了提高下載過程當中的靈活性，能夠給 Job 設置 build with Parameters，這樣在執行這個 Job 的時候能選擇下載哪些內容。以下圖所示：

圖 5. 項目 Download build to install server(Specific build) 的參數配置

上圖中設置的信息，例如，FileList 是須要下載的文件的文件名稱，buildTag 是下載的 build version。這些是使用 String Parameters。Password 是使用 Password Parameters。

除了設置參數之外，Job 的內容是爲了實現下載 Build 到指定的安裝環境中。在 Build 選項中點擊 Add build step 選擇 Execute shell script on remote host using ssh，在 SSH site 中填寫的機器上執行 Command 中的命令，將 build 下載到 install server 這臺 Linux 機器的環境上。下圖列出瞭如何配置的信息：

圖 6. 項目 Download build to install server(Specific build) 的 Command 配置

完成配置後保存，點擊 build with Parameters，填上須要下載 build 的版本和文件名，就能夠將 build 下載到 install Server 這套環境上。

而後，下載完成後要進行安裝的操做，這時候，須要創建第二個 Job，命名爲 Install build，也是在 master 上執行這個任務。這個 Job 經過 Command 中添加安裝的 shell 命令來執行自動安裝的過程。以下面圖 7 給出了詳細的信息。

圖 7. 項目 Install build 的 Command 配置

運行這個 Jenkins Job 的時候，還能夠在 Job 的 Console Output 中查看運行日誌，監控軟件安裝的狀態。這樣，就實現了軟件安裝的過程了。

在兩個 Job 按順序執行完成後，下一步須要作的是對安裝好的軟件進行 BVT 測試。

創建項目三：Run BVT Automation case

即調用批處理文件，自動進行 BVT 測試。

建立一個 Job，project name 命名爲 Run BVT Automation case。本文例子中的測試機的類型是 windows 機器，因而選擇 Add build step 中的 Execute Windows batch command 選項，經過在測試機器上運行 bat 命令來實現測試用例的運行。配置信息很簡單，以下圖所示：

圖 8. 項目 Run BVT Automation case 的 Windows command 配置

在這裏須要注意的是，仍然要選擇執行 Job 的位置是在 master 上仍是 slave 上。若是測試用例的代碼不在 master 上，能夠選擇測試機器做爲 Jenkins 的 slave 節點。在 Manage Jenkins 選項中點擊 Manage nodes 來建立 slave 節點，命名爲 Test_node，建立完成後即可以在 Run BVT Automation case Job 中選擇執行的地方是 Test_node 的 slave 節點。

配置信息完成後，保存並運行 Job，Jenkins 就會經過上圖中的 DDtest.bat 來運行測試用例。同理，爲了追蹤測試用例執行的狀況，能夠從 Job 的 Console Output 中查看運行日誌。固然，這個任務是否可以順利執行，還須要提早準備好測試代碼。本例中的測試代碼是一個獨立的 Java 工程，bat 文件能夠在測試機器上手工運行，進行 BVT 測試。Jenkins 只是將這個手工操做包裝了一下。

在上述三個項目完成後，咱們會思考怎麼將這幾個流程串連起來呢？

如何將不一樣的項目聯繫起來？

文章前面提到的 Multijob Plugin 插件就是來解決這個問題的，安裝 Multijob Plugin 插件後，就能夠創建 Multijob Project。這裏創建一個名爲 Jenkins automation for development 的項目，並選擇在 master 上執行這個 project，在 project 中配置須要串連起來的 Job 名稱，在運行這個 project 的時候，就會順序地將幾個不一樣的 Job 一個個執行起來。

作點錦上添花的事情

在整個 Jenkins 持續集成的自動化流程中，仍然有不少須要改進的地方，筆者也在不停探索，先列出下面幾點以供參考：

• 設置 Email Notification

使用 MultiJob Project 後，Jenkins 就能夠自動運行整個流程，那麼若是可以在執行結束後自動給用戶發一個通知的信息就再好不過了。這就須要在 Jenkins E-mail Notification 中配置，Reply-To Address 中填上收件人的郵箱，Charset 的內容爲 UTF-8，並經過 Test configuration 按鈕來測試是否成功發送到郵箱。

• 準備環境

在開發和測試過程當中都須要準備環境，咱們能夠經過使用 Jenkins 的 vSphere Plugin 來實現虛擬機環境的回滾，不過，這裏仍然須要在 VMware 查看 Snapshot Name。首先須要在系統配置中設置 vSphere Cloud 的信息。例如，vSphere Host、爲這個 vSphere Cloud 命名、登錄的用戶名、密碼等。而後，再建立準備環境的 Job，在 Build 中設置 vSphere Build Step 各個選項中的值。其中，Server 信息就是剛剛 vSphere Cloud 的名稱，vSphere Action 是回滾環境的話就選擇 Revert to Snapshot，Snapshot Name 能夠從 VMware 中得到。這些關鍵信息完成後，運行 Job 就能夠爲安裝 build 和測試提供可執行的環境了。

• 參數的使用

這裏的參數和日常說到的變量很相似，也有局部和全局的概念。全局的意思即在系統配置中能夠設置 Global Choice Parameter，而在具體 Job 中設置的 Parameter 應用範圍只在當前 Job 中。參數的種類也有不少，在這裏便再也不闡述，讀者能夠在實際使用中視狀況選擇。

 

回頁首

結束語

Jenkins 持續集成給開發團隊帶來了不少便利，在這裏咱們只是初步的總結，爲了讓 Jenkins 持續集成的功能更加完善，還須要不停的實踐和探索。但願經過本文的介紹讓更多的軟件開發人員和測試團隊瞭解持續集成的平臺所帶來的好處。在當今軟件產業迅速發展的趨勢下，軟件開發團隊也正在經歷着相應的發展和改變，做爲程序員的咱們，不只要開發出一個個新的軟件，也要利用已經存在的軟件工具來提升咱們的工做效率，從容應對瞬息萬變的市場。