一、背景

1.想法

jenkins1.x主要是實現的持續整合過程，整合各個外掛，但是終究需要人為手工的操作，如果job太複雜，人為容易出錯。於是jenkins2.x開始流行pipeline的寫法，以程式碼的方式來進行job的構建。正如社會潮流總是從人工到自動化的過程，在之前那篇文章中提及，要做一個devops的小工具，從java程式碼實現上來說，對於我還是比較複雜，程式碼實現部分還在鑽研中。本篇文章只是講講jenkins中pipeline怎麼寫！

二、pipeline基本語法介紹

學習一種程式語言（groovy）最開始的步驟總是學習它的語法，知曉它的規則。但是對於pipeline來說，暫時還不需要深入去學習groovy，下面簡單的為大家介紹下pipeline的一些主要的基本知識：

agent：該部分指定整個Pipeline或特定階段將在Jenkins環境中執行的位置，具體取決於該agent 部分的放置位置。該部分必須在pipeline塊內的頂層定義 ，也可以使用在stage級。

stage：表示這個Pipeline的某一個執行階段（使用stage使得邏輯變得更加簡單明瞭）

steps: 包含一個或者多個在stage塊中執行的step序列（在這裡執行操作：執行maven或者部署等等）

environment：指定鍵值對，可用於step中，主要是為常量或者變數賦值，根據所在的位置來決定其作用範圍（類似於java中全域性和區域性的概念）

options：允許執行pipeline內建的專用選項，也可以使用由外掛提供的

parameters:提供觸發pipeline時的引數列表

trigger：定義了觸發pipeline的方式（jenkins1.x中的pollscm定時構建）

tools:自動安裝工具，注意這裡使用的一定是在jenkins全域性配置中已經定義好了的

when：可以用來執行一些程式碼邏輯

post:可以根據pipeline的狀態來執行一些操作

以上是屬於個人理解，具體以官方文件為準。下面再來詳細說說裡面比較重要的agent，其他的部分請大家自行google或者百度，相對來說比較簡單。我的理解是：agent是一個機器總代理，它其中的引數都是為了指定一些可以使用的機器

agent的一些引數如下：

any ： 在任何可用的機器上執行pipeline

none ： 當在pipeline頂層使用none時，每個stage需要指定相應的agent，比方說：

pipeline{
    agent none   //沒有指定agent
    stages{
        stage('checkout code'){
            steps{
                sh 'echo "checkout code"'
            }
        }
    }
}

以上程式碼會報下面這串錯誤，原因就是沒有指定agent應用的節點：

label:在指定的機器上執行pipeline或者stage，比方說

agent{ label 'slave1'}  //指定slave1的節點機器執行該stage或者pipeline

這個設定的作用：在大規模叢集中，CI機器往往是相同的配置，而此時你的專案又需要一些額外的配置，這個時候這個設定可以很好的完成這個功能

docker:定義這個引數後，指定pipeline或stage時會動態的接收一個指定節點的docker的映象，並且還可以接受一個args的引數用於執行docker run 的引數。比方說你的專案要在A環境中做測試，在B環境中做預發驗證，在C環境做灰度釋出（這裡只是簡單的打個比方，實際中不是這樣的，只是為了說明此時需要在不同的環境中做不同的事情），這個時候涉及到多個環境，常規做法可以是直接指定幾個不同的slave的從節點，但是如果我此時想做測試並且只有一臺機器，那我可以在這臺機器上做幾個docker映象，分別用於不同的構建過程.比方說：

agent{
    docker{
        image 'mydocker'  //指定docker的映象名稱
        label 'slave1'    //指定在哪個機器上執行docker映象
        args  '-v /tmp:/tmp' //執行時傳入docker run的引數
    }
}

以上命令是在slave1的從節點機器上用mydocker的映象生成一個容器，並傳入-v /tmp:/tmp的引數

以上是我想分享給大家的基本知識，可能其中理解不對，也請大牛出來指正.

這個網站也推薦給大家：Jenkins持續整合 - 管道詳解，如若作者認為我放在這裡不合適，請聯絡我刪除.同時也推薦大家瀏覽一下官方文件。

三、pipeline實際應用（小例項）

例項1.用pipeline實現：從程式碼庫中拉取最新的程式碼，然後做pmd檢測，如果此次構建成功的話輸出“hello！success！”；如果失敗的話輸出“failed！Please check pipeline code！”併發送郵件到指定的地址上。按照以下流程做測試：

a.本地構建一個maven專案並上傳到github上(最近github賊慢，之後考慮在自己伺服器上搭建gerrit作為程式碼存放地址來演示)

***注意專案上傳時一些不需要的檔案及時使用.gitignore給忽略掉，要在git add 之前寫好.gitignore檔案，避免檔案被track後忽略不了***

以上表示檔案上傳成功.

b.寫好pipeline並執行，最後核查結果

***部分指令碼可以使用jenkins中的Pipeline Syntax來生成，比如拉取程式碼的***

下面開始演示失敗時候的場景，此時沒配置mvn的環境，但是執行mvn命令，按照預計中的報錯了：

下面開始演示正確的構建結果並附pipeline的程式碼：

pipeline{
    agent any
    tools{
        maven 'maven3' //maven3必須是已經在jenkins上配置的工具
    }
    stages{
        stage('checkout code'){
            steps{
                git credentialsId: '2c7a38c6-f536-4e93-bf3c-2ff4563fae8e', url: 'https://github.com/XXX/pipeline_script_test.git'
            }
        }
        stage('mvn test'){
            steps{
                sh "mvn -B -f ${env.workspace}/pom.xml pmd:pmd"
            }
        }
    }
    post{
        always{   //always表示不管怎麼樣都做下面的操作
            pmd canComputeNew: false, defaultEncoding: '', healthy: '', pattern: '', unHealthy: ''
        }
        failure{ 
            step([
                $class: 'Mailer',
                notifyEveryUnstableBuild: true,
                recipients: "[email protected]",
                sendToIndividuals: true
            ])
            echo "failed！Please check pipeline code！"
        }
        success{
            echo "hello！success！"}
    }
}

構建結果如下：

例項2：

以上就是一些關於jenkins的pipeline的簡單介紹，關於例項，之後會陸續更新上來。

如果對文章有疑問或者哪裡不懂的請聯絡我，在力所能及的範圍內幫助解答；如果文章有錯誤，也歡迎指出。