企业研发过程中经常遇到这种痛点:研发测试过程缓慢,工程师们在日常代码实现工作之余,还要花大把时间在工程构建、环境部署等事务上。多名团队成员同时部署环境的高峰时期,更会带来因环境资源使用不当而导致等待的低效现象,严重影响业务价值交付效率。
使用 Zadig 可实现环境的负载均衡,零人工干预实现从代码变更 -> 发布到环境中做自测/联调/测试验证。且支持团队成员并行开发、发布、验证,最大化团队合作带宽。
项目介绍
以 microservice-demo
项目为例说明。该项目包括 3 套同构环境,即包含的服务以及服务版本均相同。
通过 Zadig 动态环境能力,日常开发可实现:
- 开发 A 基于主干分支提交一个更新服务 a 的 PR1 -> 自动触发工作流更新某个空闲环境的服务 a -> 针对更新后的环境执行测试脚本
- 开发 B 基于主干分支提交更新服务 b 的 PR2 -> 自动触发工作流更新某个空闲环境的服务 b -> 针对更新后的环境执行测试脚本
- …
注:当前无工作流正在运行对其执行更新的环境即为相对空闲的环境,当多个 PR 同时/先后触发多条工作流任务时,系统会自动对环境进行闲忙负载判断,选择最合理的环境来更新。
当验证通过的 PR1、PR2…合并到稳定的主干分支后,自动触发工作流更新所有环境中的服务,确保所有环境都是最新的稳定版本,后续继续基于最新的稳定环境开展迭代。 下面展开介绍在 Zadig 上如何实现上述的动态环境场景。
实现路径
创建环境
进入 microservice-demo
项目,点击+创建环境
创建多套同构环境,环境数量可根据团队人员配置情况决策。 本文中演示项目的环境和工作流如下:
dev1
/dev2
/dev3
:当前服务版本均基于主干分支,供开发人员日常自测联调等使用microservice-demo-workflow-dev
:当开发人员提交代码变更后,自动选择一个空闲的环境更新microservice-demo-workflow-main
:当主干 main 分支有代码合并时被触发,更新所有环境
配置工作流运行策略
修改工作流 microservice-demo-workflow-dev
,开启运行策略中的并发运行和镜像版本回退,回退策略选择任务执行完成。
- 同一工作流的多个任务默认是串行执行,开启工作流的并发执行可减少任务排队时间。
- 开启镜像版本回退,当工作流执行完毕时会自动回退服务的镜像版本,确保环境始终和主干分支保持一致。
配置 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 小时”的低效现象。
欢迎加入 开源吐槽群?