Jenkins 将致力于提升稳定性、易用性和云原生兼容性

Jenkins 项目团队决定在稳定性和为 Kubernetes 等平台提供更好的支持方面分配一些工作量。前者可能会发生一些向后不兼容的变更，将影响发布模型并提供具有更多预置选项的版本，而后者将在与现有 Jenkins X 项目齐头并进。

Jenkins 目前在处理大型复杂管道方面可能不太稳定。Jenkins 的创始人兼 CloudBees 首席技术官 Kohsuke Kawaguchi 写道，由于资源问题和插件的升级，部分部署需要频繁重启。配置可能很脆弱，插件管理以及更改构建作业的设置可能会无法立即可见。为避免对系统造成破坏，系统管理员对变更总是犹豫不决。最终用户体验很复杂，因为 Jenkins 需要配置太多组件才能完成工作。由于没有足够的测试覆盖率，Jenkins 本身的开发速度受到限制。因为评审的周期太长，新老开发者的贡献受到了影响，这可能会对他们未来的贡献造成阻碍。

该提案的一部分试图通过更改发布模型并在保持向后兼容性方面采取措施来解决这些问题。在 Jenkins World 2017 贡献者峰会上，Kawaguchi 划定了应该开箱即用的 Jenkins 功能和需要管理员配置的功能区分。后者包括设置 HipChat/Slack 集成、Webhook 集成以及系统层面的设置（如用于电子邮件通知的 SMTP）。他还提出，部分解决方案是“将核心和一些重要的插件作为基础”，这样 Jenkins 就可以预先配置它们并缩短花在配置上的时间。 Jenkins 2.0 模型将继续，但可能会引入破坏向后兼容性的变更。

由 Jenkins Cloud Native SIG 驱动的云原生 Jenkins 提议是关于在 Kubernetes 等云原生平台上运行 Jenkins。 Jenkins X 平台就是这样的一个项目，它使用 Jenkins 作为核心引擎，并增加了一个工具集。Kawaguchi 表示，云原生 Jenkins 的未来是朝着 Jenkins X 的方向发展。这个版本的 Jenkins 很可能有一个不同的架构——将各种功能作为单独的微服务，使用功能即服务，而不是现在的这种构建进程，以及通过Kubernetes 自定义资源进行交互的服务。当前存储在文件系统上的数据将被移动到云存储服务。 Jenkins Configuration as Code （JCasC）项目尝试使用 Jenkins 主节点的声明性配置解决一些配置问题。此外， Jenkins Evergreen 项目“为最终用户提供了可以立即用于实现 CI 和 CD 工作负载的预装配件集”。Evergreen 可以进行自动更新。这两个将是云原生计划的关键部分。其他 CI 解决方案（如 Gitlab CI ）已经可以与托管 Kubernetes 服务集成。

Jenkins X 通过环境的概念在Kubernetes 上实现微服务部署，环境概念表示源代码存储库中给定点的一组协同工作的服务。我们可以为Dev、Staging 和Production 或任何其他发布阶段创建环境。环境映射到Kubernetes 名称空间。Jenkins X 提供了一个名为jx 的命令行工具，可用于管理环境、在环境之间切换以及升级Jenkins 平台本身。它目前可以在MacOS 和Linux 上运行，并支持主要的云提供商，如AWS、GKE 和Azure。

考虑到其他CI 工具已经提供了类似的支持，有些用户认为这些努力为时已晚，但Jenkins 拥有庞大的用户群，或许它仍然可以给这些用户和新用户带来好处。

查看英文原文： Jenkins to Focus Efforts on Stability, Ease of Use and Cloud Native Compatibility