正文
针对以上问题,我们对平台进行了升级改造,主要为:
消息机制的改造:
首先基本打包架构和流程保持不变,在 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)。
图 2 测试打包发布
如图 2 所示,在集成测试阶段,MCD 平台会自动选取已发布(RC 版本)的 Bundle 打出集成包,测试完成后测试人员可以将测试结果反馈到 MCD 平台中,待测试全部通过之后就可以安排 App 进入发布定版阶段,再进行一些后续市场包操作就可提交给 App 应用市场供用户下载。
由于 App 的开发是个连续过程,测试包和集成包都可以很方便地配置是需要 Hourly build 还是 Daily build,并且可以和测试平台的相关功能联动,从而实现持续集成。
我们也会将不同版本(不同功能)的 App 按照项目进行划分,主版 App 为标准项目,非主版(渠道/HotFix/Bundle)App 为非标准项目,同一项目内的 Bundle 可以自由组合,项目之间互相独立,不受影响。一个项目在创建时可以选择从另一个项目继承其各模块的最新版和发布版。项目在开发过程中也可以从其父项目中实时同步对应模块的最新版和发布版,这样就能基本满足各种开发和测试的需求。
测试平台
随着携程持续交付的发展,原有的测试模式以及流程渐渐显现出不足,主要体现在以下三点:
-
快速验证与手工验证的冲突;
-
自动化回归测试与手动测试效率的矛盾;
-
设备兼容测试与设备不足的矛盾。
快速验证与白屏检测