目前需要解决的问题:
- 一个版本中的多个功能都开发完成后,需要集成测试。
- 在开发过程中,多个
功能分支
后台开发完成后,需要给前端提供接口
并开发,需要将几个后台功能分支
同时部署到开发环境(服务器有限),并且这几个功能有可能还不同时上线
。 - 多个固定计划的版本在同时开工的情况下,多个计划版本都测试完成后,单只有部分上线,其他的待命。
- 在稳定迭代开发的同时有
紧急bug
修复或有紧急需求
要开发并上线。 - 在某个功能上线(master分支)完成后发现有未测试到的点,急需回滚。
解决办法:
- 每个版本基于 develop 分支创建新分支(如:M9W2),作为该版本的
功能主干分支
,该版本的各个功能分支
都完成后,在合并回功能主干分支
,然后基于该功能主干分支
迭代修改,直到测试通过。 - 利用临时分支 dev-merge 合并开发中的多个feature分支,然后部署到开发环境。
- 每个
功能主干分支
测试完成后,先不提交到develop,在需要上线的时候
再pull develop分支,如果与其他版本有代码合并,则再进行一次回归测试,没问题了在 push 到 develop,并打tag,然后提交到master上线。 - 使用hotfix或feature规范的分支,这种分支有的会merge到master,有的feature是该阶段一次性使用,所以不必merge回master,而是直接部署该分支即可。
- 如果上线平台有备份每次的上线的包(如:war/jar/docker image),可以直接恢复该包进行回滚操作;也可以在merge master前将master打个备份tag或分支,如
master/1012
,直接部署该分支即可。
分支划分
- master : 主分支,一般都是从该分支部署到线上
- hotfix/* : 修复线上bug分支
- develop : 开发主干分支
- release/* : 发布版本分支
- MxWy:周迭代版本,如M1W2(1月第2周),固定频率迭代使用
- feature/* : 功能分支,使用在非固定频率迭代开发或固定频率迭代的子任务
- dev-merge/* : (临时分支)开发合并
- dev-qa-merge : (临时分支)开发部分功能测试
- dev : (临时分支)部署分支,部署到开发环境
- test : (临时分支)部署分支,部署到测环境
原理图
最左侧的dev(34)和test(35) 是指部署到某个开发环境34和测试环境35