1. 程式人生 > >[轉] Jenkins Pipeline插件十大最佳實踐

[轉] Jenkins Pipeline插件十大最佳實踐

而是 成員 file 腳本 定義 兼容 存檔 NPU mit

[From] http://blog.didispace.com/jenkins-pipeline-top-10-action/

Jenkins Pipeline 插件對於 Jenkins 用戶來說可以讓用戶能夠改變遊戲規則。基於 Groovy 中的領域特定語言(DSL),Pipeline 插件使 Pipelines 可以有腳本來定義,並且提供了非常強大的方法來開發復雜的、多步 DevOps Pipeline 。本文記錄了編寫 Jenkins Pipeline 的一些的最佳實踐和不推薦的代碼示例和說明。

1. 要使用真正的 Jenkins Pipeline

不要使用像 Build Pipeline 插件或者 Buildflow 插件這樣的舊插件。而是使用真正的 Jenkins Pipiline 插件套裝。

這是因為 Pipeline 插件是底層工作自身的一個改變和提升的 Step。與 Freestyle 任務不同,Pipeline 對 Jenkins 主機重新啟動具有適應能力,並且有可以替代以前用於構建多步、復雜交付 Pipeline 的許多舊插件的內置功能。

有關入門的更多信息,請訪問 https://jenkins.io/solutions/pipeline/

2. 就像寫代碼一樣開發你的 Pipeline

使用這個功能可以讓你像做其他軟件一樣將 Pipeline 描述代碼以 Jenkinsfile 方式存儲在 SCM 中,然後進行版本測試。

這樣做可以將 Pipeline 作為代碼看待,強制執行良好的規範,並開辟了一個新的功能領域,如多分支、拉請求檢測和組織掃描 GitHub 和 BitBucket。

技術分享圖片

還應該將流水線腳本稱為默認名稱:Jenkinsfile ,並且以 #!groovy 腳本開頭,以便 IDE ,GitHub 和其他工具將其識別為 Groovy 並啟用代碼高亮。

3. 要在 Stage 塊內進行作業

Pipeline 內的任何非安裝作業都應該在某一個 Stage 塊內執行。

這是因為 Stage 是 Pipeline 的邏輯分割。 可以將工作分為幾個 Stage,可以將 Pipeline 分成清晰的幾個步驟。

例如:

stage ‘build‘

//build

stage ‘test‘

//test

更好的是:Pipeline Stage View 插件將各個 Stage 看作 Pipeline 的唯一分段。

技術分享圖片

4. 在節點內執行實際作業

Pipeline 裏的實質性作業都應該發生在一個 Node 塊內。

因為在默認情況下,Jenkinsfile 腳本本身在 Jenkins 主機上運行,使用一個預期使用很少資源的輕量級執行器。 在任何實質性作業過程中,例如從 Git 服務器克隆代碼或編譯 Java 應用程序,都應該利用 Jenkins 分布式構建能力, 在代理節點中運行。

例如:

stage ‘build‘

node{

checkout scm

sh ‘mvn clean install‘

}

5. 做一個並行的 Step

Pipeline 提供了一個很直接的語法,用於將你的 Pipeline 分為並行的 Step。

這是因為並行分配工作將使你的 Pipeline 運行更快,並更快地獲得開發人員和團隊其他成員的反饋。

例如:

parallel ‘shifting‘:{

//everything

}, ‘left‘:{

//I can

}

提示:使用 Parallel Test Executor 插件讓 Jenkins 自動確定如何在最佳並行池中運行 xUnit 兼容測試!您可以在 CloudBees 博客上閱讀有關並行測試執行的更多信息。

6. 在並行 Step 中的使用 Node

為什麽我們要在並行 Step 中獲取並使用一個 Node? 這是因為並行化有一個主要的優勢是:可以同時進行更多的實質性工作(參見最佳實踐4)! 通常,我們應該想在 Pipeline 的並行分支中獲取一個 Node 來提高並發構建速度。

例如:

parallel ‘integration-tests‘:{

node(‘mvn-3.3‘){ ... }

}, ‘functional-tests‘:{

node(‘selenium‘){ ... }

}

7. 在 Step 的 Timeout 代碼塊內進行 Input

Pipeline 有一個簡單的機制,那就是可以將 Pipeline 中的任何 Step 定時。 作為最佳實踐,我們應該總是計劃使用 Timeout 塊內 使用 Input。

這是為了健康的 Pipeline 的清理。如果在給定的窗口內沒有出現批準,則在超時時間中的 Input 將允許被清理(即中止)。

例如:

timeout(time:5, unit:‘DAYS‘) {

input message:‘Approve deployment?‘, submitter: ‘it- ops‘

}

8. 文件暫存優先於存檔

在將暫存能力添加到流水線 DSL 之前,存檔是在 Pipeline 中的 Node 或 Stage 之間共享文件的最佳方式。 如果只需要在流水線的 Stage 和 Node 之間共享文件,則應該使用暫存/提取而不是存檔。

這是因為暫存和提取被設計用於在 Stage 和 Node 之間共享文件,例如應用程序的源代碼。另一方面,存檔被設計用於長期文件存儲(例如,你構建的中間二進制文件)。

例如:

stash excludes: ‘target/‘, name: ‘source‘

unstash ‘source‘

9. 不要在 Node 塊內使用 Input

雖然可以在節點塊中使用一個 Input 語句,但我們絕對不應該這樣做。

因為 Input 元素會暫停 Pipeline 執行而去等待批準——無論是自動還是手動。 這些批準自然需要一些時間。 另一方面,當因為 Input 停下來的時候,節點元素會獲取並保持鎖定工作空間和耗資源的任務,這將是一個昂貴的資源。

因此,要在 Node 之外創建 Input。

例如:

stage ‘deployment‘

input ‘Do you approve deployment?‘

node{

//deploy the things

}

10. 不要使用 Env 全局變量設置環境變量

盡管你可以編輯 Env 全局變量中來定義某些環境設置,但我們應該使用 withEnv 語法。

Env 變量是全局變量,所以我們不鼓勵去直接改變它,因為樣就改變了全局環境,所以建議使用 withEnv 語法。

例如:

withEnv(["PATH+MAVEN=${tool ‘m3‘}/bin"]) {

sh "mvn clean verify"

}

本譯文轉載自:公眾號【JFrog傑蛙DevOPs】

[轉] Jenkins Pipeline插件十大最佳實踐