企业研发过程中经常遇到这种痛点：研发测试过程缓慢，工程师们在日常代码实现工作之余，还要花大把时间在工程构建、环境部署等事务上。多名团队成员同时部署环境的高峰时期，更会带来因环境资源使用不当而导致等待的低效现象，严重影响业务价值交付效率。

使用 Zadig 可实现环境的负载均衡，零人工干预实现从代码变更 -> 发布到环境中做自测/联调/测试验证。且支持团队成员并行开发、发布、验证，最大化团队合作带宽。

项目介绍

以 microservice-demo 项目为例说明。该项目包括 3 套同构环境，即包含的服务以及服务版本均相同。

通过 Zadig 动态环境能力，日常开发可实现：

1. 开发 A 基于主干分支提交一个更新服务 a 的 PR1 -> 自动触发工作流更新某个空闲环境的服务 a -> 针对更新后的环境执行测试脚本
2. 开发 B 基于主干分支提交更新服务 b 的 PR2 -> 自动触发工作流更新某个空闲环境的服务 b -> 针对更新后的环境执行测试脚本
3. ...

注：当前无工作流正在运行对其执行更新的环境即为相对空闲的环境，当多个 PR 同时/先后触发多条工作流任务时，系统会自动对环境进行闲忙负载判断，选择最合理的环境来更新。

当验证通过的 PR1、PR2...合并到稳定的主干分支后，自动触发工作流更新所有环境中的服务，确保所有环境都是最新的稳定版本，后续继续基于最新的稳定环境开展迭代。 下面展开介绍在 Zadig 上如何实现上述的动态环境场景。

实现路径

创建环境

进入 microservice-demo 项目，点击+创建环境创建多套同构环境，环境数量可根据团队人员配置情况决策。 本文中演示项目的环境和工作流如下：

• dev1/dev2/dev3 ：当前服务版本均基于主干分支，供开发人员日常自测联调等使用
• microservice-demo-workflow-dev：当开发人员提交代码变更后，自动选择一个空闲的环境更新
• microservice-demo-workflow-main：当主干 main 分支有代码合并时被触发，更新所有环境

配置工作流运行策略

修改工作流 microservice-demo-workflow-dev，开启运行策略中的并发运行和镜像版本回退，回退策略选择任务执行完成。

1. 同一工作流的多个任务默认是串行执行，开启工作流的并发执行可减少任务排队时间。
2. 开启镜像版本回退，当工作流执行完毕时会自动回退服务的镜像版本，确保环境始终和主干分支保持一致。

配置 Webhook 触发器

编辑工作流 microservice-demo-workflow-dev，配置 Webhook 触发器。 说明：

• 部署环境：选择多套用于部署的环境
• 环境更新策略：选择动态选择空闲环境更新
• 触发事件：选择 Pull requests
• 参考 触发器配置 | Zadig 文档 完成其他 Webhook 配置项

编辑工作流 microservice-demo-workflow-main，配置多个 Webhook 触发器，用于确保所有环境时刻和主干分支一致。 说明：

• 分别配置触发器对应 dev1、dev2、dev3 环境
• 环境更新策略：选择更新指定环境
• 触发事件：选择 Push commits 和 Push tags

配置 IM 通知

编辑工作流 microservice-demo-workflow-dev，添加通知配置，以飞书示例如下。

除飞书外，系统还支持企业微信、钉钉，配置可参考 IM 通知 | Zadig 文档。

至此所有配置完毕，下面我们提交代码变更看看具体效果。

效果演示

当多名开发者先后提交多个代码变更后，Webhook 能力会自动触发 Zadig 工作流，并对环境实现负载均衡，自动选择空闲环境进行更新。本例中 3 个先后产生的代码变更将会分别被部署到 dev1、dev3、dev2 环境中。 待工作流执行结束，会自动将结果发送到 IM 系统中，对于失败的情况对应工程师可及时跟进排查，对于成功的情况可及时通知相关同学完成代码 review 以及合并事项，快速集成。

小结

通过对工作流做简单配置，便可使用环境的负载均衡能力，实现代码变更后自动部署到空闲环境中，避免环境资源使用不合理导致互相等待；工作流的并发执行能力以及 IM 及时通知，帮助放大团队研发带宽，让工程师更专注在业务价值创造上，不再发生“写代码 5 分钟，上线 2 小时”的低效现象。

欢迎加入 开源吐槽群🔥

Zadig on Github
Zadig on Gitee