jenkins+python持續內建1.安裝 2.配置 3.簡單使用

搜尋jenkins,進入官網，5分鐘以内相信你能找到适合你作業系統的安裝步驟。此處為省事，列出centos步驟(注意安裝穩定版)

不要問service start xxx和systemctl（centos7引入）啥關系，後者是用來替代前者的。具體問百度。啟動後，驗證安裝是否成功，浏覽器通路http://localhost:8080/，看到老爺爺(jenkins logo)就行。

要是遇到奇葩問題，看這裡 https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Red+Hat+distributions

配置前安裝必要插件：

Git Plugin：使用Git作為源代碼管理

Python Plugin：Adds the ability to execute python scripts as build steps.

Violations：代碼品質檢測，支援pylint、jslint等

配置job

1.建立-->job-->自由風格

2.填寫git 位址，觸發器選擇Poll SCM, Schedule可選

3.填寫腳本：第二行#!/usr/bin/bash/...是給jenkins看的，讓jenkins不要輸出每條指令

coverage pylint自己安裝咯

4.增加建構後操作步驟-->Report Violations--> pylint後填寫pylint.xml --->Faux Project Path填寫實際工程路徑，也就是腳本中cd的路徑

建好工程後，建構一次玩玩呗，點選建構詳情，等待建構完畢，看到代碼風格統計圖， Console Output裡看到單元測試通過情況，代碼覆寫情況。遇到問題：

初始安裝後基本都能運作jenkin并看到jenkins web頁面，否則重裝。修修改改後程序起不來，多看看權限問題，特别是修改jenkins_user

配置的job怎麼都不按預期執行，先手動指令行執行，确認無誤後檢視jenkins環境變量

需要提的一點是Jenkins比較耗記憶體，不運作任何建構任務的情況下就吃掉了300多M，再加上建構任務時會占用更多，是以建議伺服器的記憶體至少有1G，512M的話很可能在執行建構任務的時候記憶體不夠用。

下面是我用到的一些插件：

SSH plugin：遠端ssh登入server執行指令

Parameterized Trigger Plugin：觸發其他的job

Cobertura Plugin：代碼測試覆寫率報告

Task Scanner Plugin：檢測代碼中出現的特殊标記（如TODO等）

ThinBackup：用于備份Jenkins

SCM Sync configuration plugin：将Jenkens的配置變更同步到SCM中

這裡隻是集中地列舉一下，具體的使用會在下面穿插介紹。

根據本項目的需要，在Jenkins中建立了3個任務：

tm_test：用于執行測試、代碼品質檢測等

tm_staging_deploy：用于在staging伺服器上deploy代碼

tm_deploy：用于在production伺服器上deploy代碼

其中staging伺服器用于進行線上測試，staging伺服器和production伺服器的環境必須保持完全相同（當然，staging伺服器配置可以低一些）。

具體的開發、測試、部署流程是：

在開發新功能/修複bug的時候，一般是開新分支；但如果是那種很小的修改，則直接在master上改，這樣比較省事兒

新功能開發完成/bug修複後，進行單元測試+人工測試，如果通過，合并到master

每次master有變動後，觸發tm_test任務，執行內建的單元測試和代碼品質檢測，如果OK，則自動觸發tm_staging_deploy，部署到staging伺服器上

若tm_staging_deploy成功，則登陸到運作在staging伺服器的測試網站上，人工測試新功能是否OK/bug是否已修複；若tm_staging_deploy失敗，檢查失敗原因，進行修複，直至成功

若staging人工測試通過，則手動觸發tm_deploy，部署到生産伺服器上

登入到生産伺服器上進行人工測試，若出現問題，進行修複；同時密切關注Sentry發送的告警郵件，争取在第一時間修複錯誤

比較簡單，沒有采用Git-Flow/GitHub-Flow，單元測試寫得很淺，也沒有做代碼審查。不過團隊規模小，從目前來看，上面的流程是夠用的。

下面對這三個任務做較為詳細的介紹。

該任務用于執行測試、代碼品質檢測等。

每當項目倉庫的master分支有變動時，即會觸發tm_test。要做這一點，需要如下步驟：

設定tm_test的Build Triggers為Poll SCM，但不填Schedule

為項目倉庫添加Web Hook，URL填寫<code>http://&lt;Jenkins URL&gt;/git/notifyCommit?url=&lt;URL of the Git repository&gt;</code>

執行測試之前，需要确定Python版本（一般是2.7），然後根據此版本初始化virtualenv。

在建構中添加Execute shell項：

測試中需要2個庫：nose用于執行單元測試，coverage用于統計測試覆寫率。

需要在Jenkins中安裝Cobertura Plugin插件，用于生成代碼測試覆寫率報告。

然後在建構中添加Execute shell項，輸入：

其中<code>--with-xunit</code>告訴nose輸出JUnit形式的測試報告，<code>--with-coverage</code>表示同時運作coverage（這個功能相當贊），<code>--cover-package=tm</code>表示僅對指定的package執行測試覆寫率檢測，後面的<code>coverage xml</code>表示輸出xml格式的coverage報告。

然後在建構後操作中，添加如下2項：

Publish JUnit test result report：填寫nosetests.xml

Publish Cobertura Coverage Report：填寫coverage.xml

這樣一來，就可以執行測試，并得到測試報告和測試覆寫率報告啦：

上面的圖表都是可點選的，點進去後有代碼級的詳細報告，非常贊：

綠色的代碼行表示已經覆寫到，紅色則沒有。

在安裝好Pylint後，運作<code>pylint --generate-rcfile &gt; pylintrc</code>生成配置檔案，并将其中的<code>output-format</code>項的值改為<code>parseable</code>。

然後在建構中添加2項Execute shell項，

pylint：

jshint：

其中的<code>exit 0</code>是為了告訴Jenkins該指令執行成功。對于jshint來說，report選擇jslint，然後需要使用<code>$WORKSPACE</code>組成絕對路徑，否則無法看到源碼級的分析報告（是不是一個bug？）。

然後在建構後步驟中添加Violations Report，在對應位置輸入jslint.xml和pylint.xml。

最終的圖形報告如下，可以看到趨勢走向：

源碼級别的分析也有：

團隊中約定，在代碼未完成的地方使用<code>TODO</code>進行标記，因為PyCharm有一個很好的功能就是可以檢測出代碼中的所有TODO資訊：

Jenkins中也有一個非常棒的插件Task Scanner Plugin用于檢測代碼中出現的特殊标記，當然，這些特殊标記完全是可以自定義的。

安裝完該插件後，在建構後操作中添加一項Scan workspace for open tasks，根據需要填寫配置：

然後報告就可以出來啦：

如果建構後狀态是unstable或failed，則可以發送郵件告警，及時通知相關負責人進行處理。Jenkins自帶SMTP功能，不過需要你提供SMTP伺服器。

我使用的是qq郵箱SMTP伺服器，挺好用的，目前沒有發現拒發的情況。有一點需要注意的是，在配置好SMTP的賬戶資訊後，還需填寫系統管理者郵件位址，否則會發送失敗，這也是比較容易忽略的地方。

配置好SMTP後，然後在建構後操作中添加E-mail Notification項，填寫負責人的郵箱即可。

如果tm_test建構成功，則需要自動觸發tm_staging_deploy任務，這個觸發過程是通過插件Parameterized Trigger Plugin來完成的。

在建構後操作中添加Trigger parameterized build on other projects項，選擇觸發條件為stable，然後填寫待出發的任務名稱即可。

最後的tm_test任務面闆如下：

界面是挺out的，不過很實用。

這一個job用于将最新代碼部署到staging伺服器上，我采用的部署方法是通過ssh遠端登陸伺服器執行指令的方式，需要一個插件SSH plugin。

然後在建構中添加Shell項：

此任務和tm_staging_deploy基本差不多，不同的地方有2個：（1）目标伺服器不同（2）觸發方式是手動觸發

除此之外，我還用到了一個很有用的插件SCM Sync configuration plugin，就是把Jenkins的配置（全局配置+各job配置）同步到一個Git倉庫中。這樣的話，每次配置有變動，都會形成一個commit推送到Git倉庫。

這相當于把配置的曆史變遷都記錄下來，如果哪天Jenkins任務挂了，可以看看配置變更進行排錯。

本文轉自 AltBoy 51CTO部落格，原文連結:http://blog.51cto.com/altboy/1983800