从数据到大模型应用，11 月 25 日，杭州源创会，共享开发小技巧

阅读原文/Zadig 在 Github/Zadig 在 Gitee

推荐阅读：是时候和 Jenkins 说再见了/Zadig vs. Jenkins 详细比对：时代的选择与开发者之选/平台工程和 AI 时代的新 10 亿开发者

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 参数实现充分连接，工作流支持审批功能，保障生产发布的合规和安全。

场景三：权限配置膨胀，乱！

Jenkins 中实现权限管理的方式是将用户和角色平铺成一张表格，管理员通过勾选的方式来配置用户权限。随着企业发展、员工动态变化、业务演进，权限表格会变得异常膨胀，维护的心智负担非常高。

Zadig 支持不同维度的用户/用户组以及权限管理：系统全局、业务项目、工作流资源…权限可以由每一个业务团队自己分配，在保证权限隔离的基础上有效降低权限管理的负担。

二、如何快速融合 Jenkins & Zadig？

第一步：获取 Jenkins API Token

Jenkins 管理员访问Configure，操作Add n服务器托管网ew Token，添加 API Token。

第二步：集成 Jenkins

Zadig 管理员访问系统集成 >CI/CD 工具，配置 Jenkins 集成信息

第三步：配置 Zadig 工作流，编排 Jenkins Job

参考文档[1]配置自定义工作流，配置开发环境工作流，包含Apollo 配置变更->构建部署->Mysql 数据变更->自动化测试步骤，在构建部署阶段添加「执行 Jenkins Job」任务，配置 Jenkins Job。

执行工作流，选择Jenkins Job即可，可在 Zadig 中管理和追踪整个交付过程。

参考资料

[1] https://docs.koderover.com/zadig/Zadig%20v2.0.0/project/common-workflow/