您的位置: 首页 > 技术杂谈 > 正文

使用 GitLab/GitHub/Gerrit + Zadig 实现主干开发主干发布（含字节飞书实践）

2022-05-25 17:00 https://my.oschina.net/koderover/blog/5530694 Zadig云原生交付次阅读条评论

概述

一个完整的产品交付过程涉及到分支策略、团队的协作流程、基础设施建设等方方面面，有些团队交付效率之所以低下，往往是因为其中的某个环节出了短板，高效的协作需要结合 项目所处的阶段、 产品交付的频率、 团队成员的习惯和素养等来制定适合自己团队的方案。

在团队日常协作过程中，选择一个合适的分支策略尤为重要，在此基础上团队角色之间的协作过程才可以被定义和执行，生产过程才能高效运转，从而产品功能才可高质量交付。

主流的分支策略有：

本文主要介绍“主干开发、主干发布”分支策略在 Zadig 上的实践过程。以下实践过程主要以 Gerrit 代码源为例，其他类型代码源比如 GitLab、GitHub、Gitee 同样适用。

开发代码直接提交到主干分支，经过测试验证后，使用主干分支进行打版上线。

优势：

成功关键点：

本地开发&自测 -> 提交 Pull Request 到主干分支（main） -> 代码审查 & 合并代码 -> 手动验证功能/补充自动化测试用例 -> 基于主干分支交付版本

团队协作流程

团队协分工

早期飞书的使用场景，其中一个团队有上百个微服务，服务定义使用原生的 K8s YAML 方式，使用 Gerrit 作为代码管理和人工审核工具来实现主干开发主干发布。具体过程如下：

系统可以配置审查规则，比如达到 2 分自动合并，自动化测试比较多的情况可以这样。

上述 过程 3 依赖测试环境，容易造成环境资源的浪费和审查过程等待的情况，飞书团队选择使用 Zadig Webhook 动态分配空闲环境的能力，既可以合理利用环境资源又不阻塞机器审查过程。

服务配置提取出不同的环境变量来区分集成环境，根据人员的配置情况，创建 4 个同构环境，日常开发只需要提交代码并创建 Gerrit change，自动触发工作流做代码的构建部署和自动化测试。

开发 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 -> 更新所有的环境，保证所有环境和主干一致。