使用 GitLab/GitHub/Gerrit + Zadig 实现主干开发主干发布(含字节飞书实践)
- 主干开发,主干发布
- 主干开发,分支发布
- 分支开发,主干发布
- GitFlow
- ...
什么是主干开发、主干发布
- 分支管理简单
- 开发易上手,操作简单,不易出错
- 代码合并冲突少
- 适合高频交付
- 主干分支时刻保持可发布的状态,开发自测阶段/CR 过程/主干分支验证过程需要严格把控
- 未开发完成的功能代码,不能带入将要发布的版本里或者实现功能开关,将未完成的功能隐藏
团队协作流程详解
飞书基于 Zadig 的实践过程
- 提交代码变更:修改代码,提交 MR ,生成 change-id
- 人工审查:添加/通知代码审查人;审查人可以多次 submit 审查,通过一个 transection 提交,通过审查,可以打分 -2 到 2;
- 机器审查:非阻塞式自动触发 Zadig 工作流执行验证:构建->部署->测试;
- 主干反馈:工作流跑完后会发送 IM 通知,并执行 Gerrit 打分校验结果 score +1-1
系统可以配置审查规则,比如达到 2 分自动合并,自动化测试比较多的情况可以这样。
- 基于主干发布上线
- 开发 A 提交一个更新 service-a 的 PR1,自动触发 Zadig 工作流 -> 构建 service-a ->更新 ENV1 的 service-a -> 针对 ENV1 执行测试脚本
- 开发 B 提交一个更新 service-b 的 PR2,自动触发 Zadig 工作流 -> 构建 service-b ->更新 ENV2 的 service-b -> 针对 ENV2 执行测试脚本
- PR1、PR2 合并 Master 后分别触发工作流 -> 构建 service-a、构建 service-b -> 更新所有的环境,保证所有环境和主干一致。
动态分配空闲环境实践
Demo 演示实践
-
项目基本搭建过程
-
更多配置
- 按需创建多个环境,具体参考 配置多套环境 | Zadig 文档
- 工作流配置 Webhook 触发器:环境的负载均衡 | Zadig 文档
- 工作流配置 IM 通知:工作流 | Zadig 文档
- 多个服务共享构建:构建 | Zadig 文档
日常研发使用过程
开发工程师
- 代码提交并自动验证:提交代码 -> 在 Gerrit 上创建 Change -> 自动触发 Zadig 工作流的执行(构建 -> 动态选择空闲环境进行部署 -> 自动化测试 )
- 人工代码审查:Reviewer 使用 Gerrit 作为代码审查工具并打分,根据打分结果来判断代码是否可以合并
系统可以配置 rules,比如达到 2 分自动合并
测试开发工程师
- 在 Zadig 上配置管理测试脚本: 测试 | Zadig 文档
- 针对更新后的环境验证新功能,为新功能补充测试用例
发布工程师
- 基于主干已验证的代码进行版本发布
- 发布完成后执行工作流将所有环境中的服务版本与主干保持一致


