不自重者,取辱。不自长者,取祸。不自满者,受益。不自足者,博闻。
Android开发到发布各阶段的版本控制 进入全屏
line

1、Daily Build版本:在每天RD提交代码后,次日早上获取,并携带4位小版本,如:5.4.0.1

2、灰度版本:即小流量发布的版本,对于大用户规模的产品来说,是有必要先发布一个小流量版本给特定批次的用户,以此收集用户反馈、crash率等;灰度期间的版本与上一个正式发布版本的版本号相同(AndroidManifest中,如:5.3.2),目的是防止被各种手机助手抓包并分发,用户规模被恶意扩大;但在客户端About页显示为新版本,如:5.4.0

3、正式版本:即全流量发布的版本,客户端中的所有版本号都将比上一个正式版本大,如:5.4.1


在AndroidManifest.xml中控制各阶段的版本:

<!--版本类型:1:daily build;2:灰度版本;3:正式版本-->
<meta-data android:name="versionType" android:value="2"></meta-data>
 
<!--灰度期间的版本号,在这里控制-->
<meta-data android:name="grayVersion" android:value="5.3.0"></meta-data>
 
<!--小版本,daily build用,在这里控制-->
<meta-data android:name="subVersion" android:value="1"></meta-data>

1、RD正常开发过程中,versionType的value会保持为1,QA的集成打包环境会自动修改subVersion字段(内部四位版本用,和现在的策略保持不变)

2、灰度期间,QA会将versionType的value修改为2,同时修改grayVersion的value,客户端会自动将此字段读出来,作为client_version,带到server端;同时也显示到客户端的About页面;此灰度期间,QA需保证Manifest节点的versionCode和versionName和上一个已发布的版本一致

3、正式发布时候,QA会将versionType的value修改为3,此时,grayVersion和subVersion都会被忽略,客户端会读取Manifest节点的versionCode和versionName(和现在的策略也保持一样)

趣店(原趣分期)技术学院
重点关注技术架构、服务化、优秀工具、自动化平台、开发全流程一体化解决方案、新人培养、工程师进阶之道等方面
这里环境优雅、氛围年轻、主要是福利还多,还等什么?我们敞开技术的大门,欢迎各种工程师加入!

评论区域

line