周版本制度
一、版本开发基本方案
时间跨度：每周一个迭代版本
所以需要将开发计划切割成以周为单位，并且每个迭代需要有可验收内容
- [√] 便于把控开发进度，并通过每周的开发速度来评估进度风险；
- [√] 将整体切割成块，方便根据每个开发同学的有效时间，对计划进行合理排期；
- [√] 定期验收，便于及时优化和解决bug，以免堆积到临近上线一起检出和修复会增加质量风险；
- [√] 加强时间规划，且有定期节点，便于督促进度
基本流程
时间节点
- 需求确认：版本开始阶段，确定本周需要完成需求，在需求确认期后原则上不能提本周版本新的需求，增加需求需要走需求变更流程。
- 开发期：版本开始至版本预留回归测试时间点，策划、研发（程序）、美术进行需求开发，测试进行需求测试。开发和测试人员必须在个人需求单初步测试通过后方开下班。
- 回归测试期：进行测试收尾和整体回归测试。开发和测试人员必须在测试组长宣布版本测试完成后方可下班。
- 版本发布：版本结束后第二天进行版本发布
需求开发和bug修复
- 开发期截至前，将所有本期功能开发完成，并通过自测或策划验收，如有逾期，则需进行加班完成或与需求方和PM确定延期及重新排期，并在测试报告中记录，作为KPI的考核点之一
- 优先按优先级修复BUG，版本结束由测试组长通知，需要延期的BUG需与需求方和测试确认，并在测试报告中记录。
质量标准
- 不能有影响游戏进度的阻塞性问题
- 已做完的feature，不能有严重程度为一般及以上的bug
- 未做完的功能，不能影响其他功能的质量
BUG分级
1、严重等级：（按照线上标准，不以出现概率和难易程度做为衡量因素）：
- 致命 ：客户端崩溃；服务器宕机；内存泄漏；阻塞游戏流程且需重启客户端才能解决的；无限刷道具或货币；给玩家或公司造成严重损失的
- 严重 ：阻塞游戏流程且无需重启客户端方可解决的；影响游戏模块流程的
- 一般 ：功能、数值问题；影响玩家正常游戏或认知的美术资源问题
- 提示 ：剩余美术资源问题
- 建议 ：非bug的感受度、易用性
2、优先级（以影响当前迭代版本为衡量因素）：
- 紧急 （立刻修复）：影响开发或测试进度的问题
- 高 （当天修复）：影响该版本验收进度的问题
- 中 （版本发布前修复）：影响游戏体验的问题
- 低 （可延期修复）：不影响游戏体验的问题
版本总结计划会
- 时间：版本开始阶段
- 内容：总结上个版本的问题，同步整体进度，计划后面迭代版本的需求
二、版本开发流程细则
-
主干上一直可以开发提交，每次提交前要注意自测（至少保证编辑器上能运行）
-
要保证每天凌晨自动打包可以成功，并游戏可以运行，若影响打包或游戏运行者，会受到相应惩罚
惩罚措施：
1.每月首次触犯者，周会上进行检讨：总结问题产生原因，以后如何避免
2.每月第二次及其以上重复触犯者，除周会检讨外，还额外会有经济惩罚
-
每天晚上定时自动打包，并进行基本的测试（包括安装卸载，冒烟测试等），可选手动的测试或自动测试，以此预检查是否会影响次日凌晨打包及游戏运行（将结果单独推送到程序群）
-
若开发周期需三天及其以上的大功能的开发阶段，尽量采用可选的屏蔽方案（如debug开关进行屏蔽）；不得不影响次日凌晨打包的情况，则需先告知测试组长，经同意后方可提交，并由测试组长在项目群中提前通知，否则按影响打包或游戏运行记录过失
-
测试人员按照可测标准，及时对验收通过的需求或修复的BUG进行测试。
-
测试验收期初步测试后拉取外放分支，作为测试验收和发布分支；初步测试的覆盖程度和完成程度由测试组长根据项目开发的实际情况制定并落实文档，每个版本按要求执行；外放分支上需完成基本的回归测试与各类基础的专项测试，并在测试报告中反馈测试数据。
-
版本包需要根据实际开发情况进行有针对性的专项测试。如开发期涉及到影响客户端性能的修改，则需进行客户端性能指标测试。
-
拉取外放分支后提交主干的需求内容，原则上不会进入本迭代版本验收。如有特殊需求，需与测试组长申请，经评估后方可合并入分支进入本迭代版本验收
[√]可以有个稳定的验收、测试、跑自动化的环境
[√]测试期间可同步开发
[√]全部主干拉到分支，极大的减少合并解决冲突的情况
[√]为以后出版本包提供靠谱的资源环境 -
发布周版本前，需进行一遍整体测试，可优先测试广度，测试深度适度即可。例如跑一遍所有新手引导。再完成测试后组织项目组内成员进行小组体验测试。
-
迭代版本的本发布，若没客户端C#/C++代码更新，则尽量出更新资源
[√]方便、快速获取最新资源，不用重新装包
[√]模拟上线后补丁版本更新流程，提前找出问题，并解决 -
开发期分支管理：
拉取外放分支后，在外放分支上进行的回归测试中发现的bug，可采用如下两套方案：
1.在开发主干上修复，然后自行合并入分支；
2.在外放分支上修复，然后合并入开发主干上。
两种方式均需特别注意分支合并时可能产生的冲突，出现冲突时严禁进行直接覆盖。
-
线上分支管理
在线上版本分支修复bug并验证，再合并至开发主干 -
测试报告
周版本结束后，输出周版本测试报告，总结本周进度和问题，自动统计各项开发数据
三、里程碑版本测试
时间跨度：一个月到一个半月左右为一个里程碑
- 此节点要有一定量的完整功能供验收、体验等
- 将一个大目标，拆分成多个小目标，逐一实现
- 开发期中，最接近上线品质的版本
- 一定时期的里程碑版本，可用于公司内部跑测，提出改进建议
- 避免最后全部开发完再跑测，改进时间不充裕，或改动大，造成风险等
目标：
- 完成周期内所有迭代版本的制作与验收
- 修复掉所有遗留bug
质量标准：
因里程碑是由多个迭代版本组合而成，所以开发流程基本与迭代版本一致，只是目标和质量标准提升一个高度
- 不能有影响游戏进度的阻塞性问题
- 已做完的feature，不能存在bug
- 未做完的功能，不能影响其他功能的质量（通过排期和节点的提交控制，尽量减少里程碑版本中的半成品）
- 里程碑版本结束前，需要有各项专项测试数据输出
附：分支管理建议
-
能尽量按原提交顺序进行合并，以减少冲突的产生
-
分支与主干的关系，不易太过交叉复杂，越简单越好。如果有多个分支，或交叉关系，一定要标记好依赖关系
-
分支与主干不能是嵌套关系
-
分支与主干的内容差异，尽量是包含关系，不要互相都有互相没有的内容
-
版本发布后，要拉取分支以作备份
-
按需保留线上分支，一般至少保留近两个版本
