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

k8s技术圈

共 3218字,需浏览 7分钟

 ·

2022-05-28 16:00

●●●


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

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

主流的分支策略有

  • 主干开发,主干发布

  • 主干开发,分支发布

  • 分支开发,主干发布

  • GitFlow

  • ...

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



什么是主干开发、主干发布

 

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



主干开发、主干发布


优势:

  • 分支管理简单

  • 开发易上手,操作简单,不易出错

  • 代码合并冲突少

  • 适合高频交付


成功关键点:

  • 主干分支时刻保持可发布的状态,开发自测阶段/CR 过程/主干分支验证过程需要严格把控

  • 未开发完成的功能代码,不能带入将要发布的版本里或者实现功能开关,将未完成的功能隐藏


团队协作流程详解


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


团队协作流程


团队协作分工


飞书基于 Zadig 的实践过程


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



1.提交代码变更:修改代码,提交 MR ,生成 change-id


2.人工审查:添加/通知代码审查人;审查人可以多次 submit 审查,通过一个 transection 提交,通过审查,可以打分 -2 到 2;


3.机器审查:非阻塞式自动触发 Zadig 工作流执行验证:构建->部署->测试;


4.主干反馈:工作流跑完后会发送 IM 通知,并执行 Gerrit 打分校验结果 score +1-1

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

5.基于主干发布上线


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


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


  1. 开发 A 提交一个更新 service-a 的 PR1,自动触发 Zadig 工作流 -> 构建 service-a ->更新 ENV1 的 service-a -> 针对 ENV1 执行测试脚本


  2. 开发 B 提交一个更新 service-b 的 PR2,自动触发 Zadig 工作流 -> 构建 service-b ->更新 ENV2 的 service-b -> 针对 ENV2 执行测试脚本


  3. PR1、PR2 合并 Master 后分别触发工作流 -> 构建 service-a、构建 service-b -> 更新所有的环境,保证所有环境和主干一致。


动态分配空闲环境实践


飞书后续采用 GitLab 管理代码,关于 GitLab 的分支模型和更多实践可参考文档:字节跳动飞书为什么选择 Zadig 实现主干开发、主干发布 | 博客[3]


Demo 演示实践


1.项目基本搭建过程

参考教程:如何使用 Gerrit + Zadig 实现产品级持续交付[4]


2.更多配置

  1. 按需创建多个环境,具体参考:配置多套环境 | Zadig 文档[5]

  2. 工作流配置 Webhook 触发器:环境的负载均衡 | Zadig 文档[6]

  3. 工作流配置 IM 通知:工作流 | Zadig 文档[7]

  4. 多个服务共享构建:构建 | Zadig 文档[8]


日常研发使用过程


开发工程师

1.代码提交并自动验证:提交代码 -> 在 Gerrit 上创建 Change  -> 自动触发 Zadig 工作流的执行(构建 -> 动态选择空闲环境进行部署 -> 自动化测试 )



2.人工代码审查:Reviewer 使用 Gerrit 作为代码审查工具并打分,根据打分结果来判断代码是否可以合并

系统可以配置 rules,比如达到 2 分自动合并。


测试开发工程师

  1. 在 Zadig 上配置管理测试脚本:测试 | Zadig 文档[9]

  2. 针对更新后的环境验证新功能,为新功能补充测试用例


发布工程师

  1. 基于主干已验证的代码进行版本发布

  2. 发布完成后执行工作流将所有环境中的服务版本与主干保持一致


项目/企业管理人员

  1. 查看企业项目整体的运行状况:数据概览 | Zadig 文档[10]

  2. 分析项目各个环节的变化过程以及效能短板:效能洞察 | Zadig 文档[11]


后续将推出更多分支策略以及团队协作流程相关实践专题文章,敬请期待...


GitHub: https://github.com/koderover/zadig,欢迎大家前来围观。

扫描以下二维码,添加 KodeRover / Zadig 小伙伴,备注 【姓名-公司-城市】,即可加入我们的「Zadig 开源吐槽群」



参考链接

[1] https://docs.koderover.com/zadig/env/loadbalance/

[2] https://docs.koderover.com/zadig/env/multi-env/#%E6%95%B0%E6%8D%AE%E5%BA%93%E9%9A%94%E7%A6%BB

[3] https://www.koderover.com/blog/casestudy-lark/

[4] https://www.koderover.com/tutorials/codelabs/Gerrit/index.html?index=..%2F..index#0

[5] https://docs.koderover.com/zadig/env/multi-env/

[6] https://docs.koderover.com/zadig/env/loadbalance/

[7] https://docs.koderover.com/zadig/project/workflow/#im-%E7%8A%B6%E6%80%81%E9%80%9A%E7%9F%A5

[8] https://docs.koderover.com/zadig/project/build/#zadig-%E5%85%B1%E4%BA%AB%E6%9E%84%E5%BB%BA

[9] https://docs.koderover.com/zadig/project/test/

[10] https://docs.koderover.com/zadig/stat/overview/

[11] https://docs.koderover.com/zadig/stat/insight/

 

更多最佳实践 点击阅读原文

+

浏览 68
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报