线上升级和回退策略

开发需要做的事情：

• 只有QA测试通过，镜像才能到release和online环境，明确release和online不属于开发这个基本原则。
• 当版本稳定后，所有代码改动，必须有相关bug，改bug时，超过一定量的代码改动，必须由leader确认才行。任何新功能，最多只能到QA环境。原则上新功能的开发和调试只能在Dev环境上。
• 能上release和online的代码分支，是锁住的，代码需要经过审批才能上传（按行审批）。
• release和online流转镜像时，数据是否需要清洗，格式是否需要改变，必须提前给出明确答案。如果需要额外的脚本，脚本完成和测试前，业务代码也不能提交。

运维与开发一起讨论的问题

• 是否需要停机更新（对于重大变化，特别是格式及兼容性无法保证的，需要提前讨论来定义）。
• 各更新服务间的依赖，开发需要同步给运维组，这样运维组可以看看是否能够进行渐进式更新。
• 开发可以提供一份代码变化列表，运维或相关人可以用来做参考

运维，开发与测试一起讨论的问题

• 测试要和开发一起讨论“升级接受测试”的case，这部分case要能自动运行，快速给出重要场景是否有问题的答案，用于运维升级后的快速测试。
• 测试需要在版本是否能到online环境上，给出最终的意见，有一票否决权。

运维需要做的事情

• A/B 升级，或Relase环境在测试时需导入线上环境的数据（或部分数据），数据包括redis, mysql, mongo, es, 图...，尽量避免升级时出问题。
• 数据（redis, mysql, mongo, es, 图）等等升级前进行备份。
• 快速测试，利用测试组的脚本进行快速测试。提前与开发及测试组定义接受策略，一旦不符合接受策略，立刻将服务及数据同时回滚。（最好控制在十分钟以内级别）
• 如果是非停机更新，需要监控用户访问情况，在访问量低时进行更新。或用ELB进行限流。
• 支持渐进式更新和部分回滚。

TODO 具体流程需要运维根据目前情况提供。