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

  • 格式:doc
  • 大小:150.50 KB
  • 文档页数:7

下载文档原格式

  / 7
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

机顶盒固件和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 分别代表内部测试版、公开测试版、最终修订版、最终发布版。