概述
一个完整的产品交付过程涉及到分支策略、团队的协作流程、基础设施建设等方方面面，有些团队交付效率之所以低下，往往是因为其中的某个环节出了短板，高效的协作需要结合项目所处的阶段、产品交付的频率、团队成员的习惯和素养等来制定适合自己团队的方案。
在团队日常协作过程中，选择一个合适的分支策略尤为重要，在此基础上团队角色之间的协作过程才可以被定义和执行，生产过程才能高效运转，从而产品功能才可高质量交付。
主流的分支策略有：
- 主干开发，主干发布
- 主干开发，分支发布
- 分支开发，主干发布
- GitFlow
- ...
本文主要介绍“主干开发、主干发布”分支策略在 Zadig 上的实践过程。以下实践过程主要以 Gerrit 代码源为例，其他类型代码源比如 GitLab、GitHub、Gitee 同样适用。
什么是主干开发、主干发布
开发代码直接提交到主干分支，经过测试验证后，使用主干分支进行打版上线。
优势：
- 分支管理简单
- 开发易上手，操作简单，不易出错
- 代码合并冲突少
- 适合高频交付
成功关键点：
- 主干分支时刻保持可发布的状态，开发自测阶段/CR 过程/主干分支验证过程需要严格把控
- 未开发完成的功能代码，不能带入将要发布的版本里或者实现功能开关，将未完成的功能隐藏
团队协作流程详解
本地开发&自测 -> 提交 Pull Request 到 主干分支（main） -> 代码审查 & 合并代码 -> 手动验证功能/补充自动化测试用例 -> 基于主干分支交付版本
| 角色 | 关键步骤 |
|---|---|
| 开发工程师 | 0. 本地开发 & 自测 1. 更新自测环境，对改动进行验证 2. 针对自测环境，执行回归测试 |
| 开发工程师 | 1. 提交代码到 主干分支 2. 自动触发 CI 验证 1. 持续集成检查：执行单元测试、静态代码检查等 2. 自动化回归测试：构建->部署->测试 |
| 开发工程师 | 3. 代码审查->合并代码 |
| 测试开发/开发工程师 | 4.1. 基于 主干分支 验证新功能和回归测试 1. 手动验证新功能、补充集成测试用例 2. 执行回归测试 4.2. Bugfix提交到主干 |
| 发布工程师 | 5. 基于 主干 交付可靠版本 |
飞书基于 Zadig 的实践过程
早期飞书的使用场景，其中一个团队有上百个微服务，服务定义使用原生的 K8s YAML 方式，使用 Gerrit 作为代码管理和人工审核工具来实现主干开发主干发布。具体过程如下：
- 提交代码变更：修改代码，提交 MR ，生成 change-id
- 人工审查：添加/通知代码审查人；审查人可以多次 submit 审查，通过一个 transection 提交，通过审查，可以打分 -2 到 2；
- 机器审查： 非阻塞式自动触发 Zadig 工作流执行验证：构建->部署->测试；
- 主干反馈： 工作流跑完后会发送 IM 通知，并执行 Gerrit 打分校验结果 score +1-1
系统可以配置审查规则，比如达到 2 分自动合并，自动化测试比较多的情况可以这样。
- 基于主干发布上线
飞书后续采用 GitLab 管理代码，关于 GitLab 的分支模型和更多实践可参考文档：字节跳动飞书为什么选择 Zadig 实现主干开发、主干发布 | 客户故事
Demo 演示实践
项目基本搭建过程
参考教程：如何使用 Gerrit + Zadig 实现产品级持续交付
更多配置
- 按需创建多个环境，具体参考 配置多套环境 | Zadig 文档
- 工作流配置 IM 通知：工作流 | Zadig 文档
- 多个服务共享构建：构建 | Zadig 文档
日常研发使用过程
开发工程师
- 代码提交并自动验证：提交代码 -> 在 Gerrit 上创建 Change -> 自动触发 Zadig 工作流的执行（构建 -> 动态选择空闲环境进行部署 -> 自动化测试 ）
- 人工代码审查：Reviewer 使用 Gerrit 作为代码审查工具并打分，根据打分结果来判断代码是否可以合并
系统可以配置 rules，比如达到 2 分自动合并
测试开发工程师
- 在 Zadig 上配置管理测试脚本： 测试 | Zadig 文档
- 针对更新后的环境验证新功能，为新功能补充测试用例
发布工程师
- 基于主干已验证的代码进行版本发布
- 发布完成后执行工作流将所有环境中的服务版本与主干保持一致
项目/企业管理人员
查看企业项目整体的运行状况：数据概览 | Zadig 文档
分析项目各个环节的变化过程以及效能短板：效能洞察 | Zadig 文档
扫码即刻咨询
解锁企业专属最佳实践方案！
