Jenkins CI / CD遇到了麻烦，因此其创始人希望将其拆分

最新推荐文章于 2023-04-23 11:40:58 发布

cxu0262

最新推荐文章于 2023-04-23 11:40:58 发布

阅读量188

点赞数

文章标签：运维 ui

流行的开源CI / CD系统Jenkins已走到了一个十字路口，创始人Kohsuke Kawaguchi希望解决导致平台失去吸引力的问题，包括不稳定和配置问题。

川口在公告中说，詹金斯社区的自治性质使其无法解决一些问题，而对于这个已有十多年历史的项目而言，这些问题变得更加明显。

[InfoWorld的要点： CI / CD入门：使用CI / CD管道自动执行应用程序交付。 • CI / CD的5个常见陷阱以及如何避免它们。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

在川口的计划下，该平台日益增长的烦恼将通过两方面的发展愿景来解决：

Cloud Native Jenkins是运行在Kubernetes上的通用CI / CD引擎，它包含根本不同的架构架构和可扩展性机制。
Jenkins中的Jolt，继续了Jenkins 2升级的增量轨迹，但用户能够获得真正需要的东西，例如更快的开发速度和更高的稳定性。

詹金斯怎么了

川口列出了詹金斯的问题，其中包括：

对于Jenkins实例（尤其是大型实例）， 服务不稳定 ，需要太多开销才能保持运行并需要每天重启。每次重新启动都意味着服务质量下降，软件交付团队必须等待更长的时间才能进行构建。管理员希望Jenkins能够更好地防御管道执行问题和流程失控等问题
脆弱的配置 ，Jenkins管理员必须应对这种脆弱的配置 ，例如安装和升级插件以及调整作业设置，这些更改已引起意外的副作用。太多的管理员不确定他们可以安全地进行更改。升级Jenkins和插件是这种情况的重要子案例，管理员通常不了解其影响，因此降低了他们的升级意愿，并使项目难以快速进行。随之而来的是兼容性负担。
大会要求 ，与平台不工作开箱即用，但需要组装，就像乐高积木的水桶。
降低了开发速度 ，跨多个插件的更改证明很困难，并且测试没有足够的信心来交付代码。

尽管川口的提议或许描绘了詹金斯所处地位的严峻局面，但他说该项目的未来仍然非常光明，表明采用率正在不断提高。提议的更改将使Jenkins被更广泛的开发人员和开发人员团队所使用。

提案1：Cloud Native Jenkins子项目

经过几次努力的融合，提出了Cloud Native Jenkins作为Cloud Native Special Interest Group中的一个子项目。在Kubernetes容器编排的支持下，该项目将包含无服务器计算，微服务，以及-为了促进重用和可组合性-Kubernetes定制资源定义。

同样，新的扩展性机制将继续詹金斯生态系统。例如，基于微服务或容器的可扩展性避免了服务不稳定。

还可以设想共享管道的库。拟议的Cloud Native Jenkins子项目的其他组件包括：

获取长期数据并将其移至云。
Jenkins Configuration as Code的中心角色是通过纯文本YAML语法定义配置，以帮助缓解脆弱的配置问题。
默认安全设计。
Jenkins Evergreen，一个旨在解决Jenkins的脆性和开发人员速度问题的项目。 Evergreen具有预先组装好的组件集合，可立即用于实施CI和CD工作负载。
Cloud Native Jenkins MVP（最低可行产品），具有功能即服务风格的构建引擎，可在Kubernetes上的Jenkins X云系统下使用。该MVP包含一个Webhook接收器服务，以触发构建引擎，并通过Evergreen不断交付。但是它将没有Blue Ocean风格的UI 。

CloudBees对Jenkins的发展至关重要，并聘用川口作为其首席技术官，提出了Jenkins管道的持续发展作为改版的一部分。 Jenkins中的CD管道提供了可以声明性或脚本化的工作流。目前正在进行一项工作，以删除管道的连续传递式执行并隔离执行期间的故障。该计划是为了发展管道，使其与Cloud Native Jenkins的工作良好地配合。