发版流程说明书

发版组管理流程规范

1. 目的

1.1 提高工作效率

该文档的目的是，通过将发布过程流程化，使每个环节的执行者都能清楚自己的产入和产出，受谁的影响，将影响谁。当遇到问题时，能明确定位到负责人进行沟通解决，并且有效扩散，减少沟通成本，提高工作效率。

1.2 提高工作遇见性

发布流程一旦启动，项目中的所有人员便被触动。个环节执行负责人能迅速的早期做预算。预算内容包括：人员安排、进入时间、工作内容、和工作量评估。主动提前做出安排，避开人力，时间等资源上的冲突。

1.3 降低发布的风险，提高代码质量

2. 项目发版排期

2.1 人员安排

根据业务划分，目前分为三个项目组，联网体验组、产品组、运营支持组。初步规划每个发版组成员对接一个项目组。

2.2 排期规则

需要发版的项目一旦立项，需要产品经理通知发版组负责人，进行排期。排期时，各个项目根据紧急重要，紧急不重要，重要不紧急，不紧急不重要四个基本划分级别。资源起冲突时， 根据项目级别，安排人员、进入时间、工作内容、和工作量评估。

3 发布流程三个阶段：

3.1 发布模块确认

邮件确认要发布的模块list并分配相关PM, RD，QC人员进行发布后线上验证，落实到人头，发布后立即验证，有问题的及时反馈，便于快速发现和定位问题，有主功能阻碍的问题立即回滚。

3.2 Tester测试报告和bug清单

确认所有模块第一轮，第二轮全部测试完毕. 相关bug 是否全部提禅道。p1,p2级的

bug是否已经全部关闭。特殊情况可以带p3、p4bug上线, 并确定解决时间，需要产

品经理确认，有异议可以升级。

3.3发布步骤

系统架构中，有些系统接口互相调用，需要事先确定依赖关系，一般情况来说，被依赖的系统优先于依赖的系统发布。数据结构变更等。

3.4Sonar扫描结果

Sonar是一个用于代码质量管理的开源平台，用于管理Java源代码的质量。 Sonar

扫描结果blocker和critical的结果数量为0.（目前未达到）

3.5Code review历史记录

根据公司目前出具的代码规范，检查Code Review历史记录。

3.6自动化case执行结果

目前16WiFi发布的所有模块中，自动化系统尚未建立。建议把主功能和业务分级别列出自动化case， 从接口的方向或者界面实现自动化。每次相关模块的功能需要上线时，测试通过后，应该再把相关 的模块自动化case跑通过，为线上的业务的正常运行增加第二重保障。

3.2 项目具体发布步骤

3.2.1发布现场

项目中的DEV、PM、QC、运维负责人必须在现场或在线支持，缺一不可。

根据项目的大小，如果项目比较大，系统多，涉及面比较广，项目中参与的人员建议最好在现场，快 速响应并解决问题。涉及面比较小的发布，项目排期人（负责人）在现场就可执行发布。

3.3.2 发布步骤

出现问题要按照订制的发布步骤进行回滚，要使用最快方式进行回滚，回滚后要在

beta环境中重新 测试，定位问题出在哪个工程。