在前面介绍完框架以及自动构建等内容后,再讲版本就轻松很多了,相关的内容前面都断断续续涉及到了。这篇文章和组件化的关系不大,主要是讲应用的版本,包括版本怎么定义,有哪些标识,以及这些标识怎么生成,用于什么场景,解决什么问题。以及版本发布方法,遇到问题怎么回溯。
这部分内容在自动构建里面其实有一些介绍,也阔以参考几年前总结SDK的时候写的一篇关于版本的文章:SDK设计心得之版本
需要几个版本
之前规划了三个版本,结果现在因为有各种便利的调试入口,所以基本上只有两个版本:
内测版:内测版提供各种调试入口,开启日志,可以自由切换到各种环境。主要用于内部体验和测试,
正式版:对外发布版本,不支持调试,不开日志。用于正式发布
版本名和版本号
版本基本上都是两个字段,版本号和版本名。版本名一般用于产品的版本定义,版本号用于版本升级等逻辑。很多项目的版本号都是通过版本名的String按照指定规则转化,因此需要手动维护。
在组件化框架中,因为是自己从头搭建,因此我直接改为了使用应用代码的提交次数作为版本号,版本名可以自定义。
由于组件化框架同时支持多个应用,那多个应用的版本怎么管理?其实只要明确了版本号和版本名的定位,无论是多少个应用,都不存在这个问题。
当所有的开发逻辑都使用版本号,然后版本号自增,就不会有任何问题。例如PubA 和 PubB 同时发布版本,我们可能会先构建 PubA的版本,此时版本号可能是 2001, 版本名是 2.0.1;构建 PubB 时,版本号为2002,版本名为 1.0.1;版本名可能会有差异,但是版本号本质上还是自增的。也有人会追求版本号每发一个版本增加1,那不在这个讨论范围,而且也有别的方式可以做到,因为没有实际意义,所以不做讨论。
版本TAG
除了版本名和版本号,我们还设计了一个版本标示TAG,这个TAG主要用于标示版本与代码的关系。
在持续集成时他分别以源码硬编码、配置文件打入版本包。同时正式发版本时对代码创建同名的TAG。
版本号和版本名主要用于区分版本,包括产品发布、不同版本兼容等。
版本TAG主要用于遇到问题时,问题回溯。当提供某个版本的TAG后,我们就可以复原该版本对应的源码,更快的定位问题。
版本发布主要包括两部分:
怎么发布
对于发布遵循原则:灰度发布、可止血回退、可定向发布
用户怎么更新
对于提醒用户更新,我们提供强更、弹框两种模式
在版本通过持续集成构建成功以后,就进入了发布流程。我们对版本发布制定了对应的灰度流程,不同的应用发布标准不同,因此不列出我们具体的标准。
新版本发布灰度机制
灰度 | 灰度范围 | 前提 |
---|---|---|
小范围灰度 | 内测用户群 | 自测OK,可发布 |
大范围灰度 | 定向用户群 | 小范围灰度达标,或者超时未达标 |
官网灰度 | 官网包更新 | 大范围灰度达标 |
渠道灰度 | 所有渠道包更新 | 官网灰度达标 |
全量红点 | 所有用户 | 渠道灰度达标 |
版本异常止血回退处理流程
对于用户侧怎么更新,都集中在AAF的更新模块介绍,相关内容可以点击链接查看:
这里仅简单展示下不同更新策略下弹框逻辑
版本回溯主要用于问题定位。这里涉及到两个内容:
怎么准确知道出现问题的版本
怎么根据版本知道出现问题的代码
这个其实很简单,我们前面已经在代码和APK中通过自动构架加入了版本的信息。因此:
如果拿到的是版本的安装包,我们解压安装包,就可以拿到app.ini文件,里面记录了版本相关的信息
如果是已经安装版本的用户反馈,我们提供了一个调试入口,用户点击即可把版本信息提供给我们
下面是一个我们拿到的版本信息的事例:
用户信息:
openID: F83E0E59C7080121D00F3EA3E44CECFB
设备信息:
deviceKey: 1204534990
厂商&型号: smartisan, OS105
系统版本: 7.1.1, 25
版本信息:
version: 3.2.0.4286
Tag: Tag_MNA_3.2.0_4286
official: false
里面提供的版本信息就包含前面提到的版本TAG,根据TAG就可以获取对应的版本代码