江苏龙网

  1. 首页 > 人文 > >

技术编程字节研发设施下的 Git 工作流( 三 )


技术编程字节研发设施下的 Git 工作流
本文插图
周期发版：双主干
? 周期发版：三主干
技术编程字节研发设施下的 Git 工作流
本文插图
周期发版：三主干
对比“双主干”和“单主干” ，
有联系：
处于 MR 状态的迭代分支 ≈≈ 研发主干 Dev
单主干 Master ≈≈ 发布主干 Master
也有区别：
单主干的“研发分支”不存在一个固定的测试环境（相较于双主干 dev 分支）
多个 feature 同时发测试环境时需要组合成新分支 ， 管理不便
单主干迭代分支在 MR /非 MR 状态下的 CI 流水线有差异单主干实践前端微服务管理平台
字节前端微服务平台属于成熟业务 ， 只需做少量 feature/fix 开发 ， 在工作流上采用单主干模式 。
技术编程字节研发设施下的 Git 工作流
本文插图
本地测试后 ， 不再经过功能测试环境测试 。 发起 Merge Request ， CR 通过合码后 ， 上测试基准环境进行测试 ， 如发现问题 ， 回滚 ， 进入下一轮 CR 。
虽然小修小改影响风险小 ， 但流程缺乏进入功能测试环境的流程 ， 还是存在隐患 ， 有可能影响测试环境的业务方使用 ， 不是很好的实践 。
【技术编程字节研发设施下的 Git 工作流】单主干只适应于业务规模小 ， 成熟度高无大改动的项目 。 但无论业务规模如何 ， 执行上线发布流程前 ， 都必须先经过线下环境验证 。 双主干实践私有云平台
云平台的 Git 工作流是由繁入简的过程 。 最开始为每个部署环境设定了一个部署分支 。 feature 分支的 commit 点需要和三个环境的部署分支发生 merge ， 起不到串联测试的目的 。
技术编程字节研发设施下的 Git 工作流
本文插图
经过改进后 ， 采用标准的 Trunk-based Flow ， 仍能满足 online/sandbox/boe 三个环境的部署要求 。
技术编程字节研发设施下的 Git 工作流
本文插图
云平台参与业务方有上百个（类似阿里云平台） ， 虽然图中仅展示了三个环境 ， 但实际上 5 大环境的使用都融入了日常开发中 。 某业务中台
某业务中台的 Git 工作流重点阐述了同一个项目多人协作开发时会遇到的问题：
多个 feature 各自独立提测, 临近上线合码时有较多冲突, 可能导致线上 bug
提测前和提测中, 如果 master 更新了, 可能没有及时同步下来, 上线前合入 master 可能会导致冲突或 bug
在流程设计上 ， master 作为发布分支 ， release-* 为提测分支 ， 结合了单主干的便捷（hotfix 直接和 master 交互）和双主干对 feature 的管理
和 Trunk-based Flow 刚好相反 ， 主分支是发布分支 ， 提测分支是短期的
另一个比较有特点的是 ， 在 release 测试过程中 ， 发现某个 feature 的 bug ，直接从 release 分支 checkout 出来进行修复 ， 并再次合入 release
技术编程字节研发设施下的 Git 工作流
本文插图
Jupiter 工作流规范
Jupiter 是字节 Web 开发引擎 ， 覆盖 Web、组件库、BFF、SSR 等前端开发领域 。 Jupiter 推荐 Trunk-based Flow 类似的 Flow ， 并从 CI/CD 角度出发 ， 在开发新需求、hotfix 等时机给出 Git 操作建议 。
有重叠人员参与的各项目之间有一致的流程和模式 ， 避免增加认知负担 ， 避免同一个人在不同项目之间切换时混淆和迷惑 ， 也能集中力量做实践和改进 ， 共享经验和基础建设 。


推荐阅读


上一篇：|6毫米的小息肉，3年发展成肠癌？

下一篇：|教育｜儿童在成长过程中，接触大自然有什么作用？