背景
确立客户端发布流程中的准入与准出标准，以及紧急发布流程，旨在让参与客户端研发及相关团队成员清晰理解代码合并的标准与灰度发布的规范。此举旨在强化研发过程中的质量意识，促进团队协作，共同提升版本发布的质量与效率。
具体包含以下几个方面，如下：
需求集成标准
需求准入项 | 标准 | 说明 |
|---|---|---|
Bug 修复标准 | 新需求 P3 及以上 Bug 闭环率达到 100%; | 所有准入项达到标准，才满足上车条件； |
代码 Review | 符合项目标准，无重大缺陷，易于维护和理解，满足功能需求; | |
通过合码检查 | 包括但不限于工程文件检查、静态代码检查、预编译; | |
需求服务端对应新接口已上线 | 新需求涉及到的后端需完成 ，且在灰度前上线; | |
P0 需求有开关及功能可用性 | 为防止后续验收不通过或线上可能出现问题需要回滚，建议 P0 级重点需求增加开关可快速关闭止损;P0 级重点需求需要有功能可用线上监控; |
- 为防止后续验收不通过或线上可能出现问题需要回滚，建议 P0 级重点需求增加开关可快速关闭止损;
- P0 级重点需求需要有功能可用线上监控;
集成回归和代码合入规范
集成回归规范
- 当前版本新需求影响核心功能，需加入当周回归 Case；
- 回归 Case 需要覆盖业务核心功能和核心埋点，并经过业务组内 PM、RD评审；
- 无论当前版本是否有新增功能合入，都需要进行回归；
- 回归完成需要有对应任务；
- 集成阶段 Bug 验收；
代码合入规范
子项 | 标准 | 描述 |
|---|---|---|
集成阶段发现的 Bug | 可合入 | 正常流程：需经自测、代码 Review、QA 验收; |
核心埋点 Bug | 可合入 | 正常流程：需经自测、代码 Review、QA 验收; |
历史遗留 Bug | 可合入 | 正常流程：需经自测、代码 Review、QA 验收; |
大体积 Bug修复MR | 可合入 | 负责人 REVIEW 流程：需经自测、研发负责人 Review 、QA 验收; |
需求代码 | 不可合入 | 如有特殊情况，请走 紧急上车流程; |
灰度规范
准入项 | 标准 | 是否可合入 |
|---|---|---|
灰度新增线上反馈功能问题 | 原则：业务组内评估影响。建议：全部修复。如不能，需有结论。 | 在研发业务线负责人 Review 通过后，方可合入; |
灰度新增稳定性问题 | TOP Crash 全部修复 或 有结论。 | |
回归 & 内部反馈问题 | 只允许修复 P0、P1、P2 问题。 | |
其他 Bug | 以上三类之外的 Bug。 | 不可合入; |
需求类 | 严禁需求在封板后合入，特殊需求请走临时需求流程; |
版本准出规范
准出项 | 准出标准 | Block 发版原因 |
|---|---|---|
稳定性指标 | 灰度新增 TOP 问题闭环 & 有结论。 | 任意一项不满足，均 BLOCK 发版。 |
灰度品质指标准出标准 | P0 & P1 功能问题全部修复；核心功能可用性指标符合预期； | |
灰度核心埋点趋势符合预期 & 监控无异常 | 业务核心指标趋势正常，或监控无异常。 | |
无严重 Bug 遗留 | 灰度期间无严重用户反馈问题遗留，且灰度用户反馈跟进度高于 xx%; |
- P0 & P1 功能问题全部修复；
- 核心功能可用性指标符合预期；
灰度核心埋点趋势符合预期 & 监控无异常业务核心指标趋势正常，或监控无异常。无严重 Bug 遗留灰度期间无严重用户反馈问题遗留，且灰度用户反馈跟进度高于 xx%;
收益
过程收益：
- 提升了 RD & PM 对于准出标准、准入标准的关注度；
- 提升了 QA 对于准出标准和准入标准的把控能力；
结果收益：
- 从 x.10.0到x.18.0 之后的版本维持在 100% 闭环率，整体闭环率显著提升。
- 线上用户反馈从数量从xx降低xx；
- Q3线上故障故障降低xx%；
