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的理念。
全新的開箱體驗力圖扭轉我們印象中Jenkins十年不變的呆滯界面風格，不光Jenkins應用本身，官網排版、博客樣式乃至域名都被重新設計。這些變化除了極大的改善了用戶體驗，更重要的是給人們傳達一個清晰的信號，Jenkins不再僅僅是一個CI工具，而是蘊含着無限可能。
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進程本身。
示例Pipeline
上文所涉及的示例Pipeline可以在我的GitHub找到，如果有問題想跟我探討，可以加我QQ: 7789059。
參考
- The Need for Jenkins Pipeline
- Jenkins 2.0
- Why Pipeline?
- Pipeline-as-code with Multibranch Workflows in Jenkins
轉載請保留出處及原文地址：http://emacoo.cn/blog/jenkins-2-0-from-ci-to-cd