QCon 全球软件开发大会(北京站)门票 9 折倒计时 4 天,点击立减 ¥880 了解详情
写点什么

有赞移动热修复平台建设

2020 年 7 月 24 日

有赞移动热修复平台建设

一、背景

1.1 为什么要搭建热修复平台

随着公司的快速发展,需求的快速增加,App 迭代也越来越频繁,如果移动应用出现问题,不仅仅影响用户体验,还会影响公司口碑,甚至可能造成资损。需要快速修复线上问题,对比常规的开发流程而言,热修复更加灵活方便,优势很多:


  • 无需重新发版,实时高效修复 bug;

  • 用户无感知修复,无需下载新的版本,代价小;

  • 修复成功率高,能把损失降到最低;

  • 因此热修平台愈加重要,需要搭建一个高效,好用且安全的热修复平台。


1.2 思考

搭建热修复平台,首先要考虑热修方案的选择,但这不是本文的重点,我们这里不做过多讨论。目前有赞 Android 侧的热修是基于 Tinker 自建的后端服务 + Android SDK 实现的。


下图简要描述了热修的主要过程:



看似简单的流程,在多人开发团队中,其实存在很多问题:


  • 每次版本打包发布,如何保存基准包及 mapping 等文件用于后续热修生成补丁?

  • 热修代码的分支如何规范管理?

  • 如何构建补丁包,构建了如何保存 ?

  • 补丁包如何快速高效的本地验证 ?

  • 补丁发布策略,发布审批等

  • 补丁下发数据如何统计?

  • 针对特定用户怎么查询热修状态?

  • 热修出了问题怎么定责,怎么对热修代码追溯?


1.3 热修平台定义

针对以上问题,我们认为热修平台应具备以下特点:


  • 支持打包文件保存

  • 定义标准的热修分支规范

  • 支持补丁包的构建保存

  • 支持方便的本地验证测试

  • 支持权限审批

  • 支持补丁全量,灰度及条件发布

  • 支持热修状态查询,数据统计

  • 支持历史热修代码查看


二、热修复平台

2.1 写在前面

在后面介绍热修复平台的过程中,会多次提到 MBD 及 APUB,这里先做下说明,便于下文理解:


  • MBD(Mobile Build): 有赞的移动应用构建平台, 支持 App 构建, 热修构建及 SDK 构建。

  • APUB(App Publish): 应用及热修等发布平台,APUB 的上游为 MBD,承接了 CI 系统的产物。下游则是 C 端用户,作为应用发布生命周期的最后一环,为所有应用补全了热修复 和 灰度分发相关的能力。


同时为了讲清楚热修复平台,本文以 Android 为例按照热修过程,顺序介绍。


2.2 打包文件保存

Android 侧使用 Tinker 首先要考虑的是构建产物及 mapping 等文件的保存,用于后续打补丁包


由于有赞内部 App 发版构建, 热修构建,SDK 构建等都是通过 MBD 构建平台,且 MBD 本身已支持打包产物的自定义上传,因此借助 MBD 构建平台就可以做到保存 apk&mapping 文件。MBD 构建平台打包是在运行着 GitLabRunner 的黑苹果上进行的, GitLabRunnerGitLab 基于 Go 实现的脚本解释器,如果感兴趣可以自行了解下,这里不再展开。


App 使用 MBD 打包需要先指定打包脚本,脚本为 yaml 格式,其中 artifacts 指定哪些文件要上传到 CDN , 配置中的 paths 中指定了 Tinker 构建产物目录 bakApk&mapping ,因此 Tinker 产物会上传到 CDN, 脚本如下:


build:Git API    artifacts:        untracked: false        name: "out"        preview_pattern: "app-full-release.apk"        cdn_path: "xxxxxxxx"        paths:            - app/build/bakApk            - app/build/outputs/apk/            - app/build/outputs/mapping/full/release/    script:        - env        - ./gradlew clean assembleFullRelease -PTINKER_ID=$CI_BUILD_ID -PBAK_PATH=$CI_PROJECT_DIR/app/build/bakApk -Paar=$JOB_COMPONENT_DEPENDENCIES -PMBD_RELEASE=$JOB_BUILD_RELEASE -PMBD_TEST_VERSION=$JOB_COMPONENT_VERSION -PMBD_BRANCH_NAME=$CI_COMMIT_REF_NAME --no-daemon
复制代码


2.3 热修分支规范

MBD 操作拉取分支修复问题


移动团队达到一定规模后,需要同步制定相应的分支规范,其中热修相关的分支管理需要考虑两个问题:


1. 应该从哪个分支拉取代码修改打补丁?2. 修复问题后热修代码合并问题?
复制代码


这里有必要简单说明下:


有赞每次发版都会有开车的概念,所有待发布的功能都会上车合并到一个从 master 分支拉出的 bus/${version}-${date}的分支,在 bus/${version}-${date}分支打出包后,开发同学自测然后交由项目的测试回归,没问题后,最后经 App 的测试同学回归,回归通过后开发同学会将 bus/${version}-${date} 分支合入 master 构建 release 包。


由于考虑到也可能会拉分支对老版本发布热修,因此上述 MBD 构建成功后也会入库记录该 release版本构建时的 commit hash


基于以上两点我们规定每个 release版本都有一个固定的热修分支为 hotfix/${version}-mbd,热修分支的管理也是直接由 MBD 构建平台统一规范处理的如图所示:



MBD 构建平台每个 App 构建,热修构建,SDK 构建都是一个集成单(多次构建行为的集合,每次正式构建前都可能会有若干次测试构建),举例来说如 App2.3.5 版本发现问题需要热修复:



  1. 首先要在 MBD 构建平台搜索 2.3.5版本的 release集成单, release集成单中包含一个热修复按钮

  2. 点击热修复按钮判断 2.3.5 版本是否已经存在 hotfix/2.3.5-mbd 分支?

  3. 存在直接创建热修复集成单,不存在 MBD 平台调用 GitLabAPI 创建 hotfix/2.3.5-mbd 分支

  4. 开发者在 hotfix/2.3.5-mbd 拉取创建修改问题的分支,如 hotfix/xxx_bugfix


至此解决了 应该从哪个分支拉取代码修改打补丁? 的问题,合并到哪个分支的问题,暂且不表,下文会讲到。


2.4 补丁构建及保存

如上所述,热修构建也是在 MBD 平台完成的,由于之前 app 发版构建的产物已经打包


上传到了 CDN,再次构建时 MBD 平台只需把产物下载解压到 Tinker 基准包路径,


同 App 打包逻辑,热修构建也是通过 yaml脚本配置,指定要上传补丁文件的相对路径,补丁构建命令执行结束后会上传补丁文件到 CDN,用于后续补丁下发,简要过程如图:



补丁构建脚本


patch:    artifacts:        untracked: false        name: "patch"        preview_pattern: "patch_signed.apk"        paths:          - app/build/outputs/apk/full/tinkerPatch/full/release/patch_signed_7zip.apk          - app/build/outputs/apk/full/tinkerPatch/full/release/patch_signed.apk    script:        - env        - pwd        - mv app/build/bakApk base/        - ls base/        - ./gradlew clean tinkerPatchFullRelease -Paar=$JOB_COMPONENT_DEPENDENCIES --no-daemon -POLD_BUILD_FLAVOR=$CI_PROJECT_DIR/base        - rm -rf base
复制代码


2.5 验证热修

补丁上传到 CDN 后,为了确保下发的补丁没问题,需要验证补丁,这是至关重要的一步。那怎么加载补丁呢?Tinker 也提供了加载本地补丁包的 API


TinkerInstaller.onReceiveUpgradePatch(context, 补丁包的本地路径);
复制代码


因此我们只需要把 CDN 文件下载到特定路径,在 App 重启时检测补丁文件是否已下载,如果已下载直接加载补丁即可。


验证补丁首先要考虑怎么方便开发者使用,步骤越少越快越好,因为通常发布热修本身就是非常紧急的问题,由于有赞内部有移动助手 App(支持常用的开发功能,开发环境切换,抓包等) 移动同学都会使用,因此可以把热修验证功能放在移动助手 App。


从使用简便程度上来说,二维码似乎是不错的选择,因此我们定下的方案是,移动助手 App 扫码获取二维码信息,二维码中包含:


  1. 补丁 MD5 安全校验 、签名

  2. 补丁 CDN 地址

  3. 补丁对应 App 版本及基准包 CDN 地址

  4. 补丁对应 App 包名


其中第[3]点用于检测验证热修的手机当前安装的版本是否是基准包,如果不是提示下载安装补丁对应基准包版本,避免浪费时间。


第[4]点用于补丁合成后,根据包名重启 App,主要是考虑到 Tinker 的机制补丁本地合成后,需要再次冷启动使补丁生效。



移动助手 App 扫码上图中的二维码后,请求补丁信息,执行拉取补丁本地合成补丁,如果合成成功后被热修 App 启动后会看到热修合成成功页面,否则不能明确的知道是否已热修合成,开发者会比较迷惑,同时为了方便多次合成测试的场景,比如第一次补丁问题没有修复,需要再次合成,也支持了清除补丁功能。如图所示:




2.6 发布策略

验证补丁没问题后,需要根据情况选定发布策略,目前支持三种热修发布策略


2.6.1 全量发布

全量发布,不用解释,补丁对应版本 App 所有用户都可拉取补丁


2.6.2 灰度发布

灰度下发支持按人数灰度 与 按比例灰度,按照人数灰度相对简单,因此这里只说下按比例灰度,灰度如果按照总人数的百分比进行下发,有可能会下发到不活跃用户的设备上,让百分比下发失去意义。目前一个简单的方式是实现哈希碰撞算法,概率可调,当 App 端请求补丁时,根据设备的唯一标识进行碰撞,落到概率区间内则下发补丁。


2.6.3 条件发布

很多时候在发布一个补丁时,需要在小范围内进行验证,比如特定某个系统版本或者特定某个用户;在验证通过后再进行全网用户的下发,这中场景下可以使用条件下发。


Apub 平台在发布补丁时可以选择使用条件下发,除上传补丁外,还可以填写条件语句,只有满足条件的设备才会执行修复补丁。


其中条件语句由 key/value/运算符 组成,条件语句的规则与代码中的条件表达式一致,支持 “==、!=、>、<、>=、<=、&&、||” 等运算符,如:


userId == 10023451 && roleType == 1
复制代码


后端对 DSL 解析引擎可参考:https://developer.mozilla.org/zh-CN/docs/Mozilla/Projects/Rhino


另外特定版本的 App 可能会发布多个补丁,如果结合使用多种下发补丁也会遇到些新的问题,举例来说如果先条件发布了一个补丁,再全量发布了另一个补丁 App 应该怎么处理?因此制定了 App 补丁使用规则:


  • 若第一次下发补丁,包含了条件值,不符合条件的设备补丁不会生效。

  • 若非第一次下发补丁,上一个补丁版本是全量下发,不符合条件的设备会请求上一个版本补丁。

  • 若非第一次下发补丁,上一个补丁版本非全量下发(灰度/条件/开发),不符合条件的设备若之前请求过补丁,会保留执行之前的补丁,若没有请求过补丁(新用户),不会请求到补丁。


2.7 发布审批

在确定了补丁使用哪种发布方式后,还需要由指定人(通常为 TL)统一收敛权限,同时对热修代码做二次检查(Code review) ,有赞不会允许未经复核检验的热修代码随意的发布线上,万一出了问题,可能会影响大量用户。


对于有赞权限管理感兴趣读者的可以看这篇文章《有赞权限与审批流程的标准化》


引用上文中举的例子说明:如果 A 同学需要修改 App2.3.5 版本的问题,发布热修复。


  1. 开发者需要从 hotfix/2.3.5-mbd拉取 hotfix/xxx_bugfix 分支

  2. hotfix/xxx_bugfix分支修改问题并构建补丁

  3. 接着申请发布补丁,在审批通过之后,发布热修的同学在 Apub平台上操作下发在 MBD 平台构建并上传到 CDN的补丁


仔细想想,是不是遗漏了什么?还记得上文说到热修分支规范时,修复问题后热修代码的合并问题么?


为了避免开发者在修改问题后直接发布补丁,代码忘记合并导致后续版本也有问题的情况,同时也为了规范管理热修分支。如图:



  • Apub 发布平台在 A 发起审批时,自动创建了 hotfix/xxx_bugfix->hotfix/2.3.5-mbdMR 并自动写入审批单申请理由中。

  • A点击下发补丁时调用 GitLabAPI 获取 MR 状态,如果 MR 已合并则允许下发,否则提示 A 催促审批人合并代码才可下发补丁

  • 最后下次发版时将 hotfix/2.3.5-mbd 分支添加到下一趟发版列表中,将 bug 修复代码带到下一趟车中,最终合入 master


2.8 热修数据统计

补丁下发后,还需要实时观察热修生效情况,如果有问题要及时暂停下发或回滚补丁,有赞热修提供了基础的数据统计,包含已修复设备数量,合并失败错误统计等。



2.9 设备热修状态查询

在某些场景下,可能需要查询特定用户或特定用户账号的热修状态


常见的一种情况是:


用户反馈了个线上问题,开发同学确认问题并修改发布补丁后,悻悻的回复用户已经修复了,重复杀掉 App 打开几次即可。用户说好我试试,过了一段时间,又反馈说还是有问题啊,但是明明已经发布热修复了(头皮发麻),这时就可以根据用户账号信息查询热修状态了,如下图。



2.10 热修代码回溯

还有一些特殊情况,历史版本里发布的热修复导致了新的问题,需要确认问题责任人,或者排查特定问题,需要排除热修代码的影响,需要查看该版本发布的热修复代码。


针对该情况,我们把上文中发起审批时创建的 MR 落库记录,并提供了查看代码变更按钮,点击按钮直接跳转记录的 GitLabMR, 即可查看代码变更。


三、平台架构及流程

3.1 热修平台架构

上面讲的内容比较多也比较杂,可以结合热修平台架构图来看,有个全局的视角:



3.2 热修流程梳理

最后我们还以上文中的例子回顾下分享的内容,有赞发布热修复的流程:


Android 发布热修流程

  1. 开发者在 MBD 平台搜索需要热修版本的集成单,点击热修复按钮,MBD 会创建 hotfix/2.3.5-mbd 分支,同时创建一个热修集成单 (MBD 构建平台每个 App 构建,热修构建,SDK 构建都是一个集成单)

  2. 开发者需要从 hotfix/2.3.5-mbd拉取创建 hotfix/xxx_bugfix 分支

  3. hotfix/xxx_bugfix分支修改问题提交代码并在 MBD 平台创建的热修集成单上操作构建补丁

  4. 然后使用有赞移动助手 App 扫码验证补丁

  5. 接着在 Apub 发布平台选择热修发布方式,填写申请发布理由申请发布补丁,Apub 平台会自动创建 hotfix/xxx_bugfix -> hotfix/2.3.5-mbdMR,并把 MR地址自动填充到申请理由中,开发者等待审批,审批通过之后,确认 MR合并,即可发布操作下发补丁


iOS 发布热修流程

上文很少提及 iOS 热修复,主要是因为 iOS 热修相对简单,没有 Android 基准包等复杂逻辑:


  1. 根据具体问题,编写热修脚本,通过 iOS 热修 SDK,本地运行调试

  2. 调试通过后在 Apub 平台上传热修脚本,并选择热修发布方式,填写申请发布理由申请发布补丁,iOS 侧由于修复机制等原因,没有自动创建 MR 等逻辑

  3. 审批通过之后,即可下发补丁


四、总结

本文主要介绍了有赞的热修复平台,及在搭建过程中遇到的一些问题。热修平台实现了高效、稳定、可靠的热修复补丁上传、验证、分发、权限管理等功能,并提供补丁基本数据统计,可以直接复用到各业务线,避免重复建设。


有赞热修复平台,是结合有赞移动团队实际开发过程遇到的问题,逐步解决逐渐完善的,读者可以结合自身团队打造合适的热修复管理平台,希望有赞热修复平台的建设经验可以对你有所帮助。


如果你有比较好的建议,可以评论回复,如有任何问题,欢迎指正。


本文转载自公众号有赞 coder(ID:youzan_coder)。


原文链接


https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455761058&idx=1&sn=e7296c9a1e0f3e9a72fd4a0b8b246d06&chksm=8c687687bb1fff91faf37ca84044bb90a5ddbe55dd80bbccef30f361549ecf1f81364d9516ac&scene=27#wechat_redirect


2020 年 7 月 24 日 10:00911

评论

发布
暂无评论
发现更多内容

某大厂一位核心技术人员不小心泄漏的公司内部培训以及工作笔记内容,手慢无。

Java架构师迁哥

AI小白必读:深度学习、迁移学习、强化学习别再傻傻分不清

华为云开发者社区

人工智能 学习 迁移

工作五年,一年内我靠这系列java面试宝典从13K到大厂30K

Java成神之路

Java 程序员 面试 编程语言

因材施教,阿里腾讯大牛耗时7天,整理不同人群适合的面试题合集

小Q

Java 编程 程序员 架构 面试

一周信创舆情观察(9.14~9.20)

统小信uos

JAVA JDBC

Isuodut

跟着B站UP主小姐姐去华为坂田基地采访扫地僧

华为云开发者社区

华为 技术 大牛 扫地僧

SpringBoot-技术专题-提升服务吞吐量

李浩宇/Alex

框架设计:作业

Nick~毓

一文快速入门分库分表

程序员内点事

Java 分库分表

Git 操作

老菜鸟

git

Week 2 Assignment

Yinan

进击的无源光网络:产业园区里的“追光者”

脑极体

一个草根的日常杂碎(9月25日)

刘新吾

社会百态 生活随想 日常杂碎

架构师训练营 1 期第 2 周:框架设计 - 总结

piercebn

极客大学架构师训练营

四年开发经验从美团、360、陌陌、百度、阿里、京东面试回来感想

Java架构师迁哥

〈Java开发手册(嵩山版)〉灵魂15问,深究Java规约背后的原理

Java成神之路

Java 编程 程序员 面试 阿里

云小课 | 不小心删除了数据库,除了跑路还能咋办?

华为云开发者社区

数据库 数据恢复 dba

架构师训练营第 1 期第二周总结

Leo乐

极客大学架构师训练营

架构师训练营---第二周课后练习

Jacky.Chen

Rust所有者被修改了会发生什么?

袁承兴

rust 内存管理 智能指针

【FastDFS】小伙伴们说在CentOS 8服务器上搭建FastDFS环境总报错?

冰河

分布式存储 fastdfs

机构进场区块链安全基础设施准备好了么?

CECBC区块链专委会

区块链 数字资产

从『用户』到『客户』,企业服务平台如何实现高效转化?

易观大数据

架构师训练营 1 期 - 第二周 - 设计原则

三板斧

极客大学架构师训练营

SQL 如何做 Join

Rayjun

sql

为什么海外服务器打开网站会卡呢?

德胜网络-阳

来不及解释了,快上车!快速开发平台,助力企业搭乘万物互联顺风车

Philips

敏捷开发 企业开发 互联网革命

京东T8Java架构师分享Docker和Kubernetes开源书,PDF版免费下载

Java成神之路

Java Docker 程序员 面试 编程语言

腾讯数据库专家多年运维经验凝聚成简,总结这份595页工作笔记

周老师

Java 编程 程序员 架构 面试

关于招聘的一些思考

石云升

面试 考核 招聘 下放招聘权

边缘计算隔离技术的挑战与实践

边缘计算隔离技术的挑战与实践

有赞移动热修复平台建设-InfoQ