部署更新

了解一种简单但强大的流程，可安全地将更新部署给你的用户。

For the complete documentation index, see llms.txt. Use this Use this file to discover all available pages.

当你的应用在生产环境中有多个二进制版本时（这很常见——用户并不总会保持在你最新的商店发布版本上），了解哪些代码运行在哪些版本上，并且能够针对特定版本发布热修复，是非常重要的。

EAS Update 提供了“渠道”、“分支”和“运行时版本”，帮助你确定要针对哪个应用版本，也帮助你进行记录管理以了解各个部署的状态，并支持多种部署模式。

一个简单的发布流程

在本指南中，我们将描述一种简单但强大的发布流程，它使用 渠道 和 运行时版本，并且大多忽略 分支。这以最少的概念负担带来了 EAS Update 的大部分优势。随着需求的出现，你可以逐步演进这个流程以适应你的需要，或者转向其他部署模式。

配置你的项目

渠道将指示更新针对哪个环境（例如“production”或“staging”），而运行时版本将指示更新将针对哪个应用版本（例如“1.0.0”或“1.0.1”）。

渠道配置

如果你还没有这样做，请在你的项目中运行 eas update:configure。

如果你使用 EAS Build，配置命令将应用默认配置，这几乎正是我们在这里想要使用的：每个配置文件都会指向同名渠道，因此我们应用的生产发布将指向“production”渠道。我们只需要添加一个指向“staging”渠道的“staging”配置文件。

{
  "build": {
    "production": {
      "channel": "production"
    },
    "staging": {
      "channel": "staging"
    },
    "preview": {
      "channel": "preview",
      "distribution": "internal"
    }
  }
}

如果你不使用 EAS Build，你需要修改 原生项目配置 中使用的渠道。当你发布到生产环境时，确保将原生配置中的渠道名称更新为“production”；当你发布到 staging 时，确保将原生配置中的渠道名称更新为“preview”。值得注意的是，使用 EAS Build 配合 EAS Update 能帮助你充分发挥该产品的优势，但这并不是必需的。

运行时版本配置

默认情况下，eas update:configure 会在你的应用配置中设置 "runtimeVersion": { "policy": "appVersion" }。这是推荐的配置，它将确保你的应用运行时版本始终与应用版本相同，并且你为应用的每次发布都有一个唯一的运行时版本可供针对。在这种情况下，应用版本指的是用户会在应用商店中看到的应用原生版本，不包括构建号或版本代码。例如："1.0.0" 将被用作运行时版本，而不是 "1.0.0(1)"（其中 1 是构建号或版本代码）。

{
  "expo": {
    "runtimeVersion": {
      "policy": "appVersion"
    }
  }
}

部署预览

你可以在内部发布构建或开发构建中预览更新。使用内部发布而不是部署到商店测试通道，可以降低将应用分发给内部测试者的阻力，并适用于例如你希望在每个拉取请求中共享一个构建，或者共享你正在开发的早期概念等场景。

内部发布构建

如上所述，预览构建将指向“preview”渠道。如果你希望在任意时刻内部分发多个预览应用版本，你可以根据功能名称更改渠道名称。例如，在开发功能 A 时，你可以将构建的渠道设置为“preview-feature-a”，在开发功能 B 时，则设置为“preview-feature-b”。

在开发构建中预览

只要运行时版本兼容，开发构建可以从任何渠道加载更新。了解更多请参见预览更新。

部署到 staging

运行 eas update --channel staging 将更新发布到 staging。这会让你的热修复立即对具有目标运行时版本的 staging 构建用户可用。

你的 staging 环境将是 Google Play Beta 或 TestFlight — 即相应应用商店中的“beta 通道”。你也可以使用内部发布，但当你为生产发布准备代码时，通常更推荐将其部署到商店测试通道，因为用户无需了解应用分发的内部流程即可访问它（而使用内部发布则要求用户从 expo.dev URL 下载应用）。

创建 staging 构建的一种常见做法是，每当你将生产构建上传到商店时，都同时创建一个 staging 构建。这样你就可以拥有一个与生产构建运行时完全相同的 staging 构建，并在将更新推向生产之前用它来测试更新。使用 EAS Build 时，这意味着每次运行 eas build --profile production --auto-submit 时，都运行一次 eas build --profile staging --auto-submit。

部署到生产环境

运行 eas update --channel production 将打包并推送一个新的更新到生产环境。这会让你的热修复立即对具有相同运行时版本的生产构建用户可用。

如果你已经将修复发布到 staging 并在那里验证通过，请确保你是从同一个提交重新发布的。

对于这个发布流程，我们建议在 staging 和 production 上使用相同的环境变量和代码签名配置，以确保在 staging 中验证通过的更新在 production 中表现完全一致。如果这样做，那么你可以使用 eas update:republish --destination-channel production 来提升该更新，而不是生成一个新的更新。这将确保你在 staging 中测试过的完全相同的 bundle 被用于生产环境。

运行 eas update --channel production 将更新发布到生产环境。这会让你的热修复立即对具有相同运行时版本的生产构建用户可用。

运行时版本

在创建新的生产构建时，我们建议递增你的应用版本，以确保每次应用发布都拥有唯一的运行时版本。

逐步推出更新

你可以使用按更新逐步推出将更新逐步部署给越来越多的用户。例如：eas update --rollout-percentage 10 会将更新推送给 10% 的用户，你也可以稍后使用 eas update:edit 来编辑推出百分比。了解更多请参见逐步推出。

回滚到之前的更新版本

如果你不小心向任何环境发布了更新，可以运行 eas update:rollback 发起回滚到之前的更新。

了解更多请参见回滚。

下一步

• 了解更多关于持久化预发布发布流程，这与此处所述非常相似。
• 探索在开发构建中使用预览更新。