支付宝 App 是如何建设移动 DevOps 的？

本文系InfoQ对蚂蚁金服技术专家洪锋的采访，洪锋老师即将在 QCon 上海站 2019 分享《移动研发 DevOps 在支付宝 App 内的落地实践》，欢迎关注。

微软 MSDN 上的一篇文章有这样一段话：“移动应用的理想环境须要知足两个条件，一是能够确切知道客户脑海中当即浮现的需求，二是为了知足这些需求而编写的代码能够当即传递给这些客户，简单来讲，就是客户需求、开发和传递之间没有任何间隙。”

这段话中提到的移动应用开发想要的理想环境，恰好 DevOps 均可以知足，所以一些超大规模 APP 的研发模式，尤为是偏项目式研发协同的人员、模块较多的研发，都开始慢慢研究 DevOps 体系。那么，移动 DevOps 建设与 Web DevOps 建设有什么不一样之处？移动 DevOps 的建设有哪些难点？移动 DevOps 如何面对新技术的冲击？…为了解开这些疑问，InfoQ采访了蚂蚁金服技术专家洪锋。

移动DevOps 与 Web DevOps

近两年，DevOps 已经成为企业软件研发的主流，被众多企业所采用，有关 DevOps 的实践分享分享也特别多，但大多集中在 Web DevOps，相比之下，移动端 DevOps 的实践分享就比较少。

之因此会出现这种状况，琉克认为是由于Web DevOps 具备更加稳定的执行和验证环境，一般在服务器上能够直接进行全部的开发、验证、交付等流程。而移动 DevOps 最大的难题是移动应用没有一个稳定的验证环境，大多数移动应用均可以在多个设备上使用，也就意味着要处理各类技术规范，操做系统版本，屏幕尺寸等。目前移动端主流的操做系统有两个，分别是 Android 和 iOS。其中Android 以各自为政而出名，每一个设备商都建立了本身的操做系统，存量设备差别极大，而 iOS 也具备多个变体，存量设备 OS 版本跨度大。除此以外，移动应用还具有人机交互的特性，例如当前比较流行的扫码、人脸识别等技术，那么如何在移动 DevOps 中尽可能减小人工干预，让总体变得更顺畅，提高总体的研发效率，这是咱们要思考的问题。

虽然移动 DevOps 建设存在一些难题，但其实移动开发与 DevOps 是自然契合的，由于客户端开发，尤为是智能终端，原本就是新兴的领域，技术的迭代更新比较快，再加上端产品的特殊性，好比没法实时回滚降级等，因此客户端产品的核心建设主要集中在研发协同、研发效率、新技术落地、质量保障等方面，这与 DevOps 的建设目标也不谋而合。

除了 DevOps 是否适用于移动开发，相信不少人都会关心什么时候建设 DevOps。琉克认为：“DevOps 的主要目的是为了提升总体的研发效率，因此 DevOps 应用的最佳时机就是当公司业务发展出现多个业务并行发展，且规模均达到数十人。由于这时企业的研发效率和质量就会成为一个瓶颈，为了打破这个瓶颈，就会有不少员工投入到工具研发中，以实现必定的自动化能力，不免会出现不少重复造轮子的工做，这时进行 DevOps 建设，统一收口，就能够避免重复造轮子。”

支付宝移动 DevOps 建设

DevOps 与业务发展是紧密相关的，没有业务场景的DevOps 等于空谈，因此支付宝的 DevOps 建设也是在业务发展到必定阶段才开始进行的。

据琉克介绍，支付宝的技术和业务发展大体能够分为如下几个过程：

• 初期阶段

一个仓库，一套代码，而后是工具化组件化，最后是动态化生态化和智能化。在初期开发人员多是个位数，业务功能也并不复杂，此时几个开发，几个测试就搞定整个研发，这时候投入建设 DevOps 是投入远远大于产出的，没有建设的必要。

• 中期阶段

随着业务的快速发展和客户端技术的爆发，支付宝也落地了组件化和模块化技术，此时研发人员也达到了几十号人，人和人之间的沟通协做，质量保障已经变的很是困难，也是在这个时候进行了统一的建设。

初期阶段一个代码仓库、一套代码所有搞定的模式，在代码量增多的状况下带来了不少问题，包括互相之间耦合严重，一次编译构建时间太长，再加上当时业务发展带来了线上问题，急需线上修复能力，因此支付宝自研了模块化方案，实现了模块隔离，提早编译，动态更新等能力。

在 DevOps 的建设过程当中，支付宝主要集中在了研发协同、研发效率和质量保障三个方面。

以质量保障为例，当代码量从一个仓库发展到数百个仓库，百万级代码，简单的单测或黑盒测试已经不能保障总体质量。所以，琉克所在的团队经过分析支付宝的业务特色和业务场景，结合支付宝技术框架，进行了深度的定制开发，落地了不少静态和动态的质量保障能力，其中静态质量保障能力包括定制的静态代码分析，依赖分析等，而动态质量保障能力包括真机性能稳定性测试，用例录制回放等。

做为最终产物的生成方，支付宝团队也承载了构建工做，由于大型 APP 对性能和包大小有极致的追求，每一点点的性能提高和包大小缩减均可能直接影响用户的留存。支付宝团队经过构建深挖，开发了文件重排、代码重排、debuginfo 删除等构建技术，并经过线上的灰度逐步验证到最后正式上线。

移动DevOps 建设的难点

Gartner 研究总监 Jason Wong 曾在一篇博客中指出：“并不是全部的 DevOps 公司都会将DevOps 用于移动开发，根据 Gartner 调查结果显示，只有 42％实施 DevOps 的人表示DevOps 用于支持移动应用开发。” 为何在移动应用开发场景下 DevOps 的实践不多呢？

琉克认为主要缘由在于投入产出比，除了超级 App，大部分移动 App 的开发都是采起小团队小步快走的方式，开发和测试人员都不多，几乎都是个位数。可是移动应用因为其特殊性，要实现自动化用例测试、真机测试等 CI 能力，每每须要投入比较大的人力成本和资金成本，好比实验室的搭建，大量终端设备的采购，一整套自动化系统的搭建等。相比较而言，小型 App 因为自己复杂度不会很高，大部分场景能够经过开发测试同窗的单元测试，手工用例编写和测试等手段保证 App 的质量。

在移动 DevOps 的具体建设中，琉克认为包括如下难点：

首先，移动应用技术栈是割裂的，Android和 iOS 是两套彻底不一样的技术栈，如何统一两套技术栈的研发流程，这是一个挑战。支付宝的解决方法是抽象出一个移动端的研发模型，好比统一抽象模块化构建，统一依赖管理模型，统一迭代研发流等，具体的差别点放在每个模型的实施路由上，好比 Android 模块构建会经过路由配置到 Linux 服务器上经过 Docker 构建，iOS 模块构建经过路由配置到 Mac 物理机进行构建。

其次，移动应用的验证很是复杂，尤为是支付宝百万级代码，千人研发的状况下，每次的代码改动均可以有大量的代码和功能受到影响。在代码级别，支付宝经过深刻编译以及在框架层自研深度定制的代码扫描和依赖分析能力，精确跟踪每个 Method 的影响面，并经过评估系统把控每个变更带来的风险。在真机验证环境，支付宝有一整套完整的真机实验室，全方位监控移动应用总体的兼容性，稳定性，性能等。

第三，持续集成也是移动 DevOps 建设的难点之一。持续集成须要有快速稳定的反馈能力，所以在持续集成节点上，支付宝选择了单点突破，并作了不少优化，好比构建性能等；在 UI 自动化测试方面，支付宝自研搭建了实验室，定制硬件，从而支持更多的设备，且提高稳定性和吞吐量；面对集团内部各类验证服务能力对接，也借鉴业界 Gitlab CI、Github Action 等 CI 工具，开发了本身的 CI 编排工具，为开发测试同窗提供超高体验；任务执行 DSL 咱们又直接使用 Jenkins Pipeline 不重复造轮子。

除此以外，移动应用最近几年的新技术发展也很是迅猛，例如 Facebook 的 React 生态、Google 的 Flutter，以及近日热度很高的华为方舟编译器和鸿蒙系统，对于移动 DevOps 来讲，因为不少场景都是基于当时的技术场景和技术水位定制的，因此新技术的出现对生态及技术选型的冲击比较大。

为了面对新技术的变革，移动DevOps 建设须要把新技术耦合部分和非耦合部分拆分开，尽可能减小冲击。举个例子，在与端技术有关的质量工程方面，支付宝会提早进行预研和技术储备，好比在静态分析领域，以前只有 Java、OC 语言，可是随着小程序的出现，JavaScript、TypeScript 语言也渐渐被引入进来了，同时还会对前端语言作静态分析和 Native 分析，以保障整个客户端产品的质量；在与端技术无关的方面，会有相关的团队协做能力，包括需求管控，分支管理，依赖管理，人员管理等。