您可能正在考虑共享Jenkins服务器，或者您担心：
- 谁有时间在多台服务器上进行管理？
- 我们如何确定我们不会在网络上打开巨大的鸿沟（它会发生），从而使我们的代码和测试环境公开？
- 确保人们使用标准工具集
- 避免花费相同服务的多个副本
那么，您为什么不想拥有共享的Jenkins服务器？
在不同的开发组之间共享詹金斯
不要做！
认真！
啊！
每个团队都有自己的需求，很难建立起适合所有人的东西。
你可以分享詹金斯吗？
是的，您可以，并且可以在不同的组中进行操作，但是随着组的多样性而变得越来越困难，并且如果您不为中央管理员提供资源来保持服务器正常工作，那么它就会自欺欺人。
詹金斯的讽刺意味
倾向于使用大的共享盒，以便对安装，更新和访问权限采取保守的态度。 试图减少包装箱上的零钱数量最终将使其无用。
相反，您需要拥抱变化。 接受默认情况下应该安装除了最疯狂的增量更新，补丁和插件之外的所有东西，并且增量变化的任何后果都可以轻松管理。
如果仅在深度测试后进行大的更改，则测试周期和更改阻力会非线性增长。 如果您限制每个人对事物的访问权限，那么会对确实拥有访问权限的人员产生集中的需求，并且他们会被吸引到每个人的项目中。
如何管理共享詹金斯
- 永远不要说永远不说如何？
- 每周运行补丁程序和更新–与通过偶尔的大爆炸更新来破坏大量内容的风险相比，解决对几个构建的小影响更容易解决
- 尽可能提供委派的管理员权限，以便团队可以自行解决
- 紧急处理包装盒上的任何问题–破坏建筑，破坏世界
- 通过非常轻量级的流程提供足够的集中支持，以解决问题
- 接受构建可能很混乱并且应该定期进行清理作业以保持服务器正常工作–磁盘空间，泊坞窗映像，甚至重新启动
- 确保与外部服务的最佳连接性–即，使GitHub集成正常工作要比通过轮询解决缺少Webhooks更好
- 记录无法发现的东西 – Jenkins生态系统已经很倾斜了……如果您安装了人们可以使用的东西，那么就会在一个页面上为那些没有管理员权限去寻找它们的人做广告，例如，哪些工具安装可用
- 共享技巧和窍门 –尽管人们可以弄清楚如何使用围绕您的Jenkins的特定种类的插件和服务，但为什么不共享周围的HOWTO呢？ 鼓励分享。
- 支持整个过程 –防止中断和致命的愚蠢爆发，有人希望他们可以回到几天前的状态。
当然，您无法分享
在拥有自己的詹金斯队的团队中，老年人需要以上大多数技术……只是说一下……如果您作为中心的DevOps类型，决定您不想为多种不同而做这些事情的头痛团队，那么您可以始终：
- 设置Jenkins的构建标准
- 也许提供Docker模板或其他部署脚本来创建Jenkins实例
- 创建安全扫描以确保所有Jenkins实例安全并已更新
- 鼓励跨团队共享HOW-TO和技巧
- 坐下来，让每个人都做自己的项目
集中与联合
二维：
- 整个公司或本地决策的影响力如何？
- 决策多久做出一次-一天几次或更长时间？
示例1：团队决定临时会议使用哪个会议室-对公司的影响几乎为零，决策频率非常高-将该事务的管理委托给团队。
例2：一个团队决定将哪个软件供应商用于新的全球IT系统–对公司的影响–可能是巨大的成本和巨大的影响，因此，决定的频率–很少出现–应该是高级别的决定。
例3：一个团队决定购买更多的订书钉–对公司的影响，小炒，决定的频率，临时的…可能是委派的…除了…如果每个人都总是购买订书钉…那么事实证明，如果有的话，这可能会产生规模经济占公司总支出的绝大部分。 换句话说，在这种中间立场下，您必须进行全局优化。
就Jenkins的讨论而言，对安全性的监管可能是问责制的核心内容，但是服务器的日常使用对于联合/委派来说确实很成熟。 由于这些原因，很难找到一种混合策略…
但是，如果由于缺乏集中的决策/执行而使工作陷入停顿，那么运营模式将非常浪费，需要重新考虑。
翻译自: https://www.javacodegeeks.com/2020/01/the-perils-of-the-shared-jenkins-and-making-decisions.html