Zadig on Github

Zadig on Gitee

背景介绍

药师帮是专注于医药智慧供应链的综合服务平台，而掌店易项目是负责其中药店 ERP 系统这一环节的，为全国药店搭建基础设施，提供增效减本的 SaaS 解决方案。

从 2015 年起，药师帮公司内部逐渐形成了自己的研发体系，其中包括开发，部署，测试，上线等一系列流程。近两年起步的掌电易项目，自然继承了公司内部的这套流程，并基于原有的流程上，进一步优化扩展

事出有因

我们过去的发布部署模式（如下图示）：传统的部署流程，是采用自定义的 Shell 脚本，从代码仓库拉取代码，在物理机本地进行编译生成 JAR 包，然后上传到镜像仓库，并将提前定义好的各个微服务的 Yaml 文件应用更新到 K8s 集群上。 

这种原始的部署流程存在以下一些痛点： 

1. 自定义部署脚本的开发和维护成本高

2. 开发人员提交代码后需要手动去触发部署脚本，一方面是可能会被遗忘，另一方面是很被动

3. 开发人员执行部署脚本后，需要等待部署成功后再通知到测试组开启测试，中间存在许多时间被耽搁

4. 编译部署过程依赖于物理机环境，不同环境 (开发服 / 测试服 / 正式服) 需要做到依赖环境一致很困难

5. 没有对所有发布部署流程的一个情况做相应的记录

6. 需要维护大量微服务的 Yaml 配置文件，以及其中的变量

痛定思痛，于是开始研究起持续性交付解决方案。 

利器善事

都说工欲善其事必先利其器，好的工具是解决问题的关键，所以对持续性交付解决方案的利器选型就至关重要了。

一开始从身边同事渠道，和网友渠道，一致推荐使用 Jenkins 那套自动化部署流程，都说它是持续集成界的神器，你想用它干啥都行。 公司内部还有一个部门在使用 GitLab 的 CI/CD，直接完成代码提交后触发不同条件下的发布部署流程，加上它新版的交互界面和统计界面做的比较优美，让人看的垂涎欲滴，欲罢不能啊。

可是，否定 Jenkins 我个人找了两个理由，一个是界面真的太丑，交互真的太影响心情了，另一个是它需要每个项目里维护一个 Jenkins 流程脚本。 否定 GitLab CI/CD 的原因同样是因为它需要在项目里维护一个 gitlab-ci.yml 的配置文件，和代码项目 "耦合" 是我个人不能接受这两个方案的最主要原因。

于是在知乎上翻找关于 "devops" 的所有文章，偶然间看到这篇 字节和腾讯都在使用，DevOps 工具 Zadig究竟有何魔力 - 知乎 (zhihu.com)，文章里的几个界面截图直接告诉了我的直觉，这就是我脑海中一直想要的解决方案。 于是。。。。。。

学习摸索

上手 Zadig 的最大感触就是简单，学习成本很低，我总结就是： 

1. 安装部署简单：只需要一行命令，一个脚本，一个 K8s 集群，一个命名空间，就可以模拟出来一个环境进行学习和技术预研。 这一步就极大降低了入门的门槛了。

2. 详细的官方文档：对系统各个角落的功能都做了仔细的介绍说明，并提供了多个场景下的最佳实践方案，其中 Spring Boot 项目持续交付 的文案给我们提供了很多的帮助。

3. 社区活跃度高：微信群里问题的及时反馈和跟进，以及后续有针对性的，点对点的飞书文档跟进问题进度，为我们处理解决问题提供了多方面渠道，这个非常 nice~

在其他产品上是很少见到这种多渠道，点对点沟通解决处理产品问题的思路的。 说实话，当初被 Zadig "找上门"，专门拉了个群，还建了个飞书问题跟进文档，还远程语音沟通问题点，真的是受宠若惊的感觉呀！极少有的一种用户的反馈被产品重视的感觉～

起步学习 Zadig 时，非常建议先看一遍官方文档，第一次可以先简单从头到尾过一遍，心里大概有个底，涉及到哪些操作步骤，操作流程，有哪些功能，可以解决自己的哪些痛点。 因为本人遇到比较尴尬的一件事情是，当一键安装好 Zadig，就一头扎进去使用了，刚开始连环境，服务，构建这几个先创建哪个都搞不清楚，自己摸索会遇到一些没必要浪费时间的坑的，也许文档上一句话就解决了困扰自己半天的疑惑。

测试落地

具体落地还是要从开发服和测试服启动，目前已经通过 Zadig 完成开发和测试两个支线的持续交付流程。

后续规划在正式服上搭建一套 Zadig 环境，并打通开发 / 测试两个环境，统一一套 Zadig 解决三个环境下的持续交付流程。 计划正式服的发布是已经经过测试组充分检验过，没有问题的交付物进行发布，而不需要再经过一轮拉取代码，编译打包的工作流程了。

目前测试中心和交付中心两个模块还没有深入使用，也是后续的规划方向。

预计后面正式服落地后，会在公司内部其他团队做一次分享，毕竟独乐乐不如众乐乐嘛。 技术预研期间已和其他项目技术人员沟通过关于 DevOps 这方面的干货，向他们推荐 Zadig，大家都很是期待。

总结经验

Zadig 打通了代码仓库、镜像仓库、K8s 服务集群，实现了研发人员和测试人员之间的无缝联动，自从上了 Zadig 后，之前的痛点都不再痛了 ^_^

1. 不需要再开发和维护大量脚本

2. 研发人员提交代码后，通过工作流自动触发部署，成功后通过企微 Webhook 通知到测试组的企微群里

3. 打包编译都是在 Docker 容器中完成，脱离对物理机环境的依赖，交于 Zadig 统一环境管理

4. 研发部署过程中，所有流程都有记录可循，方便追溯、定位问题

5. 微服务的 Yaml 配置文件可以基于统一一个模板文件，各个微服务也都有各自的变量管理

团队内部对 Zadig 认可度是很高： 

• 研发人员提交代码后直接根据企微群通知就可以知道发布构建的结果是成功还是失败，如果失败了也可以快速通过链接跳转到构建命令提示界面，查看原因，为研发人员节省了大量之前花在编译构建发布流程的时间

• 测试人员也可以根据企微群的服务发布记录提示，看到哪些缺陷已经被修复部署了，节省了和研发人员之间的沟通成本，避免了研发人员已修复的 Bug 但是忘记通知测试人员的情况

当然，以上是基于 Zadig 在药师帮掌店易项目中使用到的功能，以及重点解决的痛点的总结归纳，Zadig 还有其他优势，比如 集成统一账户登录 ， 完善的权限管理 ， 不同环境搭建管理等等，还有待于其他场景下的深入使用 Zadig 功能。 

建议期待

希望 Zadig 越做越好，下面仅以个人观点提几个建议和期待: 

1. 关于集成接口自动化测试流程的实践（类似现在比较流行的 Apipost，Apifox 这类产品），接下来会重点研究和实践 Zadig 测试中心模块，希望把团队的自动化测试也做起来，解决测试端的痛点

2. 是否可以考虑接入 Istio，实现服务的灰度发布，金丝雀发布等应用场景

Zadig，让工程师更专注创造！欢迎加入  开源吐槽群🔥

Zadig on Github

Zadig on Gitee