vlambda博客
学习文章列表

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

这段话中提到的移动应用开发想要的理想环境，刚好 DevOps 都可以满足，因此一些超大规模 APP 的研发模式，尤其是偏项目式研发协同的人员、模块较多的研发，都开始慢慢研究 DevOps 体系。那么，移动 DevOps 建设与 Web DevOps 建设有什么不同之处？移动 DevOps 的建设有哪些难点？移动 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 的建设过程中，支付宝主要集中在了研发协同、研发效率和质量保障三个方面。

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

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

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 分析，以保障整个客户端产品的质量；在与端技术无关的方面，会有相关的团队协作能力，包括需求管控，分支管理，依赖管理，人员管理等。