软件版本控制

浅谈软件版本控制

为了规范各平台版本控制及提升整体平台交付质量，现做流程与版本控制，规定如下：

1、发布时间：根据需求排期选定每两周作为正式版本上线时间（封板之后，暂不发布新的功能在测试环境。）；

2、紧急发布：紧急发布时间根据实际情况而定，由产品、测试确认并发起紧急发布流程，频次由运维把控。

3、发布时涉及数据结构修改（不含新增），发布方法参考如下：

a、在线只读数据库和在线服务器中其中一台业务服务器脱线或分支，并变更为预发布资源；

b、上线正式环境前先提交预发布版本，由测试进行预发布版本测试，通过后由运维发布上线至正式环境，测试进行回归；

c、回归通过后，如出现小范围用户遭到异常影响，不做回滚；如出现主流程重大bug，做回滚；由运维、产品发起，召集研发、测试、运维、在线查找并修复异常；待正常后可走发布流程；

4、代码版本及回滚说明：

a、前端、后端、APP代码，研发负责提交代码版本号及发布内容，测试、运维负责记录；并预留现版本作为回滚的紧急处理；

b、发布过程中如代码遇到短时间不可修复的情况，运维发起与研发确认回滚操作，回滚操作确定后执行。

5、交付：运维操作完成后完成邮件通知，邮件内部通知，由产品发出邮件对外或告知外部团队，内容包含功能点及影响范围。

6、上测试环境时：

a、由开发打包提测代码或二维码交付测试，并邮件通知，

b、测试在测试环境发现重大bug，有权打回测试包，由开发修复后再进行提测环节；（提交时，修改的文件必须提交，以防出问题不方便回滚）

c、线上提测表修复，由开发告知修复的编号；开发根据2周一迭代或1周一迭代的要求进行量化评估；

d、遇到紧急需要修复的bug或需求可走紧急渠道进行提测；

附件：发布计划流程

发布计划流程

紧急问题处理流程：

紧急问题及需求流程