机顶盒固件和APK升级流程规范

机顶盒固件和APK升级流程规范
2014年2月28日
版本140228
一、目标
针对目前互联网电视平台升级、终端固件及APK发布升级过程，出现较多问题，急需形成良性有序的发布规范，否则各环节流转中容易发生相互等待、被动接应的局面。

无形中不断增加了沟通成本，扩大了软件的风险。

且对后期造成的影响无法预知和估量。

因此，根据前期已有的习惯，总结其他产品的发布经验，分析统计结果后，特制定本发布过程规范。

预期达到如下目的：
1、减少交叉沟通。

通过将发布过程流程化，使合作方都非常清楚自己的分工。

当遇到困难时，能明确的定位寻找到关键人物沟通解决。

避免当需要获取一件事情的进展情况时，需要广泛征询才能掌握的现象。

减少交叉沟通成本。

2、提高工作预见性。

各合作方执行人能迅速在早期预算出自己的“参与时间”、“参与内容”、“参与工作量”，主动提前做出安排、准备，避开人力、时间等资源上的冲突。

3、提高可控性。

二、发布流程规范
2.1 制定升级计划
需对本年度内的版本更新，制定发布计划，内容包括：发布时间，预定版本号、厂商签名时间和测试时间。

以下表为例；版本升级需提前7天通知，以免出
现短时间内既升级固件又升级APK的情况；如需对已经确定的升级计划，需提前3天进行通知，并写明推迟的时间和原因。

2.2 由需要升级的相关厂家（以下简称“发起方”）提供《更新功能列表》和《测试报告》。

2.3 由涉及到的其他平台、终端厂商（以下简称“涉及厂商”）共同测试，并提供《测试报告》；
测试环境建成后，运营组对以上厂家提交的《测试报告》、《更新功能列表》进行验证。

2.4 运营人员进行确认测试后，由运营组提交报告到数据部确认。

若系统内登记的所有bug都已经被修正，或者遗留的bug不影响系统的使用，则准许发布，如果有严重bug未解决（级别为必须修正）则不能发布，需按此流程重新发布；
2.5 编写发布说明
说明文件的内容应该包括产品版本说明；产品概要介绍；本次发布包含的文件包、文档说明、预定的升级时间；本次发布包含或者新增的功能特性说明；遗留问题及影响说明；版权声明以及其他需要说明的事项。

2.6 正式发布通知
通知开发、测试、运营、网管、客服、地市接口人等相关人员，并附上产品发布说明和产品介绍，通过微信，飞信等渠道告知用户。

由运营组人员牵头，发起方厂商参与，涉及厂商配合，对升级的内容做测试，模拟真实环境，测试升级是否正常。

（1）涉及平台硬件、软件等需要在服务器现场进行操作的，由运营组人员陪同发起方厂商到达现场，现场观察升级过程，涉及厂商可自行安排
测试地点测试；
（2）涉及终端固件、APK升级的，可以不在现场操作的，需在移动公司安排的办公室内升级，由运营组人员配合测试，涉及厂商可自行安排
测试地点测试。

2.7 发布后验证。

版本正式发布后，不得擅自修改，如果需要对后台内容、栏目的增加、修改、删除，临时的业务中断，需至少提前一天通知运营组，在必要的时候对网管中心、客服中心、地市接口人或终端用户发出通知；造成用户投诉的，一经发现当作系统故障处理；
三、应急更新流程
向外发布升级后，发现了由升级导致的错误。

且该错误给客户造成了很大的影响，等不及下一版本，需要立刻修正，需要发布应急升级更新。

各方需对应急版本中涉及的内容做特殊支持，以保证业务的正常使用。

3.1 针对出现的BUG，运营组提供统一的解释口径、现象说明、临时处理方式及正式解决方案给省网管中心、客服中心、地市接口人等知晓。

3.2 由出现错误的厂商紧急处理BUG，并提供《测试报告》。

3.3 由涉及到的其他平台、终端厂商共同测试，并且提交《测试报告》；测试环境建成后，运营组对芒果，华为提交的《测试报告》、《更新功能列表》进行验证。

测试环境未建成前，由芒果提供一个测试版本供运营组测试使用。

这个版本与正式发布版本必须一致。

3.4 运营人员进行确认测试后，由运营组提交报告到数据部确认。

若系统内登记的所有bug都已经被修正，或者遗留的bug不影响系统的使用，则准许发布，如果有严重bug未解决（级别为必须修正）则不能发布，需按此流程重新发布；
3.5 编写发布说明
说明文件的内容应该包括产品版本说明；产品概要介绍；本次发布包含的文件包、文档说明；本次发布包含或者新增的功能特性说明；遗留问题及影响说明；版权声明以及其他需要说明的事项。

3.6 正式发布通知
通知开发、测试、运营、网管、客服、地市接口人等相关人员，并附上产品发布说明和产品介绍，通过微信，飞信等渠道告知用户。

3.7 发布后验证
3.8 应急更新时间点，以下表为例：
四、相关资料
1、软件版本号的命名规则：
软件版本号由四部分组成，主版本号、子版本号、修订版本号、日期版本号加希腊字母版本号。

例如：1.2.3.140210_beta。

2、版本号升级原则：
主版本号：功能模块有较大的变动，比如：增加多个模块或者整体架构发生变化。

次版本号：和主版本相对而言，次版本号的升级对应的只是局部的变动。

当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。

此版本号由项目决定是否修改。

修订版本号：局部的变动，主要是局部函数的功能改进，或者bug的修正，或者功能的扩充，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。

日期版本号:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。

希腊字母版本号:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。

希腊字母alpha、beta、RC、release 分别代表内部测试版、公开测试版、最终修订版、最终发布版。