您现在的位置是：首页 > 文章详情

Jenkins 这么玩也能云原生

日期：2023-11-23点击：209收藏

Jenkins 是在 IT 上云之前诞生的一款老牌代码构建工具，而云原生的 Zadig 相比 Jenkins，更加合适云智时代的应用开发，这一点我们在「 Zadig vs. Jenkins 详细比对：时代的选择与开发者之选」和一文中有详细的对比：Zadig 不仅拥有几乎与 Jenkins 相当的全部功能，还在 DevOps 全流程能力方面具备十倍高的扩展性、易用性和安全性。

然而对于已经耗费大量时间和人力打造出来的 Jenkins 服务配置和流水线的企业，他们可能希望短期内在不做太多改变的情况下快速接入新平台。在 Zadig 最新版本中，我们提供了一种快速接入并与 Jenkins 融合的解决方案，这将有助于数千个服务的高效接入，使更多企业能够迅速融入云原生 DevOps 的快车道。

一、哪些场景适用该融合方案？

场景一：Jenkins Job 数量繁多，疼！

在企业中，我们已经使用 Jenkins 实现了微服务的原子化构建和部署管理。每个微服务都对应一个 Jenkins Job，导致存在大量的 Job，可能达到成百上千个。这种情况下，每次服务变更都需要手动执行多个 Job，面临以下痛点：

1. 干扰信息过多： 每次发布都需要从海量的 Job 中筛选出需要执行的目标 Job，这消耗了大量时间和精力。

2. 自动化难度高：手动触发多个 Job 执行，这是繁重的重复操作，难以一键批量发布，自动化实现困难。

3. 发布决策效率低：必须分别追踪每个发布 Job 的执行结果，这降低了生产发布决策的效率。

4. 信息碎片化严重：缺乏统一的管理平台，导致发布信息分散，一次发布的信息追溯变得异常困难。

Zadig 工作流可编排 Jenkins Job，触发 Jenkins Job 并发执行，让海量 Job 的管理和执行复杂度从思考题变为选择题，而且可在一个页面中追溯多个 Job 的执行信息。

场景二：研发交付过程碎片化，苦！

在研发交付流程中，处理代码/业务变更、数据变更和配置变更可能很繁琐。尽管我们已经使用 Jenkins Job 将业务变更实现自动化，但整个流程仍然存在碎片化的问题。

1. 繁重的 Jenkinsfile 管理： 研发人员需要编写和维护许多 Jenkinsfile，这分散了他们的注意力，难以专注于业务价值。

2. 数据和配置变更的难题：数据和配置变更通常没有好的自动化解决方案，需要涉及多个团队和角色，导致高昂的沟通成本和低效的交付速度。

Zadig 支持业务、数据、配置一站式变更，支持 Nacos、Apollo 等配置管理工具，支持基于 MySQL、MariaDB、Flyway 等的数据变更。无需编写脚本，一次集成后开箱即用，真正让开发工程师聚焦在业务价值创造上，让运维工程师从支持开发日常工作琐事中解放出来。此外，支持传递 Jenkins Job 参数实现充分连接，工作流支持审批功能，保障生产发布的合规和安全。