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

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 ）关注我们，并与我们的编辑和其他读者朋友交流。