自从去年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模块化改造。
随着容器化技术(以Docker为代表)的不断升温,Jenkins紧随潮流,不仅同步上传2.0的Docker镜像,同时也在Pipeline中提供了默认的 Docker支持 。
除了上述内容,2.0还有一个比较有意思的改动,全局重命名Slave为Agent,看来在美国做IT政治正确性也是很重要啊。
了解了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的产生背景,我认为有三个层面的原因。
说完背景,再看一下Pipeline的具体构成和特性。
基本概念:
具体构成:
2.0默认支持三种类型的Pipeline,普通Pipeline,Multibranch Pipeline和Organization Folders,后两种其实是批量创建一组普通Pipeline的快捷方式,分别对应于多分支的应用和多应用的大型组织。注意,要获取Organization Folders的支持需要额外安装Plugin。
值得一提的是,2.0有两个很重要的特性:
上文所涉及的示例Pipeline可以在我的GitHub找到,如果有问题想跟我探讨,可以加我QQ: 7789059。