快速发版流程图

开发

灰度发布

验收Case

全量发布

 快速迭代好处:1.快速迭代可以及时根据用户的反馈调整产品的方向2.尽量避免在不必要的功能或方向上浪费时间3.快速的迭代可以快速响应公司的战略决策，赶超其他竞品公司    吐个槽：1.系统架构必须足够的强大和灵活，封装性和扩展性要很好，能够支持快速的功能开发2.开发人员要有意识去优化系统框架3.团队成员，必须很清晰的知道，自己工作的内容和时间节点4.对团队人员技能、统筹、应变能力要求较强5.项目管理人员，一直保持着紧绷的神经，时刻关注项目进度

并行

Y

N

API评审

UI验收

测试准备

发版计划

发开、冒烟测试：      快速迭代对于人力能力有一定要求，功能独立、提测质量1.当功能有影响其他时，务必有意识和测试同步2.提测时保证功能跑通、埋点工具自测通过

埋点评审

提测

通过合并预发布分支

进入需求池

开发自测

需求评审：      了解需求应用场景，需求解决的问题，需求的业务逻辑和技术实现。以下情况出现，需求评审不予通过：1.需求文档描述不清晰文档内容需完善细节调整2.文档内容混乱逻辑梳理不清很难看懂3.缺少流程图或原型图描述功能不清晰对需求提出QC建议，并且对需求文档质量进行确认

进入N+1迭代

需求评审

API评审：      确认时间节点：设计，开发，提测，测试，上线明确接口文档内容难点和风险及接口逻辑。以下情况出现，设计评审不予通过：1.缺少接口逻辑详细描述2.缺少请求参数样例及描述3.缺少返回参数样例及描述4.表结构及数据库逻辑描述不清楚QC要对接口文档设计文档质量进行确认

灰度监控

等待确认版本

后端上线正式环境

分支管理：开发功能：feat/xxx分支修复线上bug：hotfix/xxx分支线下集成开发环境测试：develop分支预发布环境：release/5.x.x分支线上后：master分支其中需要进入本次迭代快车的功能(feat)，必须经过develop集成测试后才能提交到release分支。且超过本次迭代不允许再向release分支提交      

系统测试（测试环境）

测试阶段： 按照测试计划于排期保证测试进度正常1.测试出bug后要基本定位bug及原因（区分前后端）2.提交bug时要保证描述清晰明了，能根据描述准确复现bug，并正确分配标清bug等级，状态3.回归后保证bug已完全修复才可关闭bug，及时推动bug解决超时未解决问题及时反馈

发版计划：用石墨表格做每天进度排期，尽量保证一段时间内只有一个关注点1.QA、技术负责人确定发版内容2.项目预警3.确定开发排期4.确定测试排期5.后端上线时间6.最终全量时间每个人同时最多只能工作在2个迭代版本上。工作切换越多，效率越低，出错可能性就越高。

快速发版流程图

等待确认版本：1.计划中全部需求都已完成测试线上包测试：1.每个QC一个线上包，验证主流程2.安装商店老版本，测试内部升级3.QA小组负责2次走查4.灰度后QA小组在群里同步灰度监控：1.灰度期间QA小组，关注SDK收集，将崩溃排行榜给与开发2.需要发版时，由QA发送申请邮件，注明版本号和修复内容全量发布：1.收到群内全量消息后，开始上传全量渠道包2.在群内发布标准格式，全量消息

测试准备：      QC要具有项目风险意识，预估排期尽量准确，出现延期时第一时间和技术经理、QA同步1.用例编写规范，按照模板统一维护2.对于开发提出的影响范围，重视覆盖3.Case和产品确认后，在执行

Case修改

冒烟修复

修复Bug

埋点评审：      各线BI明确说明重要埋点、一般埋点出发逻辑以下情况出现，设计评审不予通过：1.埋点缺少出发逻辑2.枚举说明不清3.字段数值缺少4.没有说明只在一端触发的埋点QC要对埋点文档设计文档质量进行确认

线上最终包测试（线上正式）

预发布环境回归

                                                                  关键时间节点1. 创建分支      创建版本分支，进行配置管理，随后进入开发阶段，进行功能开发和提交。如果使用敏捷方法，可以提交一个功能，测试一个功能，提高开发效率，所以过程中还会有bugfix的提交。2. 功能冻结（完成）      这个时间节点标志着所有功能的完成，后续应当进入全面测试和bugfix阶段。这时候如果有新的功能需求提出来，理论上应该放到后续迭代中，而不应该继续进行开发提交，否则会影响当前迭代的进入和这次发布的质量。3. Bug冻结      这个时间节点主要测试已经完成，质量已经达到了要求，原则上不应该在未经允许下提交任何改动。可能会有bug还没有修复，应当由项目负责人进行严格审查。      是否需要这些改动，任何\"nice to have\"的改动都应当被拒绝。只有严重影响功能的bug才可以提交，放入这次迭代中。需要引起重视的事：任何改动，包括bugfix，都会带来新的bug!4. 版本发布      这个时间节点意味着所有测试工作和bugfix已经结束，软件版本可以进行发布。      发布之后，在当前版本打上标签，可以进入到下一个迭代的开发之中。