为了规范各平台版本控制及提升整体平台交付质量，现做流程与版本控制，规定如下：1、发布时间：根据需求排期选定每两周作为正式版本上线时间（封板之后，暂不发布新的功能在测试环境）；2、紧急发布：紧急发布时间根据实际情况而定，由产品、测试确认并发起紧急发布流程，频次由运维把控。
3、发布时涉及数据结构修改（不含新增），发布方法参考如下：a、在线只读数据库和在线服务器中其中一台业务服务器脱线或分支，并变更为预发布资源；b、上线正式环境前先提交预发布版本，由测试进行预发布版本测试，通过后由运维发布上线至正式环境，测试进行回归；
c、回归通过后，如出现小范围用户遭到异常影响，不做回滚；如出现主流程重大bug，做回滚；由运维、产品发起，召集研发、测试、运维、在线查找并修复异常；待正常后可走发布流程；4、代码版本及回滚说明：a、前端、后端、APP代码，研发负责提交代码版本号及发布内容，测试、运维负责记录；并预留现版本作为回滚的紧急处理；
b、发布过程中如代码遇到短时间不可修复的情况，运维发起与研发确认回滚操作，回滚操作确定后执行5、交付：运维操作完成后完成邮件通知，邮件内部通知，由产品发出邮件对外或告知外部团队，内容包含功能点及影响范围。
6、上测试环境时：a、由开发打包提测代码或二维码交付测试，并邮件通知，b、测试在测试环境发现重大bug，有权打回测试包，由开发修复后再进行提测环节；（提交时，修改的文件必须提交，以防出问题不方便回滚）c、线上提测表修复，由开发告知修复的编号；开发根据2周一迭代或1周一迭代的要求进行量化评估；
d、遇到紧急需要修复的bug或需求可走紧急渠道进行提测；附件：发布计划流程
发布计划流程紧急问题处理流程：
紧急问题及需求流程
亲爱的读者们，感谢您花时间阅读本文。如果您对本文有任何疑问或建议，请随时联系我。我非常乐意与您交流。
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。