背景
随着技术团队的发展壮大，沟通壁垒越来越高，整个协作过程中存在较多的流程痛点；同时为了践行DevOps理念，我们前端研发团队也进行了流程提效实践，本次主要分享我们对分支管理的规范的了解，旨在为大家提供更加高效和灵活的研发环境。
现状与痛点
历史：
- 向ops团队申请创建Feature分支。
- 向ops团队申请上线，合并代码分支等等，ops团队负责发布，对服务运行状况并不清楚。
研发的声音：
“运维忙起来发版得排队等半天，影响我们上线”
“周末/半夜紧急上线需要把运维同学叫起来，联系不上/不及时的话还会影响业务”
"master分支合并对研发来说黑盒，不确定上线完成后什么时候会合并到master"
....
运维的声音：
“就是个客服机器人，干的都是体力活”
"配置改成这样是什么意义并不清楚"
"累啊...."
....
带来的问题：
-
版本发布风险的增加
线上发版依赖于运维团队执行上线计划，可能会出现忙时发版排队、配置错配或漏配的情况，这会增加发布出现问题的风险，同时也会影响产品上线的速度和质量。
-
故障排查时责任不明
当出现线上故障时，研发团队和运维团队可能会出现责任不明、沟通不畅的情况。这会导致故障排查时间过长，影响产品的可用性和用户体验。
-
运维效能无法提升
重复性工作将会占据运维绝大部分时间，无法专注在运维效能的提升上。
目标
践行Devops理念， 研发运维一体化
一体化意思是将系统开发和IT运维两个过程结合起来，使得研发团队可以自己负责部署、维护和监控自己开发的应用程序。
这种模式的好处是可以加快需求的交付速度、提高运维效率和减少沟通成本。
运维能更加专注在运维效能的提升上，将成果正向反馈给研发团队。
研发TEAM对交付质量负责
一个研发Team/Squad会包含产品、测试、前后端研发等主要角色，作为软件交付的责任单元，作为一个整体，需要对交付的软件产品的质量负责。
运维专注于运维效能提升
- 自动化运维工具和流程
- 监控体系的优化
- 容器化技术
详细内容
整体流程变动点，“单点->并发”的转变。
| Before | After | |
|---|---|---|
| 分支管理 | 由运维分配分支，运维合并分支，有问题再找研发 | 权限下沉，业务线Team闭环管理，根据团队成熟度、业务复杂度选择合适的分支管理模型。 |
| 上线发版 | 收到上线申请，运维全托管，上线完成后业务线Team走验收流程 | 业务线Team闭环管理，发版权限放权给各Team Leader。 |
环境管理
-
DEV
- 开发环境，支撑与跨团队服务联调
-
TEST-X
- 测试环境，多版本测试使用，版本相对稳定。(研发别动、研发别动、研发别动)
-
PREPROD
- 回归环境、验收环境(研发别动、研发别动、研发别动)
-
PROD
- 生产环境，面向实际用户
分支管理
分支管理由过去的运维全托管的方式变成松散自由的管理方式，目前不再做强制性约束，以研发团队为主要决策单元，将分支管理的事务下沉到研发单元内部决策，运维人员不再参与分支管理事宜，能更好的将重心放在运维效能的提升上。
常用分支管理模型
- TBD(Trunk-Based-Development)
- Git-Flow
- Github-Flow
- Gitlab-Flow
- Aone-Flow
- ...
“分支管理没有银弹”
“适合团队的，才是最好的。”
Git Flow
-
master分支
- 只存放历史发布(release)版本的源代码。各个版本通过tag来标记。
-
develop分支
- 用来整合各个feature分支。开发中的版本的源代码存放在这里。
-
Feature分支
- feature分支派生自develop分支，当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。
-
Release分支
- release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。我们用这个分支干所有和发布有关的事情，比如：提测、修复bug等
-
Hotfix分支
- hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如v0.1.1。
- 同时hotfix也要合并回develop分支。
团队Flow
团队过去的分支管理模型即是类似Aone-Flow的分支管理模型。基本兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。
三种类型：
- 主干 Master
- 功能/特性 Feature
- 发布 Release
创建Feature/Hotfix分支
合并Feature分支，形成发布分支
上线成功后，将发布分支合并回主干
注意的点：
- 上线成功后一定要将发布内容合并回主干，保持主干拥有最新运行版本的分支。
- 预发或者其他环境验收前，需要将主干合并回功能feature分支，将代码冲突等处理前置。
