今天和大家分享的是某独角兽级别、ToB领域 SaaS 平台的分支管理模型。该企业的产品、研发人员规模约 200 人,总用户在 500w 左右。通过采用简化版的大规模敏捷交付流程,明确的分支定义和管理策略,确保了高效的产品迭代和技术交付。其分支定义包括主分支、预发布分支、测试分支、特性分支和热修分支,每个分支都有明确的生命周期和质量保障措施。交付流程涵盖了从需求优先级确认到正式发布的各个环节,充分利用自动化工具提升发布效率和质量。
分支定义
主分支
-
名称: master
-
功能: 生产就绪分支,用于线上部署、版本回退等
-
数量: 1
-
生命周期: 常驻
-
创建: 初始化时拉出
-
消亡: 不涉及
-
提交: 不允许
-
同步: 不涉及
-
标记: 版本号+日期
-
质量: 通过前导流程确保质量,通过流水线限定了分支保护规则,只允许指定的分支合入
预发布分支
-
名称: pre-prod
-
功能: 预发布分支,用于预发布验证
-
数量: 1
-
生命周期: 常驻
-
创建: master
-
消亡: 不涉及
-
提交: 不允许
-
同步: 不涉及
-
标记: 版本号+日期
-
质量: 无特别要求
测试分支
-
名称: test1, test2
-
功能: QA 测试分支,对应每周二、五两个上线窗口
-
数量: 2
-
生命周期: 常驻
-
创建: master
-
消亡: 不涉及
-
提交: 不允许
-
同步: 自 feature 分支合入,自 master 同步最新功能、bugfix
-
标记: 不涉及
-
质量: CR,联调通过
特性分支
-
名称: feature/xxx
-
功能: 新功能开发分支
-
数量: 多个
-
生命周期: 临时
-
创建: 对应窗口 test 分支拉出
-
消亡: 对应窗口的上线分支
-
提交: 允许
-
同步: 手动
-
标记: 关键字
-
质量: CR
热修分支
-
名称: hotfix
-
功能: 功能发布分支
-
数量: 多个
-
生命周期: 长期
-
创建: master
-
消亡: 合入 master 后删除
-
提交: 允许
-
同步: 手动
-
标记: 关键字
-
质量: CR、QA 测试、产品验收
工作流程
交付流程
如上图所示,该企业交付模式为简化版的大规模敏捷交付流程,简单描述如下:
-
产品迭代:
-
需求优先级确认会、迭代范围确认会每双周周三召开,各敏捷小组的PO和TO单独组织。
-
需求粒度:因为作为通用工具产品SaaS平台的特点,需求需要进行完整的PRD,并进行一定的可行性分析。同时因为产品发布相对频繁,需求在形成PRD时就要拆解成可单周完成交付的粒度。
-
-
技术迭代:
-
上线窗口:每周二、四两个上线窗口
-
迭代启动会:启动会前需要完成任务估点,同时规划需求对应的上线窗口
-
分支管理
如上图所示为该企业的分支管理流程,简要说明如下:
-
分支规划:根据提前规划需求上线窗口,拉出对应的feature分支,分支命名没有特殊规定
-
提测:
-
定时Cut特性分支并部署至开发环境,前后端通过联调确保功能正常后提测
-
需求提测前需要同步最新线上代码并解决所有冲突,否则QA会直接打回不予测试
-
被提测打回或测试不通过的需求,在下个窗口测试上线
-
QA维护两条常驻的测试分支,分别对应周二、周四两个上线窗口
-
-
预发布:
-
交付流水线定时cut pre-prod分支部署预发布环境
-
内部人员通过路由规则配置,默认使用预发布环境以充分验证新功能特性
-
-
线上部署:
-
部署:由于SaaS服务的特殊性,正式发布采用触发制,但自动化程度很高,手机上经审批即可通过阿里云平台能力进行灰度发布
-
发布:对于实验性功能,需要提前维护A/B Test规则以限定实验用户集
-
总结
该企业的分支管理具有非常典型的Gitlab Flow特点,即分支与环境绑定。此外,该企业还采取了某外企的定时CUT分支实践,实现了开发环境、测试环境、预发布环境和线上环境的定时、高度自动化的部署。
通过这种科学的分支管理和交付流程,才能实现了高频率、高质量的产品发布,有效地应对了复杂的需求和技术挑战。随着数字化转型的不断深入,采用这样先进的管理方法和工具,是企业提升自身竞争力的基础,因此我在和同事、友人的沟通中也常把分支管理和流水线建设成为企业研发效能体系的『下水道工程』。只有做好了下水道工程,才能提升团队的协作效率,由研发敏捷支撑业务敏捷,进而实现生态敏捷,企业也才能为客户提供更加稳定和高效的服务体验。
如果文章对您具有一定的借鉴意义,还请不吝点赞、转发,给威哥一点继续创作的鼓励和支持。