放弃"Jenkins"的种种理由，期待更好赋能研发的持续交付平台

Jenkins 很酷，但是不完美，有历史局限性造成的问题。本文仅从“如何更好给研发团队赋能的角度”，剖析Jenkins, 探讨理想的持续交付平台, 不带货无广告～

不完美的Jenkins

Jenkins的前身是Hudson, Hudson是SUN公司时期就有的CI工具，后来因为ORACLE收购SUN之后的商标之争，创始人KK搞了新的分支叫Jenkins 。今天的Hudson还在由ORACLE持续维护，但风头已经远不如社区以及CloudBees驱动的Jenkins.

Hudson 被 Jenkins 取代后，不再维护，并于 2017 年 2 月宣布已过时。Hudson 网站 hudson-ci.org 于 2020 年 1 月 31 日关闭

关于Hudson 和Jenkins的恩怨，有兴趣可查阅 https://www.oschina.net/news/63453/hudson-and-jenkins-grievances

提到DevOps/持续集成这些话题，由于开源免费，历史悠久，插件API丰富，群众基础好（可借鉴模仿案例实践资料多）等原因，Jenkins永远是那个最亮的“仔”，也是众多相关领域厂商或者企业**绕不开的“工具”。

不过，依然有很多“不完美”，仅仅是个没有“DevOps灵魂”的CI工具（理由如下），但不得不承认它又是“免费”又有“用户量”的CI工具。下面我通过以下几个方面详细做些剖析**

历史遗留问题

首先 Jenkins 是一个巨石系统，它是一个单体的结构。为什么到现在为止大家好像没有看过特别成熟的 Jenkins 集群级的方案，或者很少看到高可用的方案，大部分情况下大家看到的是给不同的团队或者是不同的部门分配多个 Master ，而不是共用一个大的 Master ，其实这个主要取决于 Jenkins 内部的实现原理和机制。

传统意义上来讲一个服务会有两层，一层是你的服务层，一层是你的数据层。但是 Jenkins 因为历史的一些原因，导致所有的存储都是以文件的方式存储在磁盘上，存储在磁盘上就会一个比较大的性能问题。在 Jenkins home 里有一个 jobs ，里面存储的就是大家构建的每一个任务，还会存构建任务的配置等等。一系列的东西都以文件的方式，以特定的目录结构存储在磁盘上。

当 Jenkins 第一个步骤，比如你重启 Jenkins 的时候，它会做什么？先把磁盘上 jobs 目录都扫一遍，加载到自己的内存里里，再去做后续的东西。比如刚才说的高可用的方案，假如用共享存储，现在在一台 Jenkins Master 上写了一个job，其实另一台 Jenkins 是没有感知的，因为没有加载这个job。

学习成本

Jenkins 的插件那么多，到底该选哪一个？而且出现很多问题是1+1小于2，有时候必须安装第二个插件来满足，两个插件组合的时候又可能达不到很好的合力，这导致很多业务场景不得不去装很多额外的插件来满足自己的需求。开发者对 Jenkins 熟识的程度大部分在于自己插件的使用经验。

可维护性

当jenkins支持的场景越复杂，你会发现你要管理很多插件，这是你构建Jenkins和复制Jenkins面对最大的问题；同时，插件由于是个人贡献维护，很多插件会有年久失修情况。

安全性

Jenkins的插件包括Jenkins本身，它是有一些漏洞的，当你去用一些插件的时候，你要不停的更新它。

性能

不知道有没有人在一个Jenkins中配200个人，你肯定碰到到第80个人的时候，整个用户配置界面会卡。

要想 Jenkins 用得好，插件不能少。但是 Jenkins 的插件会带来一些性能问题，每一个插件都是在项目启动的时候就会加载到内存里，当插件越大的时候，对性能的损耗越大。要选择自己合适的插件去构建自己的 Jenkins 。

第一个是插件，要选择一些合适数量的插件，满足需求的插件，尽量少的插件会比较好；
第二个是job，在 Jenkins 官方的文档上讲，当你的job超过1000个以上的时候， Jenkins 就会有一些性能问题。手动创建 user 80个以上就会有卡顿，job那个地方是第一次都加载进来的，而 user 是每次都会去扫盘，然后去加载XML；
第三个是slaves；
第四个是每一个节点上的 executor

其他问题

对于不熟悉DevOps的工程师，学习成本其实不低，或者说离最佳实践差的太远
没有“DevOps最佳实践”规范约束Jenkinsfile
项目隔离/权限分配方案的缺陷
集成配置比较“散乱”
Jenkins的能力来源于插件,需要额外配置,部分插件过于老旧/兼容性
UI丑陋，无法满足复杂UI交互
…

现实中持续交付对平台的要求

抛开Jenkins上面的缺点不谈，回到现实场景中，我们需要从更大的视角（即持续交付）来理解一个“持续交付平台”需要扮演的角色。

从上图中可以看出，从开发人员写下代码到服务最终用户是一个漫长过程，整体可以分成三个阶段：

从代码（Code）到制品库（Artifact）：这个阶段主要对开发人员的代码做持续构建并把构建产生的制品集中管理，是为部署系统准备输入内容的阶段。
从制品到可运行服务：这个阶段主要完成制品部署到指定环境，是部署系统的最基本工作内容。
从开发环境到最终生产环境：这个阶段主要完成一次变更在不同环境的迁移，是部署系统上线最终服务的核心能力。

如果从持续交付角度看，其最核心诉求就是要让上图三个阶段能够无缝连接并自动化运行起来，从而达到持续交付的两个核心目标：提高交付频率（部署次数）和降低部署延时（从代码提交到上线的时间差）。

参照如上持续交付的流程，可以发现持续交付对于一个部署系统的要求绝对不仅仅是一个自动化的部署过程，这也是在有了Jenkins和其相关部署插件后仍然需要搭建独立部署系统的原因所在。具体来说，我们可以从下面几点分析：

解耦构建和部署过程

尽管持续交付希望自动化完成从代码到部署上线的整个流程。但是整个持续交付过程有多个不同角色的人参与其中（开发、测试、运维甚至还经理及市场人员）。其中有些角色（如开发/测试）需要关心构建过程，而更多的角色（如运维等）绝大时候都是从制品开始部署工作。这也就要求构建和部署过程相互解耦，能够独立操作。
构建和部署这两个过程通过制品（Artifact，又称为部署包）连接（制品是构建过程的产出，同时是部署过程的输入）。如果它们相互解耦，自然就需要有统一的地方管理存储和管理这些制品，即统一制品库。
有了统一制品库后，构建过程自动提交产生的制品到此，而部署过程则主动到制品库拉取需要的制品进行部署，从而实现构建和部署的完整解耦。

管理复杂的部署环境

服务上线需要涉及到很多不同目的环境（开发、测试、预发、生产、演示等）。在云化基础设施中，环境内部的资源会频繁变化（例如，Auto-Scaling时刻都有可能添加或者减少你的云主机）。

这时候需要对部署流程隔离部署环境差异以及环境内频繁变化的基础设施。当需要执行一个部署时，操作人员只需要指定部署到哪个环境（即环境名称或者ID号），而不需要关心环境内部的任何信息，只需把部署请求分发到指定环境内的每台主机并自动执行。

如果基于Jenkins来直接部署，则必然把环境管理的很多复杂度引入到部署流程内部。

支持多种部署策略

为保障服务的高可用，落实部署和发布的解耦以及其他业务需要，用户常需要支持如灰度发布、A/B测试发布等部署需求。一个独立的部署系统在此可以提供多种部署策略，并结合环境管理等其他功能满足业务上对部署和发布的各种需求。同样，Jenkins及其部署插件并没有提供这样的能力。

落实部署流程规范

在一个公司内部经常有不同的项目，使用不同的编程语言，而部署流程也五花八门。从控制风险，减少重复操作，降低部署自动化难度等多重考量，公司都倾向制定一套标准的部署流程。

这时候，独立的部署系统就可以帮助用把这些规范落实下去并在日常的部署过程中时刻校验（在软件工程领域，几乎所有的规范落实都得靠工具来助一臂之力，否则基本都会变成纸面上的规范而已）。

如果基于Jenkins来直接部署，如何落实这些部署规范仍然是一个很困难的事情，因为Jenkins及其部署插件并未对此提供任何实质性的支持。

获取研发过程数据

部署是一个团队从代码到服务的关键路径，这上面的所有操作数据都值得记录并用于各种运营支持（包括安全审计、部署记录查询、部署频率和失败率分析等等）。基于Jenkins直接部署当然也可以获取这些数据，但是把它做在独立的系统内会更灵活和方便。

让部署操作服务化

如之前提到，部署不仅仅开发和测试人员需要，要努力让部署服务化，从而让团队内任何一个人都可以随时触发一次部署。Jenkins的操作界面对于开发或者测试人员可能还比较方便，但是对于其他人员来说则过于复杂。

当然，除了上面列出的这些原因外，你还要解决部署版本的管理等，这里就不一一列举。

持续交付平台的特质

如前所述，一个理想的持续交付系统需要包括的内容是非常丰富的，特别是要面临各种复杂场景，不同技术栈的团队，异构的各种内部系统（绝对不仅仅是Jenkins插件要做的那些事情）。

如下图所示，持续交付系统需要连接项目中涉及的人、代码，制品库，以及环境等，Jenkins仅仅起到了简单的连接作用。

对于简单的场景，或者较小团队来说，通过Jenkins各种插件来完成持续交付活动，是足够的。
对于更大的团队，或更高要求的组织，它最终希望的目标是打通从代码（甚至需求）到最终服务的整个流程（如下图）。

所以，能够给研发过程赋能的“持续交付平台”需要具备如下特点

能够管控好“代码”，“制品”，和“环境”，整个过程都是围绕这些做文章的
隐藏底层的细节，对不同角色要友好，提供自助式的服务
控制好和外部系统的集成，少侵入，多融合
控制好过程的“输入”和“输出”，聚焦体系化流程框架
正向引导用户做正确的事，赋能组织，而不是“让用户困扰”

期待更好的持续交付平台

DevOps持续交付涉及的工具如同各类不同形状的积木，你的目标是建造一个房子，可能你现在手中只有很少的积木，或者你有很多重复的积木，但是唯独缺少三角形完成屋顶部分。

想清楚房子要多大？多豪华？
自己手里有什么，缺什么？
工具搭配是否合适？是否漂亮？
谁是主角，谁是配角？
谁是从别人那里借来的，未来可能要还的
一个房子也能玩，多个房子玩的更好，先搭建哪个？

想清楚不迷路，不同的人搭建方法不同，只要最后搭建合理漂亮实用，恰到好处就可以，期待更好赋能研发过程的持续交付平台～