打包发布机制详解

此部分逻辑对用户而言是黑盒，如果无特殊需要，用户无需了解打包平台是如何将资源打成QP 包并上传至服务器，只需了解如何使用测试 QP 包即可。

QP包的打包设计到三个平台的交互，分别是发布平台（MD开发者平台，调度作用），Portal打包平台（负责调用打包脚本打出QP包）和 QP Server 更新服务器（将 QP 包上传至服务器），具体逻辑如下。

几个关键点：

① 开发填写必须的版本信息和资源信息，交由发布平台，对于灰度和全量而言，信息指的是发布平台保存的，用户发布 Beta 时所填写的版本和资源信息。

② 发布平台将参数整合后，交由 Portal 打包平台进行打包。

③ Portal 平台会根据 HY / QRN / YIS 的不同，调用不同的发布脚本，进行打包。其中，打包脚本会通过调用 QP Server 来获取当前最新版本号，将版本号打入 QP 包中。

④ 发布平台获取到 Portal 的打包结果后，将结果进行存库，并且调用更新服务器的发布接口，更新服务器会读取 QP 包中的版本信息，并且将 QP 包上传至差分服务器。

⑤ 对于 QRN 项目，在发布全量时，还会额外的将打包产生的bundle文件上传至JsBundle服务器，以应对 QP 包因各种原因下载不到走线上的情况。

⑥ 对于 QRN / YIS 这种资源类型为 git 的QP包，在打 Beta 包时，会由输入的分支名打出 btag，发灰度时会由 btag 打出 rxtag，发全量时由 rxtag 打出 rtag 并且合并 master 分支。在重复发灰度时，由于输入是 rxtag， 不会重新进行打包，因此版本号也不会加一，即仅第一次发灰度时版本号加一，再次发灰度版本号时保持上次灰度版本。

⑦ 对于 HY 这种远程资源项目，没有打 tag 的步骤，每次都是由输入的远程地址进行打包。

⑧ 客户端在请求 QP 时，会请求更新服务器获取最新的 QP 包差分地址，差分服务器会根据客户端当前版本和要下载版本的diff结果获取到两个版本之间的差分包。