Jenkins在持续集成(CI)方面的强大力量和主导地位毋庸置疑——几乎所有人都在使用它来大规模地持续构建和测试软件。不过还有一点同样也无可争辩，可扩展性是它强大的基础，但无限的可能性会使其难以控制。
我曾经就处于这个失去秩序的风暴中心。我知道自己可以完成工作，但我正在经历由自己造成的低效率，试图快速成长或迅速把事情做好，这样我的老板就能向股东展示一个漂亮的图表。但我其实想说的是，直到现在我才学到，真正要弄清楚的是我在哪里，这样才能知道我要去哪里。
也许你已经有了一个完美的设置，但还是有人处于不受控制的位置或希望改进设置（因为没人有时间处理效率低下的问题），所以我想与你分享我学到的东西。剧透一下，这让我的工作轻松了许多，让我的天才开发人员们开心了许多，甚至还帮到我老板的老板做了漂亮的PPT。
灵活的代价
由于其无与伦比的灵活性，Jenkins主导了企业的软件开发生命周期。随着超过1800个插件将功能和工具集成扩展到开发环境的每个角落，这让Jenkins几乎无所不能。但是有两个系统问题可能对开发团队和他们所工作的企业产生负面影响：
- 缺乏集中控制。Jenkins缺乏集中控制。拥有多个控制器的企业有义务分别管理这些控制器。不存在一种可以跨CI环境管理操作、工作流和流程的集线器；也不存在可以对用户进行全局身份验证和供应的单一屏幕。从单个云接口协调跨多个服务器的插件或项目？不可能！
- 缺乏操作的可见性。Jenkins没有提供“鸟瞰图”，让企业可以看到目前状态或衡量整个运营的进展，甚至连知道谁拥有一个项目都很困难。因此，断开连接的团队就像身处一个竖井之中，在不完整的信息里工作，经理们则努力在软件开发生命周期中协调大局。
这些缺点产生的后果涉及广泛，导致了所有非托管(即严格意义上的开源)Jenkins控制器必须处理的四大问题——
问题1：管理开销过大
Jenkins潜在的管理摩擦可能会降低工程师和管理员的工作效率。毕竟，如果您的管理员耗尽了所有的时间来处理这些问题，他们将不可避免地依赖于您最好的工程师来收拾残局。有一次，那个工程师就是我，我对此很不高兴。
管理您所有的控制器是复杂且耗时的。与任何Java应用程序一样，Jenkins不是一种“设置好之后就可以忘记它”的技术。控制器需要持续的管理监督，无论是确保适当的垃圾收集还是管理内存使用。
管理、复制和配置跨团队的Jenkins实例相当困难。不同的团队有不同的需求，启动和维护多个专用服务器、为每个服务器配置非标准化的插件集、支持不同的版本控制方案以满足不同的兼容性和安全问题，这对中央管理员和共享服务团队来说是很累的，特别是当他们试图进行任何形式的治理或满足合规性时。
扩大规模会给管理员带来压力，就像它会给基础设施带来的压力一样。随着团队体验到使用Jenkins的成功，其他团队也会想要加入进来。不确定数量的Jenkins控制器(运行不同的工具集)将如何影响磁盘利用率、垃圾收集或内存可用性？正在运行的插件会影响性能吗?您是否需要更多的基础设施来处理不断变化的负载?
插件不会自我维护。管理员要花相当多的时间来更新（或故意不更新），协商兼容性冲突，执行bug解决方法，并解决因插件在控制器和团队中成倍增加带来的安全问题。
Jenkins需要高级JVM技术。更糟糕的是，Jenkins管理员需要以JVM为重点的技能，而他们往往缺乏这些技能。这使得工程师更有可能被拉到管理岗位，以便集中JVM知识来解决问题。
问题2：效率低下
当你花时间一遍又一遍地做同样的任务时，这就是一个问题。低效率会影响团队的生产力，拖延发布计划，并阻碍着企业实现目标。
工作在团队/服务器之间进行不必要的重复。当你想到一个可行的控制器设置时，没有办法在其他服务器/团队之间快速迭代。这意味着每次都要从头开始设置控制器、添加用户、安装插件等。事实上，各种工作流程往往都要反复进行。
基础设施往往被浪费了。如果没有监督和平衡资源利用的方法，基础设施经常被分配到不需要的地方。
工作流程的效率难以复制。如果一个团队想出了一个聪明的设置、工作流或流程创新，没有一个简单的方法来与不同服务器上的其他团队共享这些改进。因此，企业失去了全面提高生产力的宝贵机会。
入职培训可能很乏味。建立新的团队，每次都需要完成一系列重复的任务。这极大地限制了早期阶段的生产力。
缺乏沟通可能会造成严重后果。如果无法做到让工作跨控制器/团队清晰可见，您就会完全依赖于人工沟通——这对大多数企业来说是一个不太好的前景。当团队更新插件、调整流水线、更改网络或防火墙设置，或者在不通知其他团队的情况下启动安全更新时，这可能会特别危险。事情往往会变得糟糕，团队提交支持申请的情况并不少见，他们：“即使我们没有改变任何东西，它还是坏了！”
从无序到有序？如何通过管理Jenkins来解决这些问题
我强调这些Jenkins的缺点完全是出于热爱。Jenkins仍然是最有价值的CI工具，80%的企业使用它是有原因的。你需要弥补它的缺点来释放它真正的力量和潜力，来看看我是如何做的。
用集中式的管理来拯救
对我来说，简单的答案就是我需要一个能够消除摩擦的管理平台，并且额外减少了Jenkins基础设施的隐藏成本。当我建立了一个可以管理所有控制器的集中式权限时，我就有了全面的清晰度、优化和治理的可能性，因为现在我可以从一个单一的门户访问所有相关信息和功能。
这就是为什么CloudBees CI进入了我的生活，它带来了一个可管理的Jenkins解决方案，我用它来克服我自设的困境，以及基础设施挑战。我知道你在想，“又是一个广告……”可能是这样，但这是我只是想分享一个用来实现我的目标的方法。信不信由你——这是我的故事，并且它是成功的。
那么，这与我前面所提到的两个问题有什么关系呢？
让我们从这个单一门户的视觉开始。想象一下，您的团队和所有其他团队一起工作，为了在软件应用中实现神奇功能。
把每个团队想象成根目录下的一个文件夹。该文件夹包含了该团队所需要的所有对象。这个文件夹可以与团队的其他部分区隔，但所有对象都是从根目录中管理的。这个文件夹就是您的轻量级管理的Jenkins实例。而根是CloudBees运营中心。每个团队都有自己的实例和对象，可以自由地使用对他们有用的工具。而你的Jenkins管理部门可以从一个地方看到并管理所有的对象。
CloudBees运营中心提供了一个集中的控制平面，能够实现我最喜欢的一些功能：
对整个Jenkins基础设施的单屏命令
- 所有控制器、项目和团队的透明度；
- 基础设施运行状况监测和警报；
- 即时控制器配置（支持单个团队或团队协作）；
- 创建共享代理；
- 集中管理的身份验证和授权(SSO、SAML、RBAC、LDAP)；
- 跨控制器和项目共享事件或消息；
- 支持将资源作为关联资产集群，进行连接、复用和管理。
企业配置即代码(CasC）
- 从单一来源轻松地管理、配置、复制和更新；
- 一切都是代码：控制平面本身、控制器、代理、项目、插件和流水线模板。
插件管理
- 集中的插件供应、配置、监控和更新(以及协助维护的推荐操作)；
- 插件添加到CasC包中，用于单一来源更新；
- 通过集群操作进行插件更新。
对于那些需要工作清晰可见的人来说，请查看下图，它显示了CloudBees CI操作中心（我们在上面讨论的作为“根”的集中控制平面）如何重新构建您的Jenkins环境，无论是部署在本地，还是云中。
对我来说，实现上述功能不仅对管理我所创建的无序的Jenkins环境有很大帮助，还带来了秩序、透明性和简单的管理，我们的管理员可以轻松在多个团队中实施。
这是我在我的团队中发现的两个问题——也许你也经历过相同的挑战。当我深入研究效率低下问题时，我还发现了一些可以改进的其他方面。在下一篇文章中，我将提出另一些问题，敬请期待。
关于作者：萨曼莎·弗罗斯特（Samantha Frost），CloudBees公司产品营销经理。