关于游戏开发版本的常识。

我不是先知

写在前面：
之前的工作里没什么感觉，最近发生的一些事情，才让我感觉到，混乱的流程和版本管理，是如何反映了项目内部的效率缺失，尤其如果搭配上素质良莠不齐的人员，直接抓瞎。
我的理念里，就算规模再小的团队，不论有没有专职PM，只要是有线上运营游戏的需求，都应该有一个清晰明确的版本规划与发布流程。
这是基本的素质，如果这点都做不到，以后一定会以某种方式加倍赔回来。

在游戏策划/项目经理的视角来看，一个极简化的项目至少需要分为3个类别的版本，关系大致如下：


主干开发版本

• 主干开发版是平时日常开发使用的版本
  
• 平时各个类别的开发人员都会在这个版本提交内容，变动频繁，稳定性较低
  
  
  
  • 有些项目会定期基于主干出测试版本，所以需要维持一定的主干稳定性，这类项目就对开发人员的提交内容有一定要求，或是对主干也进行日常的QA维护
    
  • 还有一种保证主干稳定性的方式，就是大功能单独拉分支做，但这样也会有额外的代价，合并代码也非常麻烦，慎用
    
  
  
• 所有要发布的内容，除了特殊情况，都应该是从主干拉取对应的分支再行发布，而不能直接从主干同步到线上运营版
  
• 当确定版本计划之后，完成应有的开发内容后，按某一个提交记录之后拉取分支。拉取分支后，主干按计划继续开发
  

版本分支/预发布版本

• 分支版本的意义，在于能够确保某个交付版本的内容和质量达到要求，并且不影响后续其他主干的内容开发。
  
• 从主干拉取分支，而不是从某个分支再拉分支，子子孙孙无穷匮，生生世世改bug。（我也是最近才知道有的人连这点常识都没有）
  
• 拉取分支的节点，需要有明确的目的和要求，且需要同步到团队内所有的开发人员，明确开发内容完成的时间点，安排好内容开发排期，避免分支拉取的时候，还有做到一半的内容，被迫双线提交的情况。
  
• 版本分支拉取之后，QA团队开始深度介入，明确版本质量标准之后，以在规定的时间内清零bug为最优先目标
  
• 除特殊情况外，一般不在分支上进行额外的功能开发（这点其实很难做到，但原则上尽量避免）
  
• 在分支内修改的bug和其他内容，也需要合并回主干，避免两个版本差异不可控。通常有两种方式：
  
  
  
  • 开发过程中同步修改，在分支修改的内容，及时双线提交回主干，一般适用于bug的修改
    
  • 在分支版本完成目标之后，由各个团队的负责人一起评估，分支的改动是否要合并回主干，一般适用于分支上做的一些骚操作功能。
    
  
  
• 分支bug清零，质量达标之后，即可作为预发布版本，准备发布到线上运营。
  

线上运营版

• 线上运营的版本，如果不是第一次上线，通常都已经有玩家在上面实际在玩，因此做任何操作都必须要小心，以不出事故为第一优先级的原则
  
• 从预发布版本到运营版本，原则上还需要有一个模拟正式运营版本环境（服务器时间、配置等）的灰度版本，更新的时候首先将预发布的内容同步到灰度服务器，由QA人员测试无误后，再同步到线上运营版本。
  
• 线上运营版更新一般都会出现各种意想不到的问题，放平心态安排好补偿，只要不是致命的问题，基本都还好。
  
• 版本发布之后，多关注一些玩家社区的舆情，如果出现有人发帖说有问题，请一定相信是真的有问题。因为只要有1个发帖的人，通常背后都会有成千上万的人遇到了问题。
  
• 尊重玩家，尊重自己的职业，尊重劳动。
  

本文是我工作以来的一些简单经验+理解，没思考的很深，欢迎讨论，也计划在本专栏多发一些这类型的文章，作为自己一些工作的记录。
如果觉得对你有帮助，欢迎关注，点赞，收藏，或者留言与我交流。

幸福一生一世

单人独立网游 在线热更 生产环境手调bug[酷]

不老的天空

一个人想咋整咋整，哈哈

彭建忠

我也是坐沙发的