@Tyhj
2019-05-31T11:33:24.000000Z
字数 1210
阅读 1138
工作
说明:
对外app的发布,只能通过jenkins自动编译平台进行release。
目的:
1. 保证对我统一出口,杜绝混乱发包现象
2. 确保出线问题后,版本可以迅速定位,帮助复现。
3. 减少研发人员参与运维工作,避免忙中出错,流出本不应存在的包
人员:
1. 测试相关人员 2.研发相关人员
流程:
1. app对应产品负责人,给出本次升级的提示文案。供产品升级时使用。
2. 研发人员必须在GIT上进行一条日志更新,明确版本发布的内容以及一条更新记录
3. 由相关人员更新发布最新版本
4. 测试工程师,对发布的版本进行全面测试。跑用例。跑全部可能执行到的流程。同时要进行不同版本的升级更新。并验证。
5. 经测试工程师确认后,对于需要release给用户的版本,研发人员使用得到的升级文案,同步更新到后端版本数据。将本次升级,发布到google play上。
6. 对本次升级,用文档记录并保存 在 app升级记录说明。
备注.每次的发版内部版本应先于公开release的版本。公开release的版本理论上应有至少半个月的缓冲。对每次公开的版本经过仿佛测试后,方可发出给用户。
Java层,C层,内存泄露。
针对这三种类型的BUG,采用如下的3种对应方法。
1 ) JAVA层,采用腾讯公开bug管理工具(支持国外):bugly
2 ) C层,采用腾讯公开bug管理工具(支持国外):bugly
3 ) 内存泄漏,采用leakcanary进行二次开发后,对接禅道的bug管理系统,可自动将bug提交到禅道。(这需要额外制定开发计划)
BUG日志查看。
时间:每日上午10点,查看日志。
人员:测试相关工程师,将新产生的异常 手动 提交到禅道上。并附 Bugly的相关错误id。该类禅道BUG 与Bugly上对应bug的生命周期保持一致,即禅道上的bug关闭,则bugly相关的bug也应关闭
备注. 针对内存泄漏,无需关心,需要对重复的异常进行bug的过滤,剔除重复bug。
三、不定期的版本发布
说明:
为应对突发情况进行的临时版本更新,为应对突发状况而产生
特点:
急,问题重,必须及时修复
规则如下:
1. 每周四定为 固定的版本发布日;如遇突发严重bug,版本发布为即时更新。(不严重bug,不在此范围内)
2. 理论上说,内部版本必先于公开release版本几次迭代。经过充分测试后,才能上线。这才能充分确保业务流程的顺利开展。
3. 公司可能会有多种 渠道包。(这只做超前技术考虑,具体要看业务发展而定)
四、人员职责
1. 版本编译:研发相关人员、运维相关人员,测试相关人员(原则上,不应有测试介入)
2. 版本测试工作:测试相关人员
3. 版本发布:研发相关人员、运维相关人员,测试相关人员(原则上,不应有测试介入)
4. 产品更新升级信息:产品相关人员应 给出此次升级的升级提示文案