现在你的应用已经具备了检测更新的功能，下面我们来尝试发布并更新它。流程可参考下图：

流程总结如下：

1. 我们需要先打包一个原生 release 版本，在打包前请确保已集成了react-native-update并在调试过程中运行正常，安卓端关闭了crunchPngs设置，打包说明可参考iOS 打包 (opens in a new tab)和android 打包 (opens in a new tab)。打包完成后请使用pushy uploadIpa或者pushy uploadApk命令来把这个安装包上传到 pushy 服务器端，以作为之后热更差量对比的基准。同时请保留好这个安装包，上架和分发给用户所使用的安装包需要和服务器端完全一致。建议使用 git tag 功能来标记原生版本号（例如v1.0.0）。
2. 然后在基准版本之上迭代业务逻辑（增删 js 代码，增删图片等静态资源），使用pushy bundle命令来生成和发布热更新版本，而不需要重新打包。建议使用 git tag 功能来标记热更版本号（例如v1.0.1）。
3. 如果迭代过程中有原生方面的修改，则需要发布并上传新的原生基准版本（重复步骤 1，但需要设置不同的原生版本号）。可以只保留一个原生基准版本，也可以多版本同时维护。

发布原生基准版本

iOS

首先参考文档-在设备上运行 (opens in a new tab)，确定你正在使用离线包。然后点击菜单。

按照正常的发布流程打包.ipa文件：

1. Xcode 中运行设备选真机或 Generic iOS Device
2. 菜单中选择 Product - Archive
3. Archive 完成后选择Export生成.ipa 文件
4. 然后运行如下命令上传到 pushy 服务器以供后续版本比对之用

$ pushy uploadIpa <ipa后缀文件>

此 ipa 的CFBundleShortVersionString字段(位于ios/项目名/Info.plist中)会被记录为原生版本号packageVersion。

随后你可以选择往 AppStore 上传这个版本（可以重新 export 并调整相关选项，但请不要重新 archive），也可以先通过Test flight (opens in a new tab)或蒲公英 (opens in a new tab)等渠道进行真机安装测试。请注意：暂不支持通过 Xcode 直接进行热更新测试。

如果后续需要再次 archive 打包（例如修改原生代码或配置。如果只是修改 js 代码则不需要重新打包。），请先更改版本号，并在打包完成后再次uploadIpa到服务器端记录，否则后续生成的相同版本的原生包会由于编译时间戳不一致而无法获取热更新。

Android

首先参考文档-打包 APK (opens in a new tab)设置签名，然后在 android 文件夹下运行./gradlew assembleRelease或./gradlew aR，你就可以在android/app/build/outputs/apk/release/app-release.apk中找到你的应用包。

如果你需要使用 aab 格式（android app bundle，google 市场专用）的包，请参考这里的做法将其转换为 apk 格式后再操作。

然后运行如下命令

$ pushy uploadApk android/app/build/outputs/apk/release/app-release.apk

即可上传 apk 以供后续版本比对之用。此 apk 的versionName字段(位于android/app/build.gralde中)会被记录为原生版本号packageVersion。

随后你可以选择往应用市场发布这个版本，也可以先往设备上直接安装这个 apk 文件以进行测试。

如果后续需要再次打包（例如修改原生代码或配置。如果只是修改 js 代码则不需要重新打包。），请先更改版本号，并再次uploadApk到服务器端记录，否则后续生成的相同版本的原生包会由于编译时间戳不一致而无法获取热更新。

发布热更新版本

你可以尝试修改一行代码(譬如将版本一修改为版本二)，然后使用pushy bundle --platform <ios|android>命令来生成新的热更新版本。

import "expo-router/entry";

$ pushy bundle --platform android
Bundling with React Native version:  0.22.2
<各种进度输出>
Bundled saved to: build/output/android.1459850548545.ppk
Would you like to publish it?(Y/N)

如果想要立即上传，此时输入 Y。当然，你也可以在将来使用pushy publish --platform android build/output/android.1459850548545.ppk来上传刚才打包好的热更新包。

  Uploading [========================================================] 100% 0.0s
Enter version name: <输入热更新版本名字，如1.0.0-rc>
Enter description: <输入热更新版本描述>
Enter meta info: {"ok":1}
Ok.
Would you like to bind packages to this version?(Y/N)

此时版本已经提交到 pushy 服务，但用户暂时看不到此更新，你需要先将特定的原生包版本绑定到此热更新版本上。

此时输入 Y 立即绑定，你也可以在将来使用pushy update --platform <ios|android>来对已上传的热更包和原生包进行绑定。除此以外，你还可以在网页端操作，简单的将对应的原生包版本拖到需要的热更新版本下即可。

┌────────────┬──────────────────────────────────────┐
│ Package Id │               Version                │
├────────────┼──────────────────────────────────────┤
│   46272    │ 2.0(normal)                          │
├────────────┼──────────────────────────────────────┤
│   45577    │ 1.0(normal)                          │
└────────────┴──────────────────────────────────────┘
共 2 个包
输入原生包 id: 46272

版本绑定完毕后，服务器会在几秒内生成差量补丁，客户端就可以获取到更新了。

后续要继续发布新的热更新，只需反复执行pushy bundle命令即可，不需要重新打包。

恭喜你，至此为止，你已经完成了植入代码热更新的全部工作。

测试、发布与回滚

我们强烈建议您先发布一个测试包，再发布一个除了版本号以外均完全相同的正式包。

例如，假设我们有一个正式包，版本为1.6.0，那么可以修改版本号重新打包一个1001.6.0，以一个明显不太正常的版本号来标识它是一个测试版本，同时后几位相同，可以表明它和某个正式版本存在关联（内容/依赖一致）。

在每次往发布包发起热更新之前，先对测试包1001.6.0进行更新操作，基本测试通过之后，再在网页后台上将热更包重新绑定到正式包1.6.0上。如果在测试包中发现了重大问题，你就可以先进行修复，更新测试确认通过后再部署到正式线上环境。这样，可以最大程度的避免发生线上事故。

万一确实发生线上事故需要回滚的话，首先利用版本控制系统回滚代码到正常的状态，然后重新生成热更包并推送即可。