传统的研发模式已经无法适应企业在数字化转型中快速迭代以及研发协同的要求，建设符合业务场景特性和有效支撑高并发、持续迭代集成需求的研发效能实践迫在眉睫。
本文将围绕支付宝如何随着移动市场的高速发展，逐步沉淀优化出适用业务发展需求的研发效能实践。
大家好，我是来自支付宝终端工程技术团队的十境。本文将带领大家了解支付宝移动端如何随着移动市场的告诉发展，逐步沉淀优化出适用业务发展需求的研发效能实践。
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 后的一个验证有个全局认识，然后他们便可以更好的局部节点优化，比如冒烟测试要获取什么样的报告。
- 自动化流水线：示例 Demo
这是一条流水线的详情页面，点击每个节点可以看到执行的状态和产物信息，依赖信息等。每个节点也可以选择跳过执行，或选择从失败节点重新运行，满足业务接入流水线不同阶段的使用场景。
3. 发布：健康度
接下来再介绍一些我们内部灰度发布的一些质量指标设计。这是我们在集成过后经历内灰、外灰、发布的界面，每个阶段我们会聚合各种质量和反馈信息，来帮助我们去推进每个阶段。
- 发布质量分数
这是发布质量的一个概要信息，及灰度情况。质量分的曲线能很好的配合我们工作的节奏。虽然刚开始质量分非常难以设计，不容易全面并准确衡量，但质量分一定要有，然后不停地迭代。刚开始可以参考 Sonar 的 Quality Gates 和它的质量维度来设计。
- 发布：质量维度
这是我们质量维度的设计，供大家参考一下。
3. 总结
最后简单总结，以上内容首先介绍了支付宝客户端研发的现状，通过 DevOps “三步工作法” 第一步正向建模工作流，梳理了需求、开发、测试、集成、发布这 5 个阶段及每个阶段的重要活动，形成价值流动的脉络图，并参考敏捷开发实践来组织我们的产品信息架构。然后重点讲述了我们的构建和持续集成流水线的设计与实现，通过流水线编排、发布阶段质量分的设计来实践 “三步工作法”的逆向反馈机制。 三步工作法。第三步持续学习和改进可以基于前 2 步的来达成。
以上介绍的支付宝移动研发 DevOps 落地实践，目前已经通过移动开发平台 mPaaS 对外输出一部分能力。
通过 mPaaS，我们针对移动端产品的研发管理，能够从产品需求准备，研发，构建，验证到集成等多个项目阶段，充分节约管理成本，提升研发效率。
随着软件研发的模式由传统的瀑布式开发逐步向敏捷开发和 DevOps 演进，变得愈来愈自动化和智能化，研发、测试、发布统一完成线上化和流程化将全面提升研发协同效率，并给企业带来更多的业务价值。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
