移动开发面临持续交付挑战

Jesper Richter-Reichhelm作为Wooga公司的工程主管，他在2014年的阿姆斯特丹GOTO大会上发表了演讲，主题为开发移动游戏过程中团队所面临的持续交付挑战。Jesper尤其强调了缺乏对移动相关软件交付过程的控制如何差点摧毁他们的公司。\

Jesper借用一款移动游戏去年年底在App Store发布的案例阐述了他的观点。此次发布到被App Store接受花费了4天时间，但是却包含了一个严重的bug，致使15%的用户受到影响。虽然他们只花费了几个小时就将bug修复并且向App Store提交了新版本，最终用户却是在5天之后才获取到新版本，因为这几天正好是美国的感恩节。数以万计的差评，受影响用户接近200000，使得该游戏差点遭遇灭顶之灾，整个公司都差点垮掉，Jesper如是说道。\

在web开发中有越来越多的做法支持持续交付策略，比如canary（金丝雀）部署方式（为了控制新特性的发布）或特性开关，但是App Store发布过程并不支持这些方式。为了绕开这些限制，Wooga公司投入了相当精力支持对其游戏进行在线配置，而且通过一些技巧如“伪造的”设备要求（如是否配备相机）来划分他们的用户，以达到对部分功能进行canary（金丝雀）部署的目的。虽然如此，公司还是依赖用户去主动安装应用的更新，超过10%的用户还在使用18个月之前的老版本。如果你要他们强制升级到一个只能在线玩的版本，他们就关掉网络。\

此外，在发布应用到App Store环节，Wooga公司停止了从专用机器手动发布版本的做法（但是Jesper建议将dSYM文件进行版本管理，目的是调试崩溃问题），因为这种做法构成了单点失败，在需要向App Store发布新版本时，这种单点失败增加了修复bug的时间。Wooga还建立了自己的内部应用商店，用来模拟App Store的发布流程，同时允许内部用户测试游戏的新版本（与Facebook的做法如出一辙）。\

除了交付机制和MTTR（Mean-Time-To-Repair，修复平均时间），Jesper还强调对于网络和设备的控制缺失是Wooga在移动开发中面临的主要挑战。\

尤其是移动网络延迟波动和离线使用容易导致数据丢失，后果就是我们很难保持数据的一致性和/或调试用户碰到的问题。为减小问题的影响，Wooga采用的手段有，与手机客户端异步通信，同等对待所有消息（即使是几天前的）以及引入ETags来解决更新冲突。\

查看英文原文：Continuous Delivery Challenges in Mobile Development

\

---

感谢曹知渊对本文的审校。

\

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。