一、jenkins pipeline
要實作CD,先要實作CI。CD Pipeline就是一個代碼檔案,裡面把你項目業務場景都通過Groovy代碼和Pipeline文法實作,一個一個業務串聯起來,全部實作自動化,從代碼倉庫到生産環境完成部署的自動化流水線。這個過程就是一個典型的CD Pipeline。
官網建議我們把Pipeline代碼放在一個名稱為Jenkinsfile的文本檔案中,并且把這個檔案放在項目代碼的根目錄,采用版本管理工具管理。
一個Jenkinsfile或者一個Pipeline代碼檔案,我們可以使用兩個腳本模式去寫代碼,這兩種分類叫:Declarative Pipeline 和 Scripted Pipeline.
Declarative相對于Scripted有兩個優點。
1)、第一個是提供更豐富的文法功能;
2)、第二個是寫出來的腳本可讀性和維護性更好;
Jenkins是一個非常著名的CI伺服器平台,支援很多不同第三方(插件的形式)內建自動化測試。
Jenkins UI 配置已經滿足不了這麼複雜的自動化需求,加入Pipeline功能之後,Jenkins 表現更強大。
Pipeline主要有一下特點
Code代碼:Pipeline是用代碼去實作,并且支援check in到代碼倉庫,這樣項目團隊人員就可以修改,更新Pipeline腳本代碼,支援代碼疊代。
Durable耐用:Pipeline支援在Jenkins master(主節點)上計劃之内或計劃外的重新開機下也能使用。
Pausable可暫停:Pipeline支援可選的停止和恢複或者等待準許之後再跑Pipeline代碼。
Versatile豐富功能:Pipeline支援複雜和實時的CD需求,包括循環,拉取代碼,和并行執行的能力。
Extensible可擴充性:Pipeline支援DSL的自定義插件擴充和支援和其他插件的內建。
二、jenkins pipeline 流程圖

第1步.開發(IDE)送出代碼到項目倉庫伺服器(gitlab);
第2步.jenkins開始執行Pipeline代碼檔案,開始從(gitlab)倉庫git clone代碼;
第3步.jenkins啟動Pipeline裡面第一個stage(階段);
第4步.圖裡面第一個Stage從倉庫檢出(Checkout)代碼;
第5步.接着進入第二Stage建構(Build)檢出的代碼;
第6步.然後進入測試(Test)的階段,執行各種自動化測試驗證;
第7步.然後測試結束,到運維的部署(Deploy)階段;
第8步.部署結束,輸出報告,整個自動化流程工作完成;
等待觸發建構,開始重複下一輪1到8步驟。
三、Pipeline概念基礎
四、Declarative Pipeline(聲明式流水線)概述
所有有效的Declarative Pipeline必須包含在一個pipeline塊内,例如:
Declarative Pipeline中有效的基本語句和表達式遵循與Groovy文法相同的規則 ,但有以下例外:
Pipeline的頂層必須是塊,具體來說是:<code>pipeline { }</code>
沒有分号作為語句分隔符。每個聲明必須在自己的一行
塊隻能包含章節, 指令,步驟或指派語句。
屬性引用語句被視為無參數方法調用。是以例如,input被視為<code>input()</code>
Groovy代碼還可以寫分号,Jenkins Pipeline代碼就不需要,每行隻寫一個聲明語句塊或者調用方法語句。
Declarative Pipeline(聲明式流水線) 代碼中的Sections指的是必須包含一個或者多個指令或者步驟的代碼區域塊。Sections不是一個關鍵字或者指令,隻是一個邏輯概念。
Required(必需的)
Yes
Parameters(參數)
Described below(詳情如下)
Allowed(允許)
In the top-level pipeline block and each stage block(在頂級管道塊和每個階段塊中)
agent 部分指定了整個流水線或特定的部分,将會在jenkins環境中執行的位置,該部分不許再pipeline的頂層定義,但是stage級别的使用是可選擇的,也可以使用在stage級。
簡單來說,agent部分主要作用就是告訴Jenkins,選擇那台節點機器去執行Pipeline代碼。這個指令是必須要有的,也就在你頂層pipeline {…}的下一層,必須要有一個agent{…}
為了支援寫Pipeline代碼的人可能遇到的各種用例場景,agent部分支援幾種不同類型的參數。這些參數可以應用于pipeline塊的頂層,也可以應用在每個stage指令内。
作用:使用提供的标簽在Jenkins環境中可用的代理機器上執行Pipeline或stage内執行。
定義方式為:一個字元串。該标簽用于運作流水線或個别的 stage。
該參數對 node, docker 和 dockerfile 可用, node要求必須選擇該選項。
目前來說,這種node類型的agent代碼塊,在實際工作中使用可能是最多的一個場景。
一個字元串,在自定義工作區運作應用了 agent 的流水線或個别的 stage, 而不是預設值。 它既可以是一個相對路徑, 在這種情況下,自定義工作區會存在于節點工作區根目錄下, 或者一個絕對路徑。該參數對 node, docker 和 dockerfile 有用比如:
下面,我寫一個測試代碼,結合上面node的代碼,放在Jenkins UI上進行測試。代碼如下:
拷貝上面代碼在Jenkins job的pipeline設定頁面,儲存,啟動測試。
使用給定的容器執行流水線或階段。該容器将在預置的 node上,或在比對可標明義的<code>label</code> 參數上,動态的供應來接受基于Docker的流水線。 docker 也可以選擇的接受 args 參數,該參數可能包含直接傳遞到 docker run 調用的參數, 以及 alwaysPull 選項, 該選項強制 docker pull ,即使鏡像名稱已經存在。
執行流水線或階段, 使用從源代碼庫包含的 Dockerfile 建構的容器。為了使用該選項, Jenkinsfile 必須從多個分支流水線中加載, 或者加載 "Pipeline from SCM." 通常,這是源代碼倉庫的根目錄下的 Dockerfile : agent { dockerfile true }. 如果在另一個目錄下建構 Dockerfile , 使用 dir 選項: agent { dockerfile {dir 'someSubDir' } }。如果 Dockerfile 有另一個名稱, 你可以使用 filename 選項指定該檔案名。你可以傳遞額外的參數到 docker build ... 使用 additionalBuildArgs 選項送出, 比如
可以根據pipeline的狀态來執行一些操作,定義Pipeline或stage運作結束時的操作。post-condition塊支援post部件:always,changed,failure,success,unstable,和aborted。這些塊允許在Pipeline或stage運作結束時執行步驟,具體取決于Pipeline的狀态。按照慣例, post 部分應該放在流水線的底部。
NO
NONE
post-condition(情況)
always
運作,無論Pipeline運作的完成狀态如何
changed
隻有目前Pipeline運作的狀态與先前完成的Pipeline的狀态不同時,才能運作
failure
僅當目前Pipeline處于“失敗”狀态時才運作,通常在Web UI中用紅色訓示表示
success
僅當目前Pipeline具有“成功”狀态時才運作,通常在具有藍色或綠色訓示的Web UI中表示
unstable
隻有目前Pipeline具有“不穩定”狀态,通常由測試失敗,代碼違例等引起,才能運作。通常在具有黃色訓示的Web UI中表示
aborted
隻有目前Pipeline處于“中止”狀态時,才會運作,通常是由于Pipeline被手動中止。通常在具有灰色訓示的Web UI中表示
包含一系列一個或多個 stage 指令, stages 部分是流水線描述的大部分"work" 的位置。 建議 stages 至少包含一個 stage 指令用于連續傳遞過程的每個離散部分,比如建構, 測試, 和部署。
none
Only once, inside the pipeline block(在管道内,隻有一次)
steps: 包含一個或者多個在stage塊中執行的step序列,steps 部分在給定的 stage 指令中執行的定義了一系列的一個或多個steps。
Inside each stage block(在每個分段塊内)
environment指定鍵值對,可用于step中,主要是為常量或者變量指派,根據所在的位置來決定其作用範圍(類似于java中全局和局部的概念)environment{…}, 大括号裡面寫一些鍵值對,也就是定義一些變量并指派,這些變量就是環境變量。環境變量的作用範圍,取決你environment{…}所寫的位置,你可以寫在頂層環境變量,讓所有的stage下的step共享這些變量,也可以單獨定義在某一個stage下,隻能供這個stage去調用變量,其他的stage不能共享這些變量。一般來說,我們基本上上定義全局環境變量,如果是局部環境變量,我們直接用def關鍵字聲明就可以,沒必要放environment{…}裡面。
no
Inside the pipeline block, or within stage directives.(在管道内部,或者在階段指令内部)
頂層流水線塊中使用的 environment 指令将适用于流水線中的所有步驟。
在一個 stage 中定義的 environment 指令隻會将給定的環境變量應用于 stage 中的步驟。
environment 塊有一個 助手方法 credentials() 定義,該方法可以在 Jenkins 環境中用于通過辨別符通路預定義的憑證。
options 指令允許從流水線内部配置特定于流水線的選項。 流水線提供了許多這樣的選項, 比如 buildDiscarder,但也可以由插件提供, 比如 timestamps.
Only once, inside the pipeline block(僅有一次,在每個管道塊内)
**設定儲存最近的記錄,為最近的流水線運作的特定數量儲存元件和控制台輸出。例如: **
不允許同時執行流水線。 可被用來防止同時通路共享資源等。 禁止并行建構,因為用的worksapce還是同一個例如:
允許覆寫分支索引觸發器的預設處理。 如果分支索引觸發器在多分支或組織标簽中禁用,
在<code>agent</code> 指令中,跳過從源代碼控制中檢出代碼的預設情況。例如:
一旦建構狀态變得UNSTABLE,跳過該階段。例如:
在工作空間的子目錄中自動地執行源代碼控制檢出。例如:
設定流水線運作的逾時時間, 在此之後,Jenkins将中止流水線。例如:
在失敗時, 重新嘗試整個流水線的指定次數。
預謀所有由流水線生成的控制台輸出,與該流水線發出的時間一緻。 例如:
stage 的 options 指令類似于流水線根目錄上的 options 指令。然而, stage -級别 options 隻能包括 retry, timeout, 或 timestamps 等步驟, 或與 stage 相關的聲明式選項,如 skipDefaultCheckout。
在<code>stage</code>, options 指令中的步驟在進入 agent 之前被調用或在 when 條件出現時進行檢查。
可選的階段選項:
parameters 指令提供了一個使用者在觸發流水線時應該提供的參數清單。
定義: 流水線在運作時設定的參數,UI頁面的參數。所有的參數都存儲在params對象中。
将web ui頁面中定義的參數,以代碼的方式定義。
字元串類型的參數, 例如:
布爾參數, 例如:
該triggers指令定義了Pipeline應重新觸發的自動化方式。對于與源代碼內建的Pipeline,如GitHub或BitBucket,triggers可能不需要基于webhook的內建可能已經存在。目前有三個可用的觸發器是cron和pollSCM 和 upstream。
這塊是設定什麼條件下觸發pipeline代碼執行,以及觸發的頻率,用來控制輪詢頻率的,特别适合周期的自動化送出。
接收 cron 樣式的字元串來定義要重新觸發流水線的正常間隔 ,比如:
接收 cron 樣式的字元串來定義一個固定的間隔,在這個間隔中,Jenkins 會檢查新的源代碼更新。如果存在更改, 流水線就會被重新觸發。例如:
接受逗号分隔的工作字元串和門檻值。 當字元串中的任何作業以最小門檻值結束時,流水線被重新觸發。例如:
【參數解釋說明】
MINUTE:
Minutes with in the hour(0-59)每小時的分鐘(0-59)分鐘
HOUR:
The hour of the day(0-23) 每天(0-23)小時
DOM:
The day of the month(1-31) 每月(1-31)天
MONTH:
The month of the year (1-12)每年(1-12)月
DOW:
The day of the week(1-7)每周(1-7)天
stage 指令在 stages 部分進行,應該包含一個 實際上, 流水線所做的所有實際工作都将封裝進一個或多個 stage 指令中。
Required
At least one(至少一個)
Parameters
One mandatory parameter, a string for the name of the stage.(一個必選參數,階段名稱的字元串)
Inside the stages section(在階段内)
stage(階段)特點:
stage一定是在stages{…}裡面;
一個pipeline{…}中至少有一個stages{…}和一個stage{…};
一個stage{…}中至少有一個steps{…};
Stage{…}還有一個特點就是,裡面有一個強制的字元串參數,這個字元串參數就是描述這個stage是幹嘛的,這個字元串參數是不支援變量的,隻能你自己取名一個描述字段。