blyang 你长的很好看啊~
分支管理和上线发布流程
发表于: | 分类: 默认分类 | 评论:0 | 阅读: 387

当代码仓库的项目逐渐增多,协同开发的人数增多,机器数量增多的时候,一个良好的分支管理规范,大家共同来遵守,就变得越来越重要了。避免开发过程中分支混乱不清,上线冲突不断的问题。


  • 分支命名:
    • feature/pp-XXX:功能开发分支,feature + '/' + 姓名简称 + '-' + 功能说明
    • bugfix/pp-XXX: 异常修复分支,bugfix + '/' + 姓名简称 + '-' + 故障简称
    • hotbugfix/pp-XXX: 紧急故障修复分支,hotbugfix + '/' + 姓名简称 + '-' + 紧急故障简称
    • develop: 开发分支
    • release-181122: 测试分支,测试完成之后合并到主分支,实施上线,releast + '-' + 上线日期
    • master: 主分支,生产线


  • 分支管理流程:

    分支管理的流程图入上图示例。

    • 新的feature,bugfix和release,默认从master新建分支
    • develop分支用于RD和FE研发使用,所有feature和bugfix分支的开发,都需要到develop分支自测。
    • develop分支隔一段时间之后,比较脏的时候清理掉,重新从master拉一份
    • 自测结束之后,上线提测时,将feature或者bugfix合并到release分支,提交merge request,并指向合作的开发同事做code review
    • 将测试环境的代码切换到release分支,开始上线前测试。release分支禁止随意切换,需等待测试同事反馈
    • release分支由QA管理,测试结束之后,更换profile,提交merge request到master,由项目负责人审核代码并完成合并。合并前,需要查验测试报告(含功能点和用例)、产品验收通知,部分大的改动需要提交上线内容说明(上线时序流程,代码版本,配置,缓存刷新,数据库建表,测试验收功能点,异常回滚方案等)
    • master发布由OP来负责,上线通知由研发负责人发出(邮件/钉钉/微信)
    • 上线之后做基础功能回归,RD,QA和PM同事参与,回归结束之后由PM出验收报告
    • 上线测试验收完成之后,删除相应release、feature、bugfix分支,保持分支的整洁性


  • 备注
    • 生产环境除OP和研发负责人外,禁止 git pull 权限
    • 提交merge request到release分支之前,必须要有code review环节。代码量过多时,需要结对做代码讲解和审核
    • 上线前必须有测试报告和产品验收通知,OP拿到这两份文件通知之后才会操作上线
    • release分支由测试同事负责,在测试机上,没有测试完成前,禁止切换分支。若发现当前分支在release,切换前需要和QA同事沟通
    • 仅部分hotbugfix问题,可以直接合并到release分支开始测试,不经过develop分支自测
    • 测试完成,提交merge request时,需要在备注中填写版本发布的功能点,以及上线部署流程

评论已关闭

TOP