背景
最近我们要在一个新的 App 上增加热更新的能力，按照以往的设计思路，需要后台一起参与，并提供对应的接口，具体的接口如下：
| 接口 | 参数 | 返回值 | 备注 |
|---|---|---|---|
| uploadBasePkg | appVersion：App版本号；baseFile：基础包文件 | 上传基础包，发布流水线打包之后自动上传 | |
| uploadUpdatePkg | appVersion：要发布到的App版本；hotVersion：热更新版本号；updateFile：热更包 | 上传热更包，上传完成之后，需要与指定的基础包和该基础包的历史热更包生成diff文件 | |
| requestUpdate | appVersion：本地的App版本号；hotVersion：本地的热更新版本号；uin：用户id；platForm：系统（Android，iOS） | hasUpdate：true/false；updateFile：热更新文件下载地址；md5：校验；fileLength：文件长度；msg：热更新说明；HotVersion：热更新版本号；versionType：更新类型（1静默，2推荐，3强制） | 请求热更新，若有，则返回热更新配置，若无，则hasUpdate返回false |
相当于是把 diff 的计算放在后台，然后每次客户端请求后台去获取到对应的 diff 包，并在本地进行合并，就完成了一次热更新。可以参考：
Cocos热更新的非官方解决方案
这是个很好的解决方案，但是后台同学的工作量比较大，而当前后台的人力又比较紧张，因此在综合考量需求和现状之后，我们决定使用配置系统+流水线的方案来实现热更新的能力。
方案调研
当前我们 App 已经拥有配置系统的能力，可以根据系统，用户id，版本号等参数下发不同的配置，而热更新就是需要基于这些参数去获取到不同的 diff 包。
而生成 diff 包的能力，我们可以放到流水线上去执行，生成的产物自动上传到 cos，然后获取到下载链接，并组合成配置。我们拿到这个配置之后，就可以根据我们的需要，将其发布到对应的版本或者用户上了。
具体方案
流水线的流程如下图所示：
我们每次打包完，都需要将旧包保存。在生成 diff 包的流水线上，我们只需要输入升级分支，便可以生成 diff 包。diff 包包含两部分，分别是old.zip 和 new.zip 的差分文件，以及 update.manifest 文件，这个文件包含了 new.zip 的全部文件及其对应的 md5 值，可用于合并校验。
手机端的流程如下图所示：
其中，检查热更新是直接从配置系统获取最新的配置，然后和本地的热更新版本号进行对比，若配置系统的版本号高于本地的版本号，则需要进行热更新。
方案优缺点
| 优点 | 缺点 |
|---|---|
| 简单，不需要后台的介入 | 依赖于配置系统的能力，比较难实现一些个性化的需求；需要在流水线上进行一些开发 |