Zadig on Github

Zadig on Gitee

在互联网大肆发展，数字化转型的背景下，互联网出行大肆盛行的当下，传统的客运站已经逐渐站在了城市的边缘。越来越多的人出行选择了高铁、飞机。客运站更多时候都起着一个追溯曾经的青春的作用，是老一辈的人的出行首选，因为他们不太懂这些“新潮玩意”（互联网出行），但随着出行方式的多变，客运站售票方式多样化和个人用户出行目标的不变，我们需要拓展多样化的售票方式对用户去做支撑，大量的用户涌入和需求迭代就对 IT 基础设施带来了新的挑战。

本文作者：思创 运维工程师 唐启涛

1. 企业研发瓶颈

企业研发效率慢，开发人员不能全身心投入到需求开发当中

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

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

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

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

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

2. DevOps  的探索

为什么选择  Zadig？

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

• Jenkins 首先创立的初衷是针对于主机服务，在创立的时候并没有为 Kubernetes 留下一道方便之门

• Jenkins 做持续集成部署有着繁多的 Pipeline 和 Jenkinsfile，Dockerfile 以及各类 K8s 服务 Yaml 文件。在文件管理上略显杂乱。这些东西都是比较有规律的文件，缺乏统一管理。且如果 Jenkins 是包括了以往传统的主机部署项目的话是可以说是继续探索下去的，但是在大规模实现容器化编排的现在 Jenkins 在我们这就有点乏力。

• 但是 Jenkins  有着灵活的插件和 Pipeline ，可以实现人工介入发布，这是我们比较喜欢的一点。但随着项目的上线和使用，发现他的并发构建在现有环境下较慢故暂时搁置。

• Jenkins  Pipeline  在微服务发布项目中，需要修改 Pipeline ，造成不必要的麻烦

• Jenkins 无法对服务的发布顺序做改变，只能通过脚本的形式手动选择顺序发布

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

3. 初识 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 的网关冲突，在升级的时候关闭了相关的参数后才正常升级，体验到了更好的产品。通过这个事件我也体会到了开源产品社区和用户之间的联系更紧，那么问题定位也能更方便，不断的使用产品，不断的反馈，社区不断的打磨，铸就一个更为强大的产品诞生，未尝不是一件美事。

4. 落地和反馈

在 Zadig 落地后，项目的开发验证得到了跨越式的发展，以往的验证都是自己本地 IDE 启动，然后本地测试，测试人员无法进行测试。但是随着 Zadig 的流水线作业。服务的迭代速度也是越来越快。并且在扁平化的项目中， Zadig 可以对项目环境进行快速复制验证，保障在环境下的隔离。

在之前我们可能还考虑说是大家对这个有所抵触，但是随着第一个项目的成功上线，后续大家对于这些东西都不再排斥，反而是主动申请使用上线。毕竟谁不想做一个 “专一” 的人呢？

Zadig 大大提升了每日开发想法的验证个数，极大地提升了研发效能。同时随着项目容器化，越来越多的虚拟机被释放出来，实现了 IT 资源的进一步高利用率。

5. 怎么判断 Zadig 是否适合你

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

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

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

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

6. Zadig 实现的价值

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

• 针对需求迭代，做到了每日服务需求有更新

• 针对开发验证，可以做到集成环境资源的收缩自如

• Zadig 不仅实现了自身的企业价值，还帮助解决了我们这些软件企业发展中的许多瓶颈问题。

7. 使用情况总结

• 当前思创科技产品业务线 5 条，其中 3 条业务线都已完全接入 Zadig，其余 2 条业务线属于传统业务，更新频率较低。

• 通过 Zadig 管理了3个集群，其中 2 套集群为远端业务集群。部分环境无法通过 Kubernetes 去编排容器实现远程发布，通过zadig的主机项目，实现远程容器发布，方便后续的业务迁移。

• 运行环境 17 个其中 12 个测试、5 个生产，共计 200+ 个应用程序，实现了 4000+ 次自动化构建和部署，部署成功率 99% 以上

从发布频率上看，以往都是有开发人员主动介入发布，在本地通过打包的形式部署在服务器上发布，一天发布的频率大约在 10 次上下。在接入 Zadig 之后代码更新迭代的频率得以飞速提升，慢的一天也是30 左右，快的一天 70 余次

8. 对 Zadig 和开源社区期待

在发展上希望未来 Zadig 能够在开源领域多多提升自身活跃度，多参加开源社区的活动和开源峰会布道推广，例如：KubeCon，CloudNativeCon，Open Source Summit 等。希望让更多的企业，研发负责人，一线员工能够看到 Zadig 在云原生时代对 DevOps 的强有力的改变。也希望 Zadig 社区能够越做越好。

至于什么其他 Zadig 功能性的建议，我也不再献丑了。

• 因为自我技术阅历较少，不方便提及。

• Zadig 在现有环境下已经能够满足普通技术扁平化的公司 90% 的 CI/CD 覆盖了。如果必须提的话可能就是在项目管理集成和版本控制上关联，无法将 Zadig 中的发版和其他例如：CODING，禅道等项目管理软件结合。

言行至此，内心感慨，再祝愿 Zadig 越做越好。

也祝愿 Zadig 团队在上海能够万事遂意，身体安康！！！

Zadig，让工程师更专注创造！

欢迎加入 开源吐槽群🔥

Zadig on Github

Zadig on Gitee