1. 前言

隨著互聯(lián)網(wǎng)軟件行業(yè)快速發(fā)展，為了搶占市場先機，企業(yè)不得不持續(xù)提高軟件的交付效率。特別是現(xiàn)在國內(nèi)越來越多企業(yè)已經(jīng)在逐步引入DevOps研發(fā)模式的變遷，在這些背景催促之下，對于企業(yè)研發(fā)團隊所需要具備的持續(xù)集成和持續(xù)交付（簡稱CI/CD）能力變得越來越不可或缺。

相信現(xiàn)在不管是開發(fā)人員、測試人員或者是運維人員，在求職招聘時，基本上如果是面試的是中高級以上的職位，大多都要求要具備相關(guān)CI/CD的項目建設(shè)或參與搭建經(jīng)驗。

為了幫助到更多公號技術(shù)讀者，公號從本周起，將以《持續(xù)集成實踐系列》為主題，分享幾篇搭建CI持續(xù)集成實踐的技術(shù)干貨。

關(guān)于持續(xù)集成和持續(xù)交付（CI/CD）概念的介紹，公號之前的文章：DevOps研發(fā)模式下CI/CD實踐詳解指南 中有過較詳細的介紹，如果還不清楚什么是CI/CD的讀者，可以在閱讀本文前先，參考一下這篇文章。

2. CI系列大綱

市面上關(guān)于CI/CD的建設(shè)如果僅從工具、框架層面來講，方案有挺多，如TeamCity、GitLab CI、Bamboo、Circle CI、Travis CI、Jenkins、公司自研（在研發(fā)建設(shè)CI/CD能力時，除了CI/CD工具、框架鏈的建設(shè)外，還包括研發(fā)協(xié)同文化的建設(shè)等， 文化層面的這個不在本系列的討論范圍內(nèi)）。

而在眾多的持續(xù)集成CI建設(shè)工具體系中，Jenkins基本上可以說是獨占鰲頭，也是大多數(shù)公司最常用、最首選的工具之一，占據(jù)了將近70%以上的市場。

而隨著Jenkins本身的不斷發(fā)展，當前Jenkins已演變發(fā)展到了2.x系列，在Jenkins 2.x系列中，其中最核心的特性是引入了流水線機制，并提出了流水線即代碼（pipeline as code）的理念。

因此本系列也將以Jenkins 2.x作為《持續(xù)集成實踐系列》的載體，為大家介紹在結(jié)合Jenkins 2.x搭建持續(xù)集成CI能力過程中常見的一些知識要點和實現(xiàn)過程。

系列大綱分為（初步擬訂）：

3. 先介紹一下Jenkins 2.x

Jenkins 2本身的概念比較寬泛。在特定的上下文環(huán)境中，它用來泛指支持流水線即代碼及其它類似Jenkinsfile等新特性的新版Jenkins。

Jenkins 1.X版本主要通過插件的方式來實現(xiàn)，確切地講，Jenkins 2也是通過對已有插件的重點升級和新插件的引入來獲取新功能。

相比之前，用戶只能通過WEB界面進行配置的方式來定義Jenkins任務(wù)，Jenkins 2則通過使用Jenkins DSL和Groovy語言編寫程序，用戶可以定義流水線并執(zhí)行各種任務(wù)。

這里提到的DSL代表領(lǐng)域特定語言（Domain-Specific Language），可以理解為一種適用于Jenkins的編程語言。DSL基于Grovvy實現(xiàn)，并通過概念和結(jié)構(gòu)封裝了Jenkins的特定功能。

Jenkins 2推薦使用名為Jenkinsfile的文件保存任務(wù)配置和流水線信息，不同的項目和分支都會有自己的Jenkinsfile，其內(nèi)容各不相同。你可以將全部代碼寫在一個Jenkinsfile中，也可以通過共享庫的方式調(diào)用外部代碼。

4. Jenkins 2.x 實現(xiàn)流水線的兩種語法

當我們通過Jenkins 2.x實現(xiàn)流水線時，有兩種不同的語法樣式：腳本式語法（script syntax）和聲明式語法（declarative syntax）。

腳本式語法（script syntax）是Jenkins最開始實現(xiàn)流水線即代碼的方式，這是一種命令式風(fēng)格，在以前版本的Jenkins中，流水線即代碼大體就是Groovy腳本，其中插件部分針對Jenkins的DSL步驟。這種方式幾乎沒有結(jié)構(gòu)上的約束，程序流程也基于Groovy語法結(jié)構(gòu)實現(xiàn)。

這種模式現(xiàn)在被稱為腳本式流水線。在腳本式流水線中，DSL支持為數(shù)眾多的任務(wù)步驟，但是仍然缺失了部分面向Jenkins任務(wù)的核心特性，比如，構(gòu)建后處理、流水線結(jié)構(gòu)錯誤檢查以及基于不同執(zhí)行狀態(tài)發(fā)送通知的功能。當然大多數(shù)功能都可以通過Groovy編程機制來模擬實現(xiàn)，比如try-catch-finally語法。但是這在面向Jenkins編程的基礎(chǔ)上對Groovy語言技能提出了更高的要求。

而聲明式語法，是Jenkins提供的一種新的選擇，聲明式風(fēng)格的流水線代碼被編排在清晰的段落中，相對于只關(guān)注實現(xiàn)邏輯。

5. 如何選擇腳本式語法或聲明式語法

那么有哪些因素會影響選擇腳本式語法或聲明式語法呢？和大多數(shù)事情一樣，這也不是一個嚴謹?shù)目茖W(xué)問題。在特定的情況下，對比需求、實現(xiàn)的結(jié)構(gòu)和流程以及構(gòu)建流水線的人員技能和背景，二者可能各有千秋。

比如，腳本式流水線具有以下優(yōu)點：

• 更少的代碼段落和弱規(guī)范要求。

• 更強大的程序代碼能力。

• 更像編寫代碼程序。

• 傳統(tǒng)的流水線即代碼模型，用戶熟悉并向后兼容性。

• 更靈活的自定義代碼操作。

• 能夠構(gòu)建更復(fù)雜的工作流和流水線。

但同時，腳本式流水線也具有以下缺點：

• 普遍要求更高的編程水平。

• 語法檢查受限于Groovy語言及環(huán)境。

• 和傳統(tǒng)的Jenkins模型有很大差異。

• 與聲明式流水線的實現(xiàn)相比，同一工作流會更復(fù)雜。

看一則簡單的，腳本式流水線示例：

 1node("worker_node1"){
 2    stage("Source"){
 3        //從Git倉庫中獲取代碼
 4        git 'git@github.com:zhoujinjian/intelligent-test-platform.git'
 5    }
 6    stage("Compile"){
 7        //運行Gradle進行編譯和單元測試
 8        sh "gradle clean comileJava test"
 9    }
10}

而聲明式流水線優(yōu)點有：

• 更結(jié)構(gòu)化，貼近傳統(tǒng)的Jenkins Web表單形式。

• 更強大的聲明內(nèi)容能力，高可讀性。

• 可以能過Blue Ocean圖形化界面自動生成。

• 段落可映射到常見的Jenkins概念，比如通過。

• 更友好的語法檢查和錯誤識別。

• 提升流水線間的一致性。

但如此同時，聲明式流水線的缺點也很明顯：

• 對迭代邏輯支持較弱（相比程序而已）

• 對于傳統(tǒng)的Jenkins中部分功能缺乏支持。

• 更嚴格的結(jié)構(gòu)。

• 目前對于復(fù)雜的流水線和工作流難以勝任。

聲明式流水線示例：

 1pipeline{
 2    agent{
 3        lable "worker_node1"
 4    }
 5    stages{
 6        stage("Source"){
 7            steps{
 8                 //從Git倉庫中獲取代碼
 9                git 'git@github.com:zhoujinjian/intelligent-test-platform.git'
10            }
11        }
12        stage("Compile"){
13            steps{
14                //運行Gradle進行編譯和單元測試
15                sh "gradle clean comileJava test" 
16            }
17        }
18    }
19}

簡而言之，對于新用戶和那些希望流水線具備傳統(tǒng)Jenkins一樣可讀性的用戶來說，聲明式流水線更容易學(xué)習(xí)和維護。腳本式流水線更加靈活，允許用戶不受結(jié)構(gòu)結(jié)束實現(xiàn)更多功能。

不過，總的來說，任何一種流水線類型對大多數(shù)場景而言同樣適用。好了本文作為CI持續(xù)集成系列的開篇，先介紹到這里吧。

如果你覺得文章還不錯，請大家點贊分享下。你的肯定是我最大的鼓勵和支持。