用 Zadig 为研发开源节流完成广州公交系统的数字化转型

思创科技作为一家公交行业的互联网转型企业，在规模较小的时候开发人员能够担任“全栈工程师”。所有的研发步骤节点都可以由开发人员参与完成项目迭代上线。但是随着公司的发展，项目的增长和需求的繁多。研发人员在进行代码验证的时候，花费了太多的时间。无法全身心投入到研发过程当中。

同时针对于研发人员天马行空的想法验证也有着局限性。一个行业的创新，必定是需要验证众多天马行空的想法，才能最终实现突破性的创造。但如果依旧按照之前传统的研发体系，那么软件研发创新的可能性就会随着时间的发展，研发人员的精神疲惫，无法获取灵感创新。

IT 技术发展自身技术的跟进和变革（虚拟化无法满足现有状态）

传统的虚拟化在项目中已经逐步地感到“疲惫”。在项目申报中，服务器一般都会有着部分的冗余空间，但是恰恰就是这部分的冗余空间，在某些时刻就是浪费。我们需要做到一个变革，一场能够将 IT 利用率达到最好的变革。

DevOps 和容器化随着研发瓶颈逐渐出现在我们后续的工作中。

DevOps 的探索

为什么选择 Zadig？

起初我们选择的是 Jenkins ，因为 Jenkins 在业内太有名。随意在马路边上拉上一个 IT 从业者，你问他 Jenkins 是什么，他肯定知道。哈哈。随后的落地中，我们也确实是使用着 Jenkins 去做一个探索。起初想做到如下，但是效果不太理想。

• Jenkins 首先创立的初衷是针对于主机服务，在创立的时候并没有为 Kubernetes 留下一道方便之门。
• Jenkins 做持续集成部署有着繁多的 Pipeline 和 Jenkinsfile，Dockerfile 以及各类 K8s 服务 Yaml 文件。在文件管理上略显杂乱。这些东西都是比较有规律的文件，缺乏统一管理。且如果 Jenkins 是包括了以往传统的主机部署项目的话是可以说是继续探索下去的，但是在大规模实现容器化编排的现在 Jenkins 在我们这就有点乏力。
• 但是 Jenkins 有着灵活的插件和 Pipeline ，可以实现人工介入发布，这是我们比较喜欢的一点。但随着项目的上线和使用，发现他的并发构建在现有环境下较慢故暂时搁置。
• Jenkins Pipeline 在微服务发布项目中，需要修改 Pipeline ，造成不必要的麻烦。
• Jenkins 无法对服务的发布顺序做改变，只能通过脚本的形式手动选择顺序发布。

在后续的工作中，发现了 Zadig ，他成为了我们高效研发的“尚方宝剑”。

初识 Zadig

Zadig 其实我觉得接触起来非常容易，前提是你要了解基本的 K8s 概念和你需要构建服务的语言基本情况，这样你使用起来就是直接起飞。

Zadig 在我们这有着高效的研发流程，具体体现在：

1. 高效管理 K8s 服务 Yaml，Helm，微服务的 Dockerfile 的模版，完美解决了 Jenkins 中繁多的文件问题
2. Zadig 完美支持云原生项目和主机项目，可以实现鱼和熊掌，我都要！
3. 在我们扁平化的环境下， Zadig 的效能能够完美覆盖我们的所有场景
4. Zadig 环境管理能力很强大，能够提供其他工具无法提供的环境复制功能，在不同环境下支持不同的 Configmap，环境变量等
5. Zadig 进行 CI 提速较为明显
6. 具有强大的统计数据模块

我们从 1.6 版本就开始使用 Zadig ，那个时候 Zadig 还是一个比较稚嫩的 CI/CD 工具，但是现在都已经发版到 1.12 了，具有太多有用的功能了。

那个时候我们就是十分看重 Zadig 对 Kubernetes CI/CD 的管控力。只需要定义好相关服务的 Yaml ，这个 Yaml 可以从模板库中提取，就十分的 Nice。填写相关的服务参数，就可以实现运行了。并且他可以自定义运行顺序，可以说非常棒。

在后续对 Zadig 的关注中，我们发现他逐步的推出了新的产品。我们对 Zadig 也十分充满信心。在后续我们也尝试过升级，但是那个时候自己电脑上 VMware 做虚拟化升级测试是可以，信心满满的去生产做升级。好家伙，什么服务都起来了，但就是无法访问 UI 界面。只能回退，后续我们在和官方接触后才发现是 Istio 和 Zadig 的网关冲突，在升级的时候关闭了相关的参数后才正常升级，体验到了更好的产品。通过这个事件我也体会到了开源产品社区和用户之间的联系更紧，那么问题定位也能更方便，不断的使用产品，不断的反馈，社区不断的打磨，铸就一个更为强大的产品诞生，未尝不是一件美事。

怎么判断 Zadig 是否适合你

如果你们公司的是和我们一样在推动数字化转型，容器化编排，那么 Zadig 十分适合你。

如果你们公司用着 Jenkins 做传统的主机发布管理，这个时候要上 Kubernetes 实现容器化，那么 Zadig 同样适合你们，可以做到 Jenkins 和 Zadig 的集成发布。

如果你们公司的项目较为扁平化，那么 Zadig 可以基本覆盖 95% 的场景，加上 Zadig 众多的优势，何乐不为呢？

如果你们公司刚刚开始进行云原生探索，那么 Zadig 是你们的不二之选，上手快，社区活跃度高。问题响应之快，绝对可以为贵公司 DevOps 理念的落地提供技术支撑。

Zadig 实现的价值

Zadig 不仅仅是一个优秀的 CI/CD 工具，他更是 DevOps 文化的践行者。通过 Zadig 我们实现了高效研发，在研发人员的每日研发利用率上对比以往做到了更大的提升，省出宝贵时间去创造更多产品价值。

• 针对需求迭代，做到了每日服务需求有更新
• 针对开发验证，可以做到集成环境资源的收缩自如
• Zadig 不仅实现了自身的企业价值，还帮助解决了我们这些软件企业发展中的许多瓶颈问题。

使用情况总结

• 当前思创科技产品业务线 5 条，其中 3 条业务线都已完全接入 Zadig，其余 2 条业务线属于传统业务，更新频率较低。
• 通过 Zadig 管理了3个集群，其中 2 套集群为远端业务集群。部分环境无法通过 Kubernetes 去编排容器实现远程发布，通过zadig的主机项目，实现远程容器发布，方便后续的业务迁移。
• 运行环境 17 个其中 12 个测试、5 个生产，共计 200+ 个应用程序，实现了 4000+ 次自动化构建和部署，部署成功率 99% 以上 从发布频率上看，以往都是有开发人员主动介入发布，在本地通过打包的形式部署在服务器上，发布。一天发布的频率大约在 10 次上下。在接入 Zadig 之后代码更新迭代的频率得以飞速提升，慢的一天也是30 左右，快的一天 70 余次。