业务需求评审
- 需求预串：了解这一期产品需求，判断是否合理，方案实现代价，带来的业务价值
- 上下游依赖确认：梳理上下游调用链路，涉及的影响面和改动范围，上下游相关人员介入
- 需求正式串：本期需求正式拉通，深入理解需求内容与意义
- 需求确认与评审：明确项目标和收益，判断需求合理型，明确项目迭代周期，包括概要方案的设计讨论
- 开始技术方案评审：需求确认完成进入技术方案评审阶段
技术方案设计
- 开发方案：概要设计与详细设计，包括设计文档/说明/简图
- 测试方案：包含准入case设计，功能测试方案，服务测试方案等
- 监控预案设计：监控&报警设计，回滚预案设计等
技术方案评审
- 方案详细设计：需求评审之后技术团队要做详细设计，明确相关困难点与解决方案思路，内部review通过
- 确认开发排期：预估工作量，人力投入，确定开发、提测、联调、上线等时间点
- 开始开发：技术方案确认完成进入开发
开发
- GIT分支开发：从主干创建新的开发feature分支
- UT（Unit Test）：开发过程要求必编写UT，且要求新feature代码覆盖率超过30%，覆盖核心功能
- 自测：开发完成后，完成自测功能，预期功能效果、性能稳定性、diff影响面心里要有数
- CR（Code Review）：确认代码实现合理性，准确判断代码异常情况，至少2名同学CR，工程owner必须参与CR
- 联调：上下游服务联合调试，预期功能效果验证，全链路问题追查
- 开始提测：rebase主干分支代码进入提测阶段
资源版本管理 - 资源版本管理
- 代码、配置及脚本全部入git，配置过大的话走数据资源发布方案
- 数据资源：
- 配置/小词典（<10M），可以作为代码一部分入git管理。
- 本地配置（开关等）/词典/模型：建议进词典平台管理，统一管理
- 在线服务大词典接入数据平台管理统一管理
- 引擎词典进辅表
CodeReview
- CR标准：可读性、合理性、正确性、稳定性、高性能、安全性
- 代码风格：Google C++ Style，https://google.github.io/styleguide/cppguide.html
- 实现逻辑：正确高效
- 异常判断：泄漏、空指针判断、doube free、锁的使用、边界检查，如果需要可以利用扁鹊等工具来辅助
- 性能是否是高效的方案：放在压测部分评估
- 有没有安全问题（异常query/core query/注入）
- CR条件：
- 至少2名同学CR（有经验且通过模块串讲）
- CR 必须全部通过
- 工程服务Owner必须参与CR
测试
- 测试准入：提测后QA根据这期需求和开发功能点开发测试用例，开发提测走case准入与基线回归
- 功能测试：根据测试Case进行功能验证，交付自动化脚本，并进行老功能回归测试（含资损及P1&P2级别Case）
- diff测试：对关键list接口进行diff测试，需要研发确认diff结果
- 性能测试：压测时间20分钟以上进行测试版本及基线版本性能对比，性能降低超过5%需要记账或者打回
- 联调测试：上下游测试同学需要在日常、预发、灰度、线上进行全链路Case的走查验证
- 测试结论：提测后发现的BUG都需要重走开发流程重新提测；测试完成后测试产出测试报告，产品走查验证效果
- 开始上线：merge主干进入上线阶段
上线
- 上线准备：上线前需要确定发布方案、预期影响、回滚方案，提前加好报警与监控，
- 发布评审：发邮件走上线审批，带上测试报告与产品走查结论；重大项目上线必要时需要拉会讨论明确细节
- 预发上线：预发流程上线，冒烟与功能check，观测至少一天效果
- 灰度上线：预发验证无问题，灰度发布线上环境，冒烟与功能check，观测至少一天效果，灰度需要有等待时间>20分钟，进行流量验证
- 生产上线：灰度验证无问题，生产分机房分批次发布上线，分批过程必须有冒烟和功能check
- 生产check：生产发布后，需要分批冒烟和功能验证，上线完成后需要观测服务日志与指标监控一段时间，确认上下有服务正常
- 开始业务迭代终止流程：生产check无误后进入最终流程
业务需求结束
- 功能验证：产品+研发+测试验证线上效果与服务状态，验证异常需要判断是否立刻回滚或者走紧急修复，紧急修复需要重走开发流程重新上线；验证无异常，本次迭代周期结束，进入下一次产品需求迭代
日常开发迭代
- 严禁除服务owner外的同学使用线上admin权限操作线上服务机器，如果需要操作需要审批且跟服务owner确认操作方案，一起操作；
- 严禁使用类似pgm的集群命令操作线上集群，稳定性性相关同学紧急处理线上问题除外；
