部署更新

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

当你在生产环境中拥有具有多个二进制版本的应用时（这很常见 - 用户并不总是及时了解你最新的商店版本），了解哪些代码在哪些版本上运行以及能够使用修补程序专门针对特定版本非常重要。

¥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 Update 提供 "channels"、"branches" 和 "运行时版本"，帮助你确定要定位的应用版本，帮助你进行簿记以了解部署状态，并支持各种部署模式。

¥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.

What if my preferred release process isn't supported by EAS Update?

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

¥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 更新协议兼容的自己的更新服务，并将 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.

Why ignore branches in this release process?

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

¥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

渠道将指示更新针对哪个环境（例如 "production" 或 "staging"），运行时版本将指示更新将针对的应用版本（例如 "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" 配置文件。

¥If you use EAS Build, the default configuration that will be applied by the configure command, which is almost what we want to use here: each profile will point to a channel of the same name, so our production release of our app will point to the "production" channel. We only need to add a "staging" profile that points to the "staging" channel.

Example eas.json configuration

如果你尚未配置项目，以下配置大致是 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 可以帮助你充分利用产品，但这不是必需的。

¥If you do not use EAS Build, you will need to modify the channel used in your native project configuration. When you release to production, ensure you update the channel name in native config to "production", and when you release to staging, ensure you update the channel name in native config to "preview". It's worth noting that using EAS Build with EAS Update helps you get the best out of the product, but it is not required.

运行时版本策略

¥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).

Example app.json configuration

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

What about the fingerprint runtime version policy?

我们希望这将成为运行时版本策略的未来，但目前，我们建议使用 "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

如上所述，预览版本将指向 "preview" 通道。如果你希望在任何给定时间内部分发预览应用的多个版本，你可以根据功能名称更改渠道名称。例如，在处理功能 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 — 各自应用商店中的 "beta track"。你也可以使用内部分发，但当你为生产版本准备代码时，通常建议部署到商店测试版轨道，因为用户无需了解分发应用的内部流程即可访问它（而使用内部分发则需要用户从 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.

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

¥If you have already published the fix to staging and verified it there, ensure that you are republishing from the same commit.

对于此发布过程，我们建议在暂存区和生产区使用相同的环境变量和代码签名配置，以确保在暂存区验证的更新在生产中完全相同。如果这样做，那么你可以使用 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

创建新的生产版本时，我们建议增加 app 版本，以确保它对应用的每个版本都有唯一的运行时版本。

¥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

利用多个分支的部署不能用于此工作流程。我们正在为此寻找解决方案，但与此同时，你需要使用类似于分店促销流程的过程来逐步推出更新。

¥Rollouts that leverage multiple branches can't be used with this workflow. We're working on a solution for this, but in the meantime, you will need to use a process similar to the branch promotion flow to incrementally roll out updates.

在推出中了解更多信息。

¥Learn more in Rollouts.

路由参数

¥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

了解有关持久暂存发布过程的更多信息，与此处描述的非常相似。

¥Learn more about the Persistent staging release process, which is very similar to what is described here.
探索在开发版本中使用预览更新。

¥Explore using preview updates in development builds.