VPS做镜像网站,北京 网站建设托管公司,免费做做网站,网站开发包括软件吗传统的研发模式已经无法适应企业在数字化转型中快速迭代以及研发协同的要求#xff0c;建设符合业务场景特性和有效支撑高并发、持续迭代集成需求的研发效能实践迫在眉睫。 本文将围绕支付宝如何随着移动市场的高速发展#xff0c;逐步沉淀优化出适用业务发展需求的研发效能实… 传统的研发模式已经无法适应企业在数字化转型中快速迭代以及研发协同的要求建设符合业务场景特性和有效支撑高并发、持续迭代集成需求的研发效能实践迫在眉睫。 本文将围绕支付宝如何随着移动市场的高速发展逐步沉淀优化出适用业务发展需求的研发效能实践。 大家好我是来自支付宝终端工程技术团队的十境。本文将带领大家了解支付宝移动端如何随着移动市场的告诉发展逐步沉淀优化出适用业务发展需求的研发效能实践。
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 来连接这些执行机器。环境管理这块主要是 DockerWindows 对 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 演进变得愈来愈自动化和智能化研发、测试、发布统一完成线上化和流程化将全面提升研发协同效率并给企业带来更多的业务价值。
原文链接 本文为云栖社区原创内容未经允许不得转载。