部署更新

了解一个简单但功能强大的过程，可以安全地将更新部署给你的用户。

当你的应用在生产环境中有多个二进制版本时（这种情况很常见——用户并不总是会更新到你最新的商店版本），理解每个版本运行的代码以及能够针对特定版本进行热修复是很重要的。

🌐 When you have an app with multiple binary versions in production (this is common — users do not always stay up to date with your latest store release), it's important to understand what code is running on which versions and to be able to specifically target a particular version with a hotfix.

EAS 更新提供“渠道”、“分支”和“运行时版本”，帮助你确定要针对的应用版本，辅助记账以了解部署状态，并支持各种部署模式。

🌐 EAS Update provides "channels", "branches", and "runtime versions" to help you determine which app version to target, to help you with bookkeeping to understand the state of your deployments, and to support a variety of deployment patterns.

如果我偏好的发布流程不受 EAS Update 支持怎么办？

发布管理是软件工程中的一个大话题，每个人对于如何进行发布管理都有略微不同的看法。EAS Update 旨在支持多种不同的工作流程，但本指南将重点介绍适用于大多数应用的最简单的工作流程。话虽如此，还有一些其他工作流程可能无法在 EAS Update 服务的限制内运作。例如，每个二进制版本必须始终指向一个单一的渠道，并且你不能动态更新渠道。

🌐 Release management is a large topic in software engineering, and everyone has a slightly different take on how they would like to do it. EAS Update is designed to support a variety of different workflows, but this guide will focus on the simplest workflow that works for most apps. That said, there are some other workflows that may not work within the constraints of the EAS Update service. For example, each binary version must always point to a single channel, and you cannot dynamically update the channel.

作为一种应急方案，你可以托管自己的更新服务，该服务与 Expo Updates Protocol 兼容，并将你的 expo-updates 配置指向该服务。协议级别上与更新选择相关的唯一概念是“运行时版本”和“平台”，你可以在这些概念之上自由创建自己的概念，就像我们构建渠道和分支的方式一样。了解有关创建自定义 expo-updates 服务器的更多信息。

🌐 As an escape hatch, you can host your own update service that is compatible with the Expo Updates Protocol and point your expo-updates configuration to that service instead. The only concepts relevant to update selection that exist on the protocol level are "Runtime Version" and "Platform", and you are free to create your own concepts on top of those in the same way we built channels and branches. Learn more about creating a custom expo-updates server.

一个简单的发布流程

🌐 A simple release process

在本指南中，我们将介绍一个简单但强大的发布流程，该流程使用渠道和运行时版本，并且大部分情况下忽略_分支_。这样可以在最小的概念负担下获得 EAS Update 的大部分好处。你可以根据实际需求逐步调整这一流程，或者转向其他部署模式。

🌐 In this guide, we'll describe a simple but powerful release process that uses channels and runtime versions, and mostly ignores branches. This gives most of the benefits of EAS Update with a minimal amount of conceptual overhead. You can evolve this process to suit your needs as they arise, or move to other deployment patterns.

为什么在此发布过程中忽略分支？

使用 EAS Update 最简单的方法是忽略“分支”的概念，专注于“通道”。分支仍然存在，但你不必直接与它们交互来管理部署。你可以将通道指向与通道同名的分支，并将它们视为一个单一的概念。

🌐 The most simple way to use EAS Update is to ignore the concept of "branches" and focus on "channels". Branches will still exist, but you will not have to interact with them directly to manage deployments. You can keep your channels pointed at a branch with the same name as the channel and think of them as a singular concept.

EAS 更新分支旨在映射到 Git 分支，并使团队能够将 Git 分支的更改直接发布到同名的 EAS 更新分支。这对于预览更新可能很有帮助，但对于许多应用来说，这种与 Git 的集成程度并非必需。通常，开发者只是希望能够手动将热修复发布到应用的临时或生产版本，并可以在需要时运行 eas update --channel staging 或 eas update --channel production，而无需通过管理分支来实现相同的结果。

🌐 EAS Update branches were meant to map to Git branches and enable teams to publish changes from a Git branch directly to an EAS Update branch of the same name. This can be helpful for previewing updates, but for many apps, this level of integration with Git is not required. Often, developers are only interested in being able to release hotfixes to a staging or production version of their app manually, and can run eas update --channel staging or eas update --channel production, when needed rather than managing branches to accomplish the same result.

配置你的项目

🌐 Configuring your project

渠道将指示更新所针对的环境（例如“生产”或“测试”），而运行时版本将指示更新所针对的应用版本（例如“1.0.0”或“1.0.1”）。

🌐 Channels will indicate which environment the update targets (such as "production" or "staging"), and runtime versions will indicate the app version that the update will target (such as "1.0.0" or "1.0.1").

通道配置

🌐 Channel configuration

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

🌐 Run eas update:configure in your project if you haven't already.

如果你使用 EAS Build，configure 命令将应用的默认配置几乎就是我们这里想要使用的：每个配置文件都会指向同名的通道，所以我们应用的生产版本将指向“production”通道。我们只需要添加一个指向“staging”通道的“staging”配置文件。

示例 eas.json 配置

以下配置大致是 eas update:configure 会为你生成的内容，如果你还没有配置你的项目的话。

🌐 The following configuration is approximately what eas update:configure will generate for you if you haven't already configured your project.

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

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

运行时版本配置

🌐 Runtime version configuration

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

🌐 By default, eas update:configure will set "runtimeVersion": { "policy": "appVersion" } in your app config. This is the recommended configuration, it will ensure that the runtime version of your app is always the same as the app version, and you have a unique runtime version to target for every release of your app. In this case, the app version refers to the native version of your app that users will see on the app store, and it does not include the build number or version code. For example: "1.0.0" will be used as the runtime version, and not "1.0.0(1)" (where 1 is the build number or version code).

示例 app.json 配置

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

指纹运行时版本策略怎么样？

我们希望这将成为运行时版本策略的未来，但目前我们建议使用 "appVersion" 策略。"fingerprint" 策略仍处于实验阶段，目前尚不广泛推荐。

🌐 We hope that this will be the future of runtime version policies, but for now, we recommend using the "appVersion" policy. The "fingerprint" policy is experimental and not yet widely recommended.

部署预览

🌐 Deploying previews

你可以在内部分发的发布版本或开发版本中预览更新。使用内部分发而不是部署到商店测试版渠道，可以减少向内部测试人员分发应用的困难，适用于例如在每个拉取请求上共享构建版本或你正在开发的早期概念的情况。

🌐 You can preview updates in your internal distribution release builds or in development builds. Using internal distribution instead of deploying to a store beta track reduces the friction of distributing the app to internal testers, and is suitable for cases where you want to, for example, share a build on every pull request or an early concept that you're working on.

内部发布构建版本

🌐 Internal distribution release builds

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

🌐 As explained above, preview builds will point to the "preview" channel. If you want multiple versions of the preview app distributed internally at any given time, you can change the channel name based on the feature name. For example, you might set your channel on your build to "preview-feature-a" when working on feature A, and then set it to "preview-feature-b" when working on feature B.

在开发构建中预览

🌐 Preview in development builds

开发版本可以从任何渠道加载更新，前提是运行时版本兼容。有关详细信息，请参阅预览更新。

🌐 Development builds can load updates from any channel, provided the runtime version is compatible. Learn more about this in Previewing updates.

部署到预发布环境

🌐 Deploying to staging

运行 eas update --channel staging 以发布更新到预发布环境。这将使使用目标运行时版本的预发布构建用户立即可以使用你的热修复。

🌐 Run eas update --channel staging to publish an update to staging. This will make your hotfix immediately available to users of staging builds with the targeted runtime version.

你的预发布环境将是 Google Play Beta 或 TestFlight —— 即各自应用商店的“测试版通道”。你也可以选择内部分发，但在为生产发布进行代码预发布时，通常建议将应用部署到商店的测试版通道，因为用户无需了解内部分发流程即可访问应用（而使用内部分发则需要用户从 expo.dev URL 下载应用）。

🌐 Your staging environment will be Google Play Beta or TestFlight — the "beta track" on respective app stores. You may alternatively use internal distribution, but deploying to a store beta track is generally recommended when you are staging code for a production release since users are able to access it without any knowledge of internal processes for distributing the app (while using internal distribution would require users to download the app from an expo.dev URL).

创建预发布版本的一个常见做法是每次将生产版本上传到应用商店时，都创建一个预发布版本。这使你可以拥有一个与生产版本运行时完全相同的预发布版本，用于在将更新推送到生产环境之前进行测试。使用 EAS Build，这意味着每次运行 eas build --profile production --auto-submit 时都要运行 eas build --profile staging --auto-submit。

🌐 A common practice for creating staging builds is to always create one whenever you upload a production build to a store. This allows you to have a staging build with an identical runtime to the production build, which you can use to test your updates before rolling them out to production. With EAS Build, this means running eas build --profile staging --auto-submit every time you run eas build --profile production --auto-submit.

部署到生产环境

🌐 Deploying to production

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

🌐 Run eas update --channel production to bundle and push a new update to production. This will make your hotfix immediately available to production build users with the same runtime version.

如果你已经将修复发布到暂存环境并在那里进行了验证，请确保你是从同一提交重新发布的。

对于此发布过程，我们建议在预发布环境（staging）中使用与生产环境相同的环境变量和代码签名配置，以确保在预发布环境中验证的更新在生产环境中完全相同。如果这样做，那么你可以使用 eas update:republish --destination-channel production 来推广更新，而不是生成一个新的更新。这将确保在预发布环境中测试的完全相同的包被用于生产环境。

🌐 For this release process we recommend using identical environment variables and code signing configuration on staging as on production, to ensure that updates verified in staging work exactly the same in production. If do this, then you can eas update:republish --destination-channel production to promote the update rather than generating a new one. This will ensure the exact same bundle that you tested in staging is used in production.

运行 eas update --channel production 将更新发布到生产环境。这将使使用相同运行时版本的生产版本用户立即获得你的热修复。

🌐 Run eas update --channel production to publish an update to production. This will make your hotfix immediately available to users of production builds with the same runtime version.

运行时版本

🌐 Runtime versions

在创建新的生产版本时，我们建议增加你的应用版本，以确保每个应用发布都有一个独特的运行时版本。

🌐 When creating a new production build, we recommend incrementing your app version to ensure it has a unique runtime version for each release of your app.

逐步推出更新

🌐 Gradually rolling out updates

你可以使用按更新分批推出功能，逐步向越来越多的用户部署更新。例如：eas update --rollout-percentage 10 将向 10% 的用户推出更新，你之后可以使用 eas update:edit 编辑推出的百分比。详情请参阅分批推出。

🌐 You can use per-update rollouts to deploy updates gradually to an increasing percentage of users. For example: eas update --rollout-percentage 10 will roll out the update to 10% of users, and you can use eas update:edit to edit the rollout percentage later. Learn more in Rollouts.

还有哪些类型的推广方式？

另一种类型的部署被称为“基于分支的部署”。这需要一种以更新分支为核心的部署策略，而我们在本指南中没有使用这种策略，并且对于大多数使用场景来说也不是必需的。

🌐 Another type of rollout is called "branch-based rollouts". These require a deployment strategy focused around update branches, which we are not using in this guide and are not required for most use cases.

每次更新发布与基于分支的发布之间的区别在于，每次更新发布针对单个更新进行操作（ID 为 123 的更新将向 production 通道/分支的 10% 用户推出），而基于分支的发布则会通过切换到不同的分支（即一系列更新）来进行发布（分支 hotfix-123 将向 production 通道的 10% 用户推出，且 hotfix-123 可以指向更新 ID 123 或 124）。

🌐 The distinction between per-update rollouts and branch-based rollouts is that per-update rollouts operate on a single update (update with ID 123 will be rolled out to 10% of users on the production channel/branch), whereas branch-based rollouts will roll out switching over to a different branch (which is a stream of updates) (branch hotfix-123 will be rolled out to 10% of users on the production channel, and hotfix-123 can point to update ID 123 or 124).

路由参数

🌐 Rolling back to a previous update version

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

🌐 If you've mistakenly published an update to any of your environments, you can run eas update:rollback initiate a rollback to a previous update.

在回滚中了解更多信息。

🌐 Learn more in Rollbacks.

下一步

🌐 Next steps

了解有关持久预发布版本流程的更多信息，这与此处描述的非常相似。
在开发版本中探索使用预览更新。