版本发布流程

一、版本发布流程

1、增加/变更功能流程

（1）需求确认

涉及人员范围： 产品经理、原型设计师（需要的话）、研发工程师（服务端、终端、硬件、结构）、测试工程师。
动作：

• 产品经理召集所有涉及人员进行需求宣讲，完成最终功能需求确认，同时确认release版本号。
• 原型设计师根据最终需求设计原型图（需要的话）。
• 产品经理确认原型图（需要的话）。
• 产品经理组织研发、测试进行沟通协调周期预估、评估影响范围以及提取风险点。

输出： 最终功能需求文档（尽量具体，最好有业务流程图之类的）、原型图（需要的话）、研发和测试周期预估表、风险点报告、release版本号。

（2）产品开发

涉及人员范围： 研发工程师。
动作：

• 根据release版本号创建对应的分支，分支名 = develop/ + release版本号，例如：develop/3.0.0。
• 在新建的分支上进行开发并自测，有条件的话根据测试编写的用例进行自测。
• 自测没问题，在最新的分支提交上打alpha版本的tag，并打包上传到ftp服务器，告知测试工程师去获取测试。注：
  • tag名 = alpha版本号，例如：3.0.0.118-alpha。
  • 包名 = 项目名_（选填） + tag名，例如：JH_3.0.0.118-alpha，如果打出的包是debug调试版，则包名需要加上标识debug，例如：JH_3.0.0.118-alpha-debug。

输出： alpha版本的包、CHANGELOG.md。

（3）alpha测试

涉及人员范围： 测试工程师、产品经理、研发工程师。
动作：

• 根据需求文档编写测试用例（前置条件、操作步骤、期望结果）。此步可以和第（2）点同步进行。
• 编写相关自动化测试脚本进行挂机测试。此步可以和第（2）点同步进行。
• 从ftp服务器获取研发工程师所指定的包进行测试，过程中发现问题，有条件时保留现场，让研发人员进行分析，有本地日志记录时，及时抓取日志，并确定问题出现时间范围。所发现的问题需要同样告知产品经理。
• 最后整理测试报告，并和产品经理沟通确认每个问题的严重等级：P0、P1、P2、P3，并把缺陷问题指给具体的某个研发工程师（不确定时指给研发经理）。
• 研发工程师根据严重等级依次解决处理缺陷。
• 所有缺陷自测没问题，在最新的分支提交上打alpha版本的tag，输出对应的包上传到ftp服务器，告知测试工程师获取测试。
• 在beta测试前，至少需要进行3轮的alpha

输出： 测试用例、测试报告、缺陷问题链接、alpha版本的包。

（4）问题修复

涉及人员范围： 研发工程师、测试工程师。
动作：

• 对测试所指派的缺陷问题，根据严重等级依次处理。
• 所有缺陷自测没问题，在最新的分支提交上打alpha版本的tag，输出对应的包上传到ftp服务器，告知测试工程师获取测试，重复第（3）点。
• 在beta测试前，至少需要进行3轮的alpha测试。
• 当最后一轮alpha测试没问题时，在最新的分支提交上打beta版本的tag，并打包上传到ftp服务器，提供给外部测试。注：
  • tag名 = beta版本号，例如：3.0.0.214-beta。
  • 包名 = 项目名_（选填） + tag名，例如：JH_3.0.0.214-beta。

输出： beta版本的包。

（5）beta测试

涉及人员范围： 产品经理、研发工程师、测试工程师、其他人员。
动作：

• 此测试面向的是非专业的测试人员，所以主要进行的是发散性的测试。
• 收集过程中的缺陷以及体验问题，产品经理组织研发、测试工程师进行沟通，分析缺陷和体验的严重程度，以及是否在当前版本进行修改，或是遗留到下个版本。
• 对于必改的，研发工程师进行修复，并重复alpha测试流程。
• beta测试一般1到2轮。

输出： 测试报告、缺陷问题链接、beta版本的包、CHANGELOG.md。