公司有30多个项目,源码都存放在自有git服务器上管理。公司没有统一的配置管理员对源码进行管理,都是由各个项目的干系人对代码的项目的各个分支进行管理。随着公司业务发展,每个项目的分支不断增加,有些项目甚至有10多个分支,而且大多分支都是由不同的开发人员创建的,分支多而杂,命名没有规范,常常发布一个新功能时,因为未合并其他分支的代码而出现功能不可用等问题,还有就是在需要开发新功能时,没有一个最新源码的分支进行代码拉取,很多时候都是在选择源分支时,心里没底。源码的权限管理缺失,存在因为不可控人为因素导致代码删除等现象发生的状态。
基于以上状况提出以下建议:
1、 标准化项目分支结构
2、 控制源码管理权限
3、 标准化开发、发布流程
4、 保证任何情况出现,都能快速恢复当前生产环境及回滚生产环境到前一个版本
1、 dev分支(不稳定分支,开发分支)
2、 master预生产分支(稳定分支,控制读写权限)
3、 release当前生产环境分支(稳定分支,控制读写权限,备份,线上紧急bug修复使用)
4、 release_bugfix当前生产环境紧急bug修复分支(稳定分支,控制读写权限)
5、 release_last_version当前生产环境前一个版本分支(稳定分支,控制读写权限,备份用)、
1、 从master拉取最新代码,创建功能分支dev_function_v.x.x
2、 在功能分支dev_function_v.x.x上完成功能开发
3、 从dev_function_v.x.x从功能分支上拉取代码,创建功能测试分支test_function_v.x.x(使用新的分支,以便可以基于dev_function_v.x.x分支开发新功能,该功能不同步发布)
4、 打包测试分支test_function_v.x.x,提交测试包
5、 部署测试包到测试环境
6、 测试人员测试,提交bug到禅道
7、 开发人员切换到test_function_v.x.x分支完成bug修改
8、 重复步骤(4)-(7),直到bug修复完毕
9、 将测试分支test_function_v.x.x代码合并到开发分支dev_function_v.x.x
1、 测试通过后,需要发布UAT环境或者预生产环境
2、 申请锁定master代码,避免其他功能分支同步合并分支到master,各个分支相互影响
3、 将master上的代码合并到测试分支test_function_v.x.x上,再将test_function_v.x.x代码合并到master上
4、 从master打包UAT或者预生产环境包
5、 发布至UAT环境或者预生产环境
6、 验证UAT环境或者预生产环境,若出现bug,则回到test_function_v.x.x进行bug修改,从(一)4-9及(二)3-6开始走下面的流程
7、 释放master合并权限给配置管理员
1、UAT及预生产环境验证通过后,从master上打生产环境包
2、发布最新代码至生产环境,若在发布生产环境过程中或者发布到生产环境功能或者服务出现问题,则使用release分支中的代码进行紧急回滚,恢复线上环境。
3、如果新功能,发布生产成功而且验证通过,则先备份release分支中的代码至release_last_version分支(该分支用于紧急恢复到上一版本),再合并master中代码至release分支中及release_bugfix分支中
发布生产出现的bug具有最高的优先级,不再走master分支,而是直接release_bugfix分支
1、 切换到release_bugfix分支
2、 合并release中的代码至release_bugfix(避免两个分支不一致)
3、 修复bug,提交代码至release_bugfix分支
4、 打包release_bugfix分支,部署至测试环境测试
5、 测试人员测试,测试不通过,则重复3-4,直到测试全部通过。
6、 测试通过,发布UAT或者预生产环境。如果生产环境bug修复完发布预生产环境过程中,已经存在功能在UAT环境或者预生产环境验证。则需回滚原有功能,待生产环境bug验证通过后,合并release_bugfix修复的代码后,再起发起预生产环境部署验证流程。
7、 重复(五)发布生产环境
1、删除test_function_v.x.x分支