发版流程及对外版本规范

这部分为三个方面：

一、版本编译、验证、发布

二、BUG追踪

三、不定期的版本发布

四、人员职责

一、版本编译、验证、发布

说明：
对外app的发布，只能通过jenkins自动编译平台进行release。
目的：
1. 保证对我统一出口，杜绝混乱发包现象
2. 确保出线问题后，版本可以迅速定位，帮助复现。
3. 减少研发人员参与运维工作，避免忙中出错，流出本不应存在的包
人员：
1. 测试相关人员 2.研发相关人员
流程：
1. app对应产品负责人，给出本次升级的提示文案。供产品升级时使用。
2. 研发人员必须在GIT上进行一条日志更新，明确版本发布的内容以及一条更新记录
3. 由相关人员更新发布最新版本
4. 测试工程师，对发布的版本进行全面测试。跑用例。跑全部可能执行到的流程。同时要进行不同版本的升级更新。并验证。
5. 经测试工程师确认后，对于需要release给用户的版本，研发人员使用得到的升级文案，同步更新到后端版本数据。将本次升级，发布到google play上。
6. 对本次升级，用文档记录并保存 在 app升级记录说明。
备注.每次的发版内部版本应先于公开release的版本。公开release的版本理论上应有至少半个月的缓冲。对每次公开的版本经过仿佛测试后，方可发出给用户。

二、BUG追踪

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. 产品更新升级信息：产品相关人员应 给出此次升级的升级提示文案