11月16日总结

提到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 熟识的程度大部分在于自己插件的使用经验。
可维护性