1、外网版本管理

    对于手游产品来说，产品上了线，打包发布工作量会飙升，主要是因为版本多。一般强制玩家更新底包都会造成玩家的流失，所以我们要尽量避免底包更新，一般都会采用热更新的方案，这就造成了版本多。

1.1、两平台版本底包的不一致

    IOS发布底包需要有一个审核时间，快的1、2天慢的1周，甚至还有被打回的风险，对于游戏开发来说，这个时间是非常宝贵的，因为需求每天都在加，BUG每天都在改，不可能提交了就不做了。所以一般情况下是提交IOS底包，等他审核后再同时与安卓一起上架，以保证两个平台的同步。而在发布的同时会发热更新包，以保证两边的版本一致。

1.2、两平台可能底包数量不一致

    连个平台的底层语言是不一样的，一个是ObjectC一个是Java，可能因为某些底层或者接口底层Bug，甚至是某些特定平台的需求而发一个单平台的底包。这时可能在IOS平台上和安卓平台上的底包个数不一致

1.3、停止更新一个底包

    这就和操作系统一样，一段时间后，由于这个底包的使用率过低，比如我们是低于1%，这个时候就要强制更新底包，让这个版本失效。另外也可能是一个底包存在一个严重bug，也会强制玩家更新底包。

1.4、两平台版本内容的一致

    再说下如何保证IOS，安卓两大平台版本同步的问题。由于我们存在不同的平台，同一个平台在外网可能同时又存在多个底包，而且我们是网游，服务器是一套，玩家需要互相通信。所以我们每次发布新的补丁，或者版本，都需要考虑所有底包的兼容性，需要把外网所有底包的内容，通过热更新，打到同一个内容水平。

2、发版流程

    在开发完一个功能后到见到玩家，中间有许多环节，有的用来开发、测试，有的用来IOS提审、运维运营预操作测试，玩家预体验，这些环境都是最终品质的保证

2.1、主干与审核（测试）

    这个是常用的两个环境，一个是给开发用的主干版本，一个是给测试和策划审核用的审核环境。这两个环境在产品没上线前也存在。通常只要强调技术尽量保证审核（测试）环境的稳定性，不要传个“有毒”的代码上去搞的完全挂掉。

2.2、IDC-D（天）、IDC-W（周）、IDC-M（月）

    这3个环境对应不同的版本内容，对应这3种内容：大版本内容、一般bug可以周更新的线上需求，需要立即更到线上的紧急BUG。

    这个IDC-D（天）环境就是和外网的代码保持一致的环境，用来保证处理紧急Bug。

    IDC-W（周）环境用来开发“周版本”的内容的，这样测试可以在上面测试需要“周更新”的内容。

    IDC-M（月）这个环节是用来开发大版本的，一般用来开发回归测试大型月版本。

    为什么要3个，因为会并行，如果你能保证你开发、测试月版本的时候没有“周版本”、“紧急更新”内容，你可以不需要这么多，当然这个要看项目规模

2.2、外网测试

    这个环境是给代理商的测试用的，内部测试完成后，把包给代理商，通过代理商的第一道测试。恩，我们是上的腾讯，腾讯通常要求尽量提前给他们测。通过测试就可以往后走了

2.3、IOS审核服

    如果你这个是一个底包更新需要上传苹果App Store的，你就部署在这个环境上面，在这个环境测试后，再提交审核。审核期间要保证这个环境的稳定性，不要乱重启，影响到审核...可能就会影响发布时间。另外苹果审核有很多限制，可以在这个环境上开发一些开关，你懂的。

2.4、预发布

    这个环境通常是和外网正式环境一模一样的，运维大哥在操作更新之前，需要在这个环节进行预操作，在预操作后，测试进行验证功能是否发布成功。这个环节腾讯做的非常到位，腾讯的运维大哥好严谨呀，真的在这个环节发现过问题。

2.5、先锋服（灰度服）

    这个环境是先给一部分测试玩家试用，一般用在大版本上线的时候，需要更加谨慎的上线。这个环节通常能发现很多隐藏的服务器Bug，这也是这个步骤的价值

2.6、正式环境

    一般看你的服务器结构，苹果要求是不能与安卓的玩家同服，所以即使是大服制架构的服务器，也需要分开搭建，另外还有个游客服，或者其他的环境。

2.7、各环境的管理

    因为环境很多，所以这个地方需要记录每个环境上跑的各个版本号，不要搞乱，通常会找个表格来记录

3、线上问题处理

    “没有更新就没有伤害”只要你有版本更新上线就会产生新的Bug，甚至你可以看当天的Bug数就能猜出有版本上线了。

    出了线上问题，确定存在后，先判断他的处理级别，再来确定后续的处理方案。“影响范围”就是到底这个Bug会影响那种玩家，还是全部玩家。“问题紧急程度”这个紧急程度，有多个因素影响，比如是不是会影响玩家数据，数据是否可修复，是否会阻碍玩家正常游戏，你可以给这个定一个标准。最后是“更新难度及更新影响”这个需要技术在分析问题后得出，因为这是游戏，有的Bug可能要重启服务器，有的需要玩家重启客户端，而这些都是要尽量避免的。

    项目经理要通过3个方面来评估这个Bug是现在更新，还是等到周维护更新，还是等下一个大版本更新。记住任何决策都要承担后果，要多听取测试与策划的建议。

3.1、一般线上问题

    对于这类问题也要做一个管理表格，记录发生的问题与解决方案，因为有些Bug不是代码问题，可能是配置问题，可能是模板表的问题，也可能是运维、DBA的问题

3.2、严重事故

    对于影响范围大、后果严重，已经上升到事故级了，除了上面的问题处理记录，还要给这个事故定个级别，“漏测分析”，“改进措施”区分除测试外（因为理论上所有的问题测试都有责任）的责任方。

4、更新管理

4.1、更新类型

    “紧急更新”一般是处理紧急Bug，通常都等不到半夜，要求白天处理，那对应的更新方法应该是热更新，所以你项目的服务器、客户端的热更新能力一定要有。关于热更新：服务器如果是Java可以热更新一些方法体、c++可以考虑使用共享内存来实现、客户端大量使用lua，这些都是需要技术提前考虑的

    “周例行维护”一般处理小功能升级、一般性线上Bug，通常在每周2或某天的凌晨进行操作，所以是可以做闪断更新的，当然能热更新就热更新

    “大版本更新”这个在更新上没什么难度，一般就“闪断更新”或“重启更新”

4.2、更新内容

    当确定要做一次线上更新，需要在这个表里面记录下更新内容，每个内容必须包括涉及的资源、脚本、表甚至代码文件，因为需要根据这个来确定“更新范围”（服务器、客户端、还是包括数据库等等）,根据这个“更新范围”后面要确定“更新方案”

    测试也会根据这个内容来进行更新包的检查，防止漏合多合文件，热更新包也要根据这个来检查完整性

4.3、更新方案

    不同的游戏产品技术方案有不同的更新方案，不过都大同小异，这些需要和技术提前沟通清楚，你必须要了解的各个方案的不同特性，对玩家的影响，操作成本等。

    注意：只要升级，都要提前通知玩家升级时间，说明可能会造成的影响。

4.3.1、热更新方案

    服务器热更新，意思是可以不杀进程（不重启程序）的情况下，动态更新程序的方案。JDK1.7后可以热更新一些方法体，c++或其他可以采用Lua脚本的方式。

    客户端热更新，是指玩家不需要重新下载完整的App，在登录的时候（或者其他时机），自动升级程序的方案，一般都是Lua的解决方案

    热更新好是好，当然有诸多限制，比如用java的方法体更新，方法签名是不能改的，还有嵌套类、静态方法等等。服务器热更新的时候还要考虑内存数据如何升级，可能需要写段代码来升级内存数据。协议升级更麻烦了，因为需要客户端同时生效，除非一开始就做了兼容。总之热更新之前一定要做热更新测试，因为有很多意外情况的出现。

4.3.2、客户端提示更新

    当某次更新，客户端、服务器都可以热更新，但需要同时生效。但热更新的两个的生效时间是可能不一致的，服务器是立即生效，客户端是重新进入游戏的时候。比如“协议改了”这种情况，你就不能选择这个方案了，服务器热更新的同时需要把所有玩家提下线，强制更新客户端才行。为了照顾到玩家的体验，一般会选择弹一个提示，要求玩家重启游戏，来达到这个目的。当然在战斗中的会继续让他们打完，当打完战斗退出战斗拿完奖励后再提示

4.3.3、闪断更新

    如果你的服务器是大服制，或者做了微服化。那某次升级需要重启部分服务，而客户端可以热更新。可以用这个方案。这个方案会导致玩家被踢出游戏或踢出某功能，但立即（或者3s内）又可以正常使用。如果是需要客户端立即生效，可以选择提示玩家，强制让玩家重启游戏。

4.3.4、停服更新

    这是常见更新方式，适用于服务器需要停服升级，数据库、缓存需要做大规模升级。玩家在停服期间不能登录游戏，客户端提示升级中，预计停服结束时间。

4.3.5、底包更新

    这个是指客户端无法热更新，必须要改底包的更新方案。就算热更新做得好，一般1个季度建议也提交一个底包更新，这样减少热更新包的大小。

    底包更新又分为不提示更新、提示更新、强制更新3个阶段。需要根据实际情况来判。底包更新刚上线的时候，一般先选用“不提示更新”，这种方式只有新玩家或开了自动App更新的玩家才会拿到新版本的App。而提示更新是指，在登录的时候会有一个提示，提示玩家是否更新App，玩家可以选择不更新，因为玩家可能处于非Wifi的环境，选择了不更新玩家可以继续进入游戏。而强制更新一般是用在某一个底包版本通过前两种方式，版本使用率降低到1%或者更低的时候，就可以开这个强制升级了。玩家进入游戏的时候弹提示，不升级进不了游戏。

4.4、更新步骤

    更新必须要技术写更新步骤，运维、测试需要按更新步骤先在预发布服上进行预更新测试，更新步骤需要考虑的各个更新的点，比如数据库更新、服务器更新、客户端更新，各个更新步骤直接的先后关系也是重点考虑的点。

    建议尽量把更新过程写出脚本，脚本化更新过程，如果你的产品开服多，或者你上的是腾讯，一般必须会要求脚本化升级过程。你的更新脚本就按设计的更新步骤来。而且每次更新很多地方是一样的，只是内容不一样，这时建议做更新模板，来降低开发更新脚本的复杂度。比如这是一次大版本更新的步骤：

4.5、风险管理

    有更新有风险，在更新前，还需要做好风险评估。首先列出更新内容，评估各个功能的风险点，预估发生问题后的影响范围，根据影响范围大小，来评估风险高低。如何来降低影响范围呢，开发的时候就要做好保底措施，比如玩家一天最大的收益底线，背包里堆叠物品的上限，副本最大的收益次数。注意这里不是策略的逻辑，是服务器的保底，确保在发生异常情况下，不会有太大的破坏力。

    应对方案，这个在风险评估的时候一定要做的。最常见的应对方案是先要做功能开关，遇到问题的时候可以随时关闭某个功能。也有紧急热更新的，尽量避免在应对方案的时候就有需要重启服务器打补丁的方案，因为重启服务器打补丁是万不得已的方案。