2.0新時代：從CI到CD

2.0 破繭重生

自從去年9月底Jenkins的創始人Kohsuke Kawaguchi提出Jenkins 2.0（後稱2.0）的願景和草案之後，整個Jenkins社區為之歡欣鼓舞，不管是官方博客還是Google論壇，大家都在熱烈討論和期盼2.0的到來。4月20日，歷經Alpha(2/29)，Beta(3/24)，RC(4/7)3個版本的迭代，2.0終於正式發布。這也是Jenkins面世11年以來（算上前身Hudson）的首次大版本升級。那麼，這次升級具體包含了哪些內容呢？

外部

從外部來看，2.0最大的三個賣點分別是Pipeline as Code，全新的開箱體驗和1.x兼容性。

Pipeline as Code是2.0的精髓所在，是幫助Jenkins實現CI(Continuous Integration)到CD(Continuous Delivery)華麗轉身的關鍵推手。所謂Pipeline，簡單來說，就是一套運行於Jenkins上的工作流框架，將原本獨立運行於單個或者多個節點的任務連接起來，實現單個任務難以完成的復雜發布流程（例如下圖）。Pipeline的實現方式是一套Groovy DSL(類似Gradle)，任何發布流程都可以表述為一段Groovy腳本，並且Jenkins支持從代碼庫直接讀取腳本，從而實現了Pipeline as Code的理念。

vcTL1sHT8sP7tryxu9bY0MLJ6LzGoaPV4tCpseS7r7P9wcu8q7TztcS4xMnGwcvTw7unzOXR6aOsuPzW2NKqtcTKx7j4yMvDx7SrtO/Su7j2x+XO+rXE0MW6xaOsSmVua2luc7K71Nm99r32ysfSu7j2Q0m5pL7fo6y2+MrH1My6rNfFzt7P3r/JxNyhozwvcD4NCjxwPjxpbWcgYWx0PQ=="" src="http://www.2cto.com/uploadfile/Collfiles/20160503/20160503090406151.png" title="\" />

1.x兼容性給所有老版本用戶吃了一顆大大的定心丸，注意，是完全兼容哦。

內部

從內部來看，2.0主要包含了一些組件升級和JS模塊化改造。

升級Servlet版本到3.1，獲取Web Sockets支持 升級內嵌的Groovy版本到2.4.6
未來版本的Jenkins將會把Groovy徹底從內核中剝離，此次Groovy升級只是第一步 提供一個簡化的JS類庫給Plugin開發者使用

更好的容器化支持

隨著容器化技術（以Docker為代表）的不斷升溫，Jenkins緊隨潮流，不僅同步上傳2.0的Docker鏡像，同時也在Pipeline中提供了默認的Docker支持。

除了上述內容，2.0還有一個比較有意思的改動，全局重命名Slave為Agent，看來在美國做IT政治正確性也是很重要啊。

Pipeline as Code

了解了2.0的概貌之後，回過來我們再看一下Pipeline as Code(後稱Pipeline)產生的背景和具體構成。

產生背景

作為2.0的核心插件，Pipeline並不是一個新事物，它的前身是Workflow Plugin，而Workflow的誕生是受更早的Build Flow Plugin啟發，由Nicolas De Loof於2012年4月發布第一個版本。而縱觀Jenkins的幾個競爭對手（Travis CI、phpci、circleci），Pipeline早已不是什麼新鮮概念。可以說這次Jenkins 2.0的發布是順勢而為，同時也是大勢所趨。

如果要在更大范圍探討Pipelined的產生背景，我認為有三個層面的原因。

第一層面，與不斷增長的發布復雜度有關，其中一個典型場景就是灰度發布。原本只有大公司才有的灰度發布，隨著敏捷開發實踐的廣泛采用、產品迭代周期的不斷縮短、數據增長理念的深入人心，越來越多的中小公司也開始這一方面的探索，這對發布的需求也從點狀的CI升級到線狀的CD。這是Pipeline產生的第一個原因。 第二層面，與應用架構的模塊化演變有關，以微服務為代表，一次應用升級往往涉及到多個模塊的協同發布，單個CI顯然無法滿足此類需求。這是Pipeline產生的第二個原因。 第三層面，與日益失控的CI數量有關。一方面，類似於Maven、pip、RubyGems這樣的包管理工具使得有CI需求的應用呈爆發性增長，另一方面，受益於便捷的Git分支特性，即便對於同一個應用，往往也需要配置多個CI。隨著CI數量的不斷增長，集中式的任務配置就會成為一個瓶頸，這就需要把任務配置的職責下放到應用團隊。這是Pipeline(as Code)產生的第三個原因。

具體構成

說完背景，再看一下Pipeline的具體構成和特性。

基本概念：

Stage: 一個Pipeline可以劃分為若干個Stage，每個Stage代表一組操作。注意，Stage是一個邏輯分組的概念，可以跨多個Node。 Node: 一個Node就是一個Jenkins節點，或者是Master，或者是Agent，是執行Step的具體運行期環境。 Step: Step是最基本的操作單元，小到創建一個目錄，大到構建一個Docker鏡像，由各類Jenkins Plugin提供。

具體構成：

Jenkinsfile: Pipeline的定義文件，由Stage，Node，Step組成，一般存放於代碼庫根目錄下。 Stage View: Pipeline的視覺展現，類似於下圖。

2.0默認支持三種類型的Pipeline，普通Pipeline，Multibranch Pipeline和Organization Folders，後兩種其實是批量創建一組普通Pipeline的快捷方式，分別對應於多分支的應用和多應用的大型組織。注意，要獲取Organization Folders的支持需要額外安裝Plugin。

值得一提的是，2.0有兩個很重要的特性：

Pausable: 類似於Bash的read命令，2.0允許暫停發布流程，等待人工確認後再繼續，這個特性對於保證應用HA尤為重要。

Durable: 發布過程中，如果Jenkins掛掉，正在運行中的Pipeline並不會受影響，也就是說Pipeline的進程獨立於Jenkins進程本身。