“Jenkinsteins”——单体服务器

创建一个统一的Jenkins服务器并让组织中的每个人都使用它，这就是Jenkinstein方法，可能看起来很明智，但它会使您的服务器变得非常脆弱，并有可能使业务增长停滞。让我们看看Jenkins单体应用的四个主要问题。

• 缓慢的服务器：当服务器过载时，会直接影响构建和测试时间，从而影响您快速创新的能力。

• 单点故障：如果您的唯一Jenkins服务器出现故障，整个软件组织的生产力就会暂停，直到中断得到解决。 

• 插件冲突：插件是Jenkins伟大的一部分，但是由于各个团队的不同要求，拥有一个统一的Jenkins服务器会产生插件冲突的可能性。

• 个人依赖：一切都取决于组织中“Jenkins伙伴”配置和维护脆弱的设置。

当这些摩擦出现时，许多团队选择自行出击，这就产生了Jenkins孤岛。

“Jenkins孤岛”——断开连接的控制器

通常，组织内的每个团队都有自己的Jenkins控制器。这确实阻止了Jenkinsstein的问题，但也带来了新的麻烦。所有这些单独的服务器都营造出每个团队都在自己的孤岛上生活的感觉。结果呢？

• 没有治理：让每个团队都按照自己的一套规则和实践工作是一场治理噩梦。控制谁有权访问什么几乎是不可能的，并且不会出现最佳实践。 

• 合规性挑战：没有适当的机制来确保团队始终如一地运行测试。例如，一些团队可能会将安全扫描内置到其流水线的每个部分中，而其他团队可能不会。您将永远无法以这种方式实现法规合规性。

• 缺乏协作：很难在不同断开的Jenkins控制器之间切换任务。如果一个团队发现了一种更有效地做事的新方法，他们就没有实际的方法与其他孤立的团队共享这些信息。

• 隐藏成本：工程师不应该浪费他们宝贵的时间和资源来维护一系列Jenkins实例和配置。

请记住：没有人是一座孤岛，Jenkins控制器也一样。

优化和扩展Jenkins，实现更快、更可靠的DevOps

无论是Jenkins蔓延、单体控制器、插件漏洞、耗时的管理任务，还是不断膨胀的基础设施成本，管理和扩展开源Jenkins（更不用说创造一种文化，打破孤岛，每个人都在一个共享的愿景）是一项艰巨的任务。为了实现所有这些，您需要为所有运行Jenkins的开发团队提供共享、集中管理、受管控的体验——这就是CloudBees CI所提供的。