部署更新

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

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

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

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.

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

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?

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

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

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

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

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"
    }
  }
}

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

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?

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.