实例分析无线持续交付平台 MCD 的实践应用

　　目前携程大部分订单已来自移动端，App 几乎承载了整个集团的所有业务形态。在内部研发中，携程的 App 已经发展成为拥有 90+ Native Bundle、100+ Hybrid Bundle、30+ React Native Bundle，几百名研发人员，每个版本（1 个月）交付 4000+个 App 包，Hybrid/React Native/HotFix/Bundle 发布次数 500+。如果没有一个有效的无线持续交付平台，很难实现大版本的集成发布在 3 天内完成。而对比市场上开源的无线持续集成工具 Fastlane、TestFlight、Jenkins 都存在各种定制化需求的问题。因此我们从零开始，逐步打造适合携程研发流程的无线交付平台，系统化地解决研发支撑痛点。下面将从集成、测试、发布、运营四个子平台来展开，具体分享我们是如何一步步打造无线持续交付平台的。

　　集成平台

　　从最初到现在，携程无线持续交付模型经历了从 1.0 到 2.0 的迭代演进。在 1.0 之前，App 集成和发布还主要依靠人工操作 Jenkins，需要由特定的打包人员负责打包，再将包通过 IM/邮件等方式传递给其他测试人员，测试结果需要专人手工回收，以把控 App 质量。此时最大的问题就是 App 管理混乱，人工介入过多，每次发布都需要花费很长的时间。

　　1.0 阶段

　　在 1.0 阶段，我们引入 MCD（Mobile Continues Delivery）平台思路，将打包人员的工作交给平台来完成，提高了发布工作效率。这时不需要专职人员负责出包，平台会定时自动打包，测试人员可以到平台上自由取包（通过下载链接或扫描二维码的方式）进行测试。与此同时，测试人员也可以在平台上进行单独的打包和测试。测试结果会统一反馈到平台上来，协调人员在平台根据各家的反馈结果决定需要重新出包还是继续下一步发布操作。

　　在这个阶段，App 的打包还完全依赖于源代码进行，由平台生成打包参数（主要包含 App 运行环境、与 iOS 签名相关的参数以及代码仓库相关的参数）提交给后台的打包系统。它会根据仓库地址和 commit ID 从代码仓库中拉取全量代码，然后打包系统再调用代码中预先准备好的 Build 脚本构建 App 产物，构建完成后将结果保存至临时的文件服务中，最后由平台的回收进程将构建结果回收并处理之后放在云存储上供用户下载使用。

　　2.0 阶段

　　1.0 阶段虽然已经基本实现了集成打包的自动化，但是还存在以下几点不足：

　　源码打包方式效率低下，每次都要从代码仓库中下载全量代码，再通过源代码生成 App 产物。这样做使得每次 Build 时间都很长，而打包次数的增加会导致某些打包任务积压，系统不能及时出包。

　　编译容易失败，任何一个 Check-in 导致的编译失败，就会致使系统不能正常出包。

　　系统之间采用轮询模式，Job 任务扩展性差。

　　MCD 系统发起 Build 请求之后会有另一个定时的 Job 任务去轮询 Build Server 查看 Build 结果。在初期阶段还能满足业务需求，但是后来由于打包数量的增加以及打包频率的提高，系统的处理效率变得越来越低。一方面打包资源不够（Android 打包使用 Linux 虚拟机，iOS 打包使用 Mac），另一方面轮询 Job 的处理效率达到了瓶颈。打包机器采用 Jenkins 方式进行管理，因此很容易进行横向扩展，但是 Job 却很难扩容。

　　针对以上问题，我们对平台进行了升级改造，主要为：

　　引入消息机制，提高系统吞吐量；

　　将工程进行拆分，按照 Bundle 的方式进行打包。

　　消息机制的改造：

　　首先基本打包架构和流程保持不变，在 MCD 系统和 Build Server 之间增加消息系统，MCD 发起 Build 之后不再轮询 Build Server，而是消费由 Build Server 产生的 Build 完成消息，如图 1 所示。使用这样的生产消费模型 MCD 可以轻易地进行水平扩展，系统执行效率得到极大改善。

　　图 1 Bundle 打包工程拆分：

　　App 工程拆分成多个不同的 Bundle 模块，Bundle 之间存在依赖关系。在这个情况下 App 的编译和打包也可以按照 Bundle 的方式进行组织。在开发阶段，开发人员提交完代码之后就能直接将自己负责的 Bundle 编译成可执行文件，测试可以自由选择 Bundle 进行打包。此时打包工作只需将多个 Bundle 文件组装在一起就行，极大地加快了打包速度。通过测试的 Bundle 会被发布到指定地点，在 App 集成阶段只需把所有发布的 Bundle 组装成最终 App 供大家测试即可。

　　在开发自测阶段，开发人员提交完代码后在 MCD 平台上 Build 出所开发的 Bundle（标记为 L，表示 Latest）。相关测试人员（或开发人员自己）可以打测试包，测试包会使用所有 Bunde 的 L 版本进行构建。构建完成之后获取测试包进行功能测试，测试通过后就可以将该 Bundle 进行发布操作，即标记为 RC 版本（表示 Release Candidate）。