1. 程式人生 > >Jenkins Pipeline外掛十大最佳實踐!

Jenkins Pipeline外掛十大最佳實踐!

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。

640?wx_fmt=png&wxfrom=5&wx_lazy=1

還應該將流水線指令碼稱為預設名稱:Jenkinsfile ,並且以 #!groovy 指令碼開頭,以便 IDE ,GitHub 和其他工具將其識別為 Groovy 並啟用程式碼高亮。

3. 要在 Stage 塊內進行作業

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

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

例如:

  1. stage 'build'

  2. //build

  3. stage 'test'

  4. //test

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

640?wx_fmt=png

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

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

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

例如:

  1. stage 'build'

  2. node{

  3.    checkout scm

  4.    sh 'mvn clean install'

  5. }

5. 做一個並行的 Step

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

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

例如:

  1. parallel 'shifting':{

  2. //everything

  3. },'left':{

  4. //I can

  5. }

提示:使用 Parallel Test Executor 外掛讓 Jenkins 自動確定如何在最佳並行池中執行 xUnit 相容測試!您可以在 CloudBees 部落格上閱讀有關並行測試執行的更多資訊。

6. 在並行 Step 中的使用 Node

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

例如:

  1. parallel 'integration-tests':{

  2.    node('mvn-3.3'){...}

  3. },'functional-tests':{

  4.    node('selenium'){...}

  5. }

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

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

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

例如:

  1. timeout(time:5, unit:'DAYS'){

  2.    input message:'Approve deployment?', submitter:'it-  ops'

  3. }

8. 檔案暫存優先於存檔

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

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

例如:

  1. stash excludes:'target/', name:'source'

  2. unstash 'source'

9. 不要在 Node 塊內使用 Input

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

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

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

例如:

  1. stage 'deployment'

  2. input 'Do you approve deployment?'

  3. node{

  4. //deploy the things

  5. }

10. 不要使用 Env 全域性變數設定環境變數

儘管你可以編輯 Env 全域性變數中來定義某些環境設定,但我們應該使用 withEnv 語法。

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

例如:

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

  2.    sh "mvn clean verify"

  3. }

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

原文:https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin

優秀人才不缺工作機會,只缺適合自己的好機會。但是他們往往沒有精力從海量機會中找到最適合的那個。100offer 會對平臺上的人才和企業進行嚴格篩選,讓「最好的人才」和「最好的公司」相遇。掃描下方二維碼,註冊 100offer,談談你對下一份工作的期待。一週內,收到 5-10 個滿足你要求的好機會

640?wx_fmt=jpeg