而移动基础设施（Mobile Infrastructure，我们称之为“Minfra”）提供了除产品流程以外的一整套 App 研发管控的 SaaS 服务，即涉及开发、发布、线上和修复的全生命周期管控平台。

　　饿了么移动基础设施建设的实践

　　饿了么移动技术团队在面对以上流程时，搭建了名为“Grand”的总体管控平台，并分别建立相应的管控模块来进行保障工作。接下来将分模块谈谈每个流程的具体细节。

　　持续集成

　　持续集成是每个互联网公司基本都会部署的一道开胃菜，通过代码仓库的“Webhook”操作来自动触发一次编译构造，从而快速定位该代码集成是否会导致整个项目崩溃。这一步，是一项“掌控代码”的操作。

　　对于持续集成的平台搭建来说，业内最常用的便是“Jenkins”。通过简单的“job”配置就可以轻松跑起一款 App 的持续集成。同时它还具备强大的可扩展性、简便的集群管控能力。也正因为这些优点，我们最终选择了“Jenkins”。

　　然而在饿了么，由于 App 数量众多，且随时可能会有新的 App 成员加入。于是乎，在这样一种业务场景下，为每款 App 都单独进行一次自定义配置就成了奢望。如何使用一个“job”就能让所有 App 都跑起来，是我们首要解决的问题。

　　得益于“Jenkins”平台的高度可自定义性，我们使用自己的 Python 脚本完成了持续集成的管控工作（如图 1 所示），同时使用“Grand”平台实现前端状态的监控工作。每款 App 使用一个预定义好的配置，来配合脚本内预定义的不同打包行为，最终汇总结果于“Grand”平台。

　　持续集成平台的搭建，让团队合作的代码最终趋于稳定状态。完全自定义的脚本代码，让未来“静态代码检测分析”、“自动化测试平台”的加入成为可能，真正实现了对代码的掌控。

　　图 1 Jenkins 管控页面 Release

　　代码已经 OK，功能也已完备，接下来就是接受千万用户检验的时刻了。在此，“发布”这个看起来最寻常、最微乎其微的功能服务，却是发挥极大作用的功臣。我们前面提到，由于用户量巨大，99.99%的 Crash 率也能给成千上万的用户带来困扰。为了最大限度地减少这种困扰，一个具备“灰度发布”的服务被赋予了非凡的意义。

　　图 2 App 发布灰度配置信息

　　通过向特定的手机、城市甚至人群发送升级提醒，让部分、少量的用户升级至新 App（如图 2 所示），以观察这部分用户的 Crash 率成为了我们防止大规模 Crash 最主要的解决方案之一。在灰度的过程中，一旦发现 Crash 率快速上升，则可通过关闭“发布”渠道来防止事态的进一步升级，让“能用”这一用户体验等级得到掌控。

　　看到这里，一定有读者会产生疑问，对于 Android 操作系统而言，以上方案或许可行，但对于 iOS 是否有更加可行的方案？

　　的确如此，对于 iOS 平台而言，由于 App Store 的存在，往往很难达到灰度控制的目的。事实上，如果有条件的话，可以适当地采用 iOS 企业版来做灰度。不过这种方案并不被推荐，企业版也不是为该种目的而生，所以我们也并未完全采取这种方案。

　　另一种 iOS 的灰度渠道方案，j2直播，则是在各大越狱社区进行分发，同样可以绕过某些监管。当然，由于安全性原因，也具备一定风险。因此，如何取舍还是得看读者自己衡量。

　　HotPatch

　　上文提到，在我们的 App 发布过程中，一般会让部分用户进行升级，通过观察其 Crash 率来决定是否最终全量该版本。在过去，这部分用户被“牺牲”后，如果其不主动再次升级自身软件版本，阴影将永远笼罩在他们的头顶。然而数据告诉我们，移动 App 用户的主动升级率一直处在低位，因此总会有这样一些用户不断被这团阴霾所困扰，最终选择离开我们。

　　在这种历史情景下催生的“HotPatch”技术，简直就像是救命稻草一样，拯救了一大批这样的 App 用户，同时也拯救了在移动端默默奋斗的程序员们。只需通过“HotPatch”服务有针对性地下发修复 Bug 的 Patch 包，就能达到降低 Crash 率的目的（如图 3 所示），从而很好地提升用户的基本体验。也就难怪该项技术出现后，各大厂商都趋之若鹜。

　　图 3 通过“HotPatch”发布包 小结