移动研发 DevOps 落地实践

大家好，我是来自支付宝终端工程技术团队的十境。本文将带领大家了解支付宝移动端如何随着移动市场的告诉发展，逐步沉淀优化出适用业务发展需求的研发效能实践。
0. 背景

如何解决百万级代码的极速构建？
如何让上百开发者在同一个 App 上高效研发协同？
如何保障代码频繁变更下的交付质量？

显然，传统的研发模式已经无法适应企业在数字化转型中快速迭代以及研发协同的要求，建设符合业务场景特性和有效支撑高并发、持续迭代集成需求的研发效能实践迫在眉睫。

1. 研发协作平台现状
   关于支付宝在移动端研发平台构建的历程，首先我们先展开看看目前平台的现状，并讲述如何参考 DevOps “三步工作法” 来正向建模我们的交付价值流，以及这些活动中比较核心的分支模型，构建，持续集成等。
   研发协作平台大概从 2014 年开始建设，如今支持的 iOS 和 Android 客户端代码量都已经超过 300w 行，拆分的 Bundle 数量也都在 300 个以上。我们每周的构建次数在 1.4W，安装包平均每天会灰度 2~3 次，开发测试同学达到近千人的规模。

我们支撑了蚂蚁集团支付宝、网商银行、财富、口碑等产品的交付，支持的技术栈从最开始的 Android 和 iOS，演进到厂商 SDK、小程序、IoT 及桌面应用等。在这些能力输出的下层是我们沉淀的一套研发协作流程，从需求到开发、测试、交付、及发布后的反馈闭环。

支付宝业务的飞速发展，从工具到超级 App，代码量猛增到 300W+。技术架构上，采用了模块化动态加载的技术，这就给我们提了一个问题，如何将 300+ 个 Bundle，在不同的团队里开发，集成，变成一个高质量的 App 推送到用户手机上。
2. DevOps 三步工作法

DevOps 三步工作法，第一步，我们正向价值流建模，把研发划分为 5 个阶段（需求阶段、开发阶段、测试阶段、集成阶段以及发布阶段），定义每个阶段的准入准出标准。比如需求分析的结果需要拆分到 User Story 级别，通过大家需求评审，达成一致。接着，每个阶段我们提炼出最重要的活动，比如开发阶段，开发同学每天最多的就是写代码，代码 Review，以及代码 MR/Push 后触发的自动化流水线，如编译、扫描、自动化测试等。这些阶段和每个阶段的活动以及人员之间的协作，就构成了我们交付大图的脉络，即我们常说的价值流。

通过正向价值流的建模，结合团队的开发实践，便可以得到研发协作平台产品的一个信息架构图。
如上图所示，随时间演进，我们沉淀出了一套产品信息图：从最开始仅仅是安装包构建的一个在线工具，到产物管理，版本管理，架构拆分后的模块信息、模块构建管理，根据构建的产物及场景的不同，抽象出了构建配置、渠道配置、持续集成的配置，当然还有其它元数据如证书信息的配置。
我们参考了敏捷、Scrum 实践，抽象出迭代的概念来组织每个模块涉及的资源如代码仓库、需求、缺陷、任务、持续集成流水线还有最重要的团队和人员。发布定义了我们交付的产物，同时也是各团队工作集成到一起的大容器。

这是我们研发协作平台的门户首页，开发者能直观地看到自己关注项目的日常发布、迭代信息，以及每天需要解决的待办等，每个类目和我们上一页提炼的信息架构相对应。

拆解「依赖配置」

前面提到我们通过架构拆分，团队模块化协作的方式来应对激增的业务需求。那么之所以有这张截图，是想让大家对我们的依赖配置有个直观的感受，每个模块的产物可以理解为一个 Zip 包，在某一个安装包发布中管理这样由 300 多个 Bundle 构成的一个依赖列表。我们的需求集成某种意义上就是这个依赖列表中中模块版本的升级。模块拆分也让我们的小批量快速交付成为得以践行、拥有 2 周发布一个大版本的能力。

分支模型

需求管理我们可以借助 Jira、Redmine 等工具，或对接内部的项目管理平台。这里我直接从开发阶段的活动开始。
首先说下 MR，这是我们的分支模型：“基于分支开发，基于主干发布”。开发阶段基于 Master 创建迭代分支，基于迭代分支创建 Feature 分支通过 MR 方式在合并到迭代分支前，做一次 Code Review 卡点。集成阶段便可以直接基于 Master 分支创建 Bugfix 分支然后在 MR 回 Master 分支。发布阶段基于客户端版本创建 Tag。

1. 构建的定义与技术架构

接下来说说构建。我把构建定义为代码和配置经过构建工具和脚本在环境中执行而产生产物的过程。因此我们要关注这 4 个要素“代码、构建脚本、执行环境、产物管理”。代码和构建脚本由开发者提供，我们要帮忙管理的是环境和产物。比如 IoT 提个需求过来要支持他们的构建，其实就是给他们准备一个 Docker 镜像，定义好输入输出，把他们产物发布到 Maven 仓库或云存储中。

构建：技术架构

理解了构建的要素，技术架构也就很明确了，上面是我们支持的构建业务类型，调度是执行的核心能力，Docker 和 MacOS 是我们涉及的环境，借助 Jenkins 来连接这些执行机器。环境管理这块主要是 Docker，Windows 对 Docker 的支持也很好，我们的 IDE 构建就用的 Windows Docker。我们有 30 多台 Mac Pro，为了更好的管理，采用 Ansible 来做一些预置和软件升级的工作。

构建：Demo

这是我们的一次 Android 安装包构建，时间是 3 分钟，通过 Jenkins 的界面可以很直观的看到经历了那些步骤及耗费的时间，如果有错误也能很快定位到。
2. 自动化流水线架构设计

从构建的单项能力建设，慢慢扩展到了静态扫描、自动化测试、包大小检查，安全扫描等验证的需求。我们首先会想到持续集成流水线，我们调研了 Jenkins、Gitlab、Drone、CircleCI、TravisCI 等主流的 CI 工具，最终还是决定自研一套 CI 平台来连接公司内部的各个团队的验证服务。从这个架构图可以看出 CI 的内核是 Pipeline 流水线的定义与解析，验证执行，以及连接各服务的接入规约。上层是支持的业务类型，以及触发流水线的机制设定。
流水线也让我们不停的思考如何去更好的可视化，以及 DevOps 实践“三步工作法”中的逆向反馈设定。比如流水线编排时如何快速验证，分层分级验证，做到有效反馈。根据反馈再快速修复。

自动化流水线：列表 Demo

这是我们的持续集成列表页面，选择 IOT 新业务快速试错，将扫描和冒烟测试都展示给开发测试同学，这样对代码 Push 后的一个验证有个全局认识，然后他们便可以更好的局部节点优化，比如冒烟测试要获取什么样的报告。