部署模式

了解使用 EAS 更新时项目的不同部署模式。

一旦我们在应用中创建了功能并修复了错误，我们希望尽可能快速、安全地向用户提供这些功能和错误修复。在向用户交付代码时，"safe" 和 "fast" 通常是对立的力量。我们可以将代码直接推送到生产环境，这会更快但安全性较差，因为我们从未测试过我们的代码。另一方面，我们可以进行测试构建，与 QA 团队共享它们，并定期发布它们，这会更安全，但向用户交付更改的速度会更慢。

¥Once we've created features and fixed bugs in our app, we want to deliver those features and bug fixes to our users as quickly and safely as we can. Often "safe" and "fast" are opposing forces when delivering code to our users. We could push our code directly to production, which would be fast yet less safe since we never tested our code. On the other hand, we could make test builds, share them with a QA team, and release them periodically, which would be safer but slower to deliver changes to our users.

根据你的项目，在向用户提供更新时，你需要对 "fast" 和 "safe" 的方式有一定的容忍度。

¥Depending on your project, you'll have some tolerance for how "fast" and how "safe" you'll need to be when delivering updates to your users.

设计 EAS 更新部署流程时需要考虑三个部分：

¥There are three parts to consider when designing the EAS Update deployment process:

创建构建

¥Creating builds
- （a）我们只能创建仅供生产使用的版本。
  
  ¥(a) We can create builds for production use only.
- (b)我们可以创建用于生产用途的构建，并为生产前变更测试创建单独的构建。
  
  ¥(b) We can create builds for production use and separate builds for pre-production change testing.
测试变更

¥Testing changes
- （a）我们可以使用 TestFlight 和 Play Store Internal Track 来测试更改。
  
  ¥(a) We can test changes with TestFlight and Play Store Internal Track.
- (b)我们可以通过内部发行版构建来测试更改。
  
  ¥(b) We can test changes with an internal distribution build.
- （c）我们可以使用 Expo Go 或开发构建来测试更改。
  
  ¥(c) We can test changes with Expo Go or a development build.
发布更新

¥Publishing updates
- （a）我们可以将更新发布到单个分支。
  
  ¥(a) We can publish updates to a single branch.
- (b)我们可以创建基于环境的更新分支，例如 "production" 和 "staging"。
  
  ¥(b) We can create update branches that are environment-based, like "production" and "staging".
- （c）我们可以创建基于版本的更新分支，例如 "版本-1.0"，这使我们能够将更新从一个渠道推广到另一个渠道。
  
  ¥(c) We can create update branches that are version-based, like "version-1.0", which enables us to promote updates from one channel to another.

我们可以混合、匹配和调整上述部分，为我们的团队和用户创建一个在发布节奏和安全性之间取得适当平衡的流程。

¥We can mix, match, and tweak the parts above to create a process that is the right balance of release cadence and safety for our team and users.

另一个需要考虑的权衡是我们在整个过程中必须做的版本/名称/环境的簿记量。我们要做的簿记工作越少，就越容易遵循一致的流程。它还将使我们与同事的沟通变得更加容易。如果我们需要细粒度的控制，就需要簿记来获得我们想要的精确流程。

¥Another trade-off to consider is the amount of bookkeeping of versions/names/environments we'll have to do throughout the process. The less bookkeeping we have to do will make it easier to follow a consistent process. It'll also make it easier to communicate with our colleagues. If we need fine-grained control, bookkeeping will be required to get the exact process we want.

下面，我们概述了有关如何使用 EAS 更新部署项目的四种常见模式。

¥Below, we've outlined four common patterns on how to deploy a project using EAS Update.

两条命令流程

¥Two-command flow

此流程是最简单、最快的流程，安全检查量也最少。它非常适合尝试 Expo 和小型项目。以下是构成此流程的上述部署过程的部分：

¥This flow is the simplest and fastest flow, with the fewest amount of safety checks. It's great for trying out Expo and for smaller projects. Here are the parts of the deployment process above that make up this flow:

创建构建：（a）创建仅供生产使用的版本。

¥Creating builds: (a) Create builds for production use only.

测试变化：（c）使用 Expo Go 或开发构建测试更改。

¥Testing changes: (c) Test changes with Expo Go or a development build.

发布更新：（a）发布到单个分支。

¥Publishing updates: (a) Publish to a single branch.

流程图

¥Diagram of flow

流程说明

¥Explanation of flow

在本地开发项目并在开发版本或 Expo Go 中测试更改。

¥Develop a project locally and test changes in a development build or in Expo Go.
运行 eas build 创建构建，然后将它们提交到应用商店。这些版本供公众使用，应提交/审核并在应用商店上发布。

¥Run eas build to create builds, then submit them to app stores. These builds are for public use and should be submitted/reviewed, and released on the app stores.
当我们有想要提供的更新时，请运行 eas update --branch production 以立即向我们的用户提供更新。

¥When we have updates we'd like to deliver, run eas update --branch production to deliver updates to our users immediately.

该流程的优点

¥Advantages of this flow

此流程不需要记录额外的版本或环境名称，这使得与其他人交流变得容易。

¥This flow does not require bookkeeping extra version or environment names, which makes it easy to communicate to others.
向构建提供更新的速度非常快。

¥Delivering updates to builds is very fast.

此流程的缺点

¥Disadvantages of this flow

没有预生产检查来确保代码按预期运行。我们可以使用 Expo Go 或开发构建进行测试，但这不如专用测试环境安全。

¥There are no pre-production checks to make sure the code will function as intended. We can test with Expo Go or a development build, but this is less safe than having a dedicated test environment.

持续的分期流程

¥Persistent staging flow

此流程就像 "分店促销流程" 的未版本化变体。我们不跟踪分支的发行版本。相反，我们将拥有可以永久合并的持久 "staging" 和 "production" 分支。以下是构成此流程的上述部署过程的部分：

¥This flow is like an un-versioned variant of the "branch promotion flow". We do not track release versions with branches. Instead, we'll have persistent "staging" and "production" branches that we can merge into forever. Here are the parts of the deployment process above that make up this flow:

创建构建：(b)创建用于生产的构建和单独的测试构建。

¥Creating builds: (b) Create builds for production and separate builds for testing.

测试变化：（a）在 TestFlight 和 Play Store 内部轨道上测试更改和/或 (b) 使用内部发行版测试更改。

¥Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.

发布更新：(b)创建基于环境的更新分支，例如 "staging" 和 "production"。

¥Publishing updates: (b) Create update branches that are environment-based, like "staging" and "production".

流程图

¥Diagram of flow

流程说明

¥Explanation of flow

在本地开发一个项目并在 Expo Go 中测试更改。

¥Develop a project locally and test changes in Expo Go.
使用名为 "production" 的渠道创建版本，最终将接受审核并在应用商店上提供。使用名为 "staging" 的通道创建另一组构建，该版本将用于在 TestFlight 和 Play Store Internal Track 上进行测试。

¥Create builds with channels named "production", which will eventually get reviewed and become available on app stores. Create another set of builds with channels named "staging", which will be used for testing on TestFlight and the Play Store Internal Track.
设置 expo-github-action 在合并提交到分支时发布更新。

¥Set up expo-github-action to publish updates when merging commits to branches.
将更改合并到名为 "staging" 的分支中。GitHub Action 将发布更新并使其在我们的测试版本中可用。

¥Merge changes into a branch named "staging". The GitHub Action will publish an update and make it available on our test builds.
准备好后，将更改合并到 "production" 分支以发布对我们的生产版本的更新。

¥When ready, merge changes into the "production" branch to publish an update to our production builds.

该流程的优点

¥Advantages of this flow

此流程允许你独立于开发速度来控制部署到生产的速度。这增加了测试你的应用的额外机会，并避免你的用户每次提交 PR 时都必须下载新的更新。

¥This flow allows you to control the pace of deploying to production independent of the pace of development. This adds an extra chance to test your app and avoids your user having to download a new update every time a PR is landed.
与你的团队沟通很容易，因为在合并到名为 "staging" 和 "production" 的 GitHub 分支时会发生部署更新。

¥It's easy to communicate to your team, since deploying updates occurs when merging into GitHub branches named "staging" and "production".

此流程的缺点

¥Disadvantages of this flow

检查应用的早期版本稍微复杂一些，因为我们需要检查旧的提交而不是旧的分支。

¥Checking out previous versions of your app is slightly more complex, since we'd need to check out an old commit instead of an old branch.
合并到 "production" 时，更新将重新构建并重新发布，而不是从通道 "staging" 的构建移至通道 "production" 的构建。

¥When merging to "production", the update would be re-built and re-published instead of moved from the builds with channel "staging" to the builds with channel "production".

特定于平台的流程

¥Platform-specific flow

此流程适用于需要始终单独构建和更新 Android 和 iOS 应用的项目。它将产生单独的命令来向 Android 和 iOS 应用提供更新。以下是构成此流程的上述部署过程的部分：

¥This flow is for projects that need to build and update their Android and iOS apps separately all the time. It will result in separate commands for delivering updates to the Android and iOS apps. Here are the parts of the deployment process above that make up this flow:

创建构建：（a）仅创建用于生产的构建，或者 (b) 创建用于生产的构建和单独的测试构建。

¥Creating builds: (a) Create builds for production only, or (b) create builds for production and separate builds for testing.

测试变化：（a）在 TestFlight 和 Play Store 内部轨道上测试更改和/或 (b) 使用内部发行版测试更改。

¥Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.

发布更新：(b)创建基于环境和平台的更新分支，例如 "ios-staging"、"ios-production"、"android-staging" 和 "android-production"。

¥Publishing updates: (b) Create update branches that are environment- and platform-based, like "ios-staging", "ios-production", "android-staging", and "android-production".

流程图

¥Diagram of flow

流程说明

¥Explanation of flow

在本地开发一个项目并在 Expo Go 中测试更改。

¥Develop a project locally and test changes in Expo Go.
使用名为 "ios-staging"、"ios-production"、"android-staging" 和 "android-production" 的通道创建构建。然后将 "ios-staging" 构建放在 TestFlight 上，并将 "ios-production" 构建提交到公共 App Store。同样，将 "android-staging" 版本放在 Play 商店内部轨道上，并将 "android-production" 版本提交到公共 Play 商店。

¥Create builds with channels named like "ios-staging", "ios-production", "android-staging", and "android-production". Then put the "ios-staging" build on TestFlight and submit the "ios-production" build to the public App Store. Likewise, put the "android-staging" build on the Play Store Internal Track, and submit the "android-production" build to the public Play Store.
设置 expo-github-action 在将提交合并到分支时将更新发布到所需的平台。

¥Set up expo-github-action to publish updates to the required platforms when merging commits to branches.
然后，将 iOS 应用的更改合并到分支 "ios-staging" 中，然后在准备就绪时将更改合并到 "ios-production" 分支中。同样，将 Android 应用的更改合并到分支 "android-staging" 中，准备就绪后，合并到名为 "android-production" 的分支中。

¥Then, merge changes for the iOS app into the branch "ios-staging", then when ready merge changes into the "ios-production" branch. Likewise, merge changes for the Android app into the branch "android-staging" and when ready, into the branch named "android-production".

该流程的优点

¥Advantages of this flow

此流程使你可以完全控制哪些更新进入你的 Android 和 iOS 版本。更新永远不会适用于两个平台。

¥This flow gives you full control of which updates go to your Android and iOS builds. Updates will never apply to both platforms.

此流程的缺点

¥Disadvantages of this flow

你必须运行两个命令而不是一个命令才能修复两个平台上的更改。

¥You'll have to run two commands instead of one to fix changes on both platforms.

分店促销流程

¥Branch promotion flow

此流程是用于管理版本化版本的流程示例。

¥This flow is an example of a flow for managing versioned releases.

此流程需要更多的簿记，并且不支持自动运行时版本策略（"sdkVersion"、"appVersion"、"nativeVersion" 和 "fingerprintExperimental"）。你将需要使用此流程手动指定运行时的版本。

以下是构成此流程的上述部署过程的部分：

¥Here are the parts of the deployment process above that make up this flow:

创建构建：(b)创建生产版本（每个主要版本一个）和单独的测试版本。

¥Creating builds: (b) Create builds for production (one per major version) and separate builds for testing.

测试变化：（a）在 TestFlight 和 Play Store 内部轨道上测试更改和/或 (b) 使用内部发行版测试更改。

¥Testing changes: (a) Test changes on TestFlight and the Play Store Internal Track and/or (b) Test changes with internal distribution builds.

发布更新：（c）创建基于版本的更新分支，例如 "版本-1.0"。分支动态映射到渠道，以促进从测试到生产的经过充分测试的变更。

¥Publishing updates: (c) Create update branches that are version based, like "version-1.0". Branches are dynamically mapped to channels to promote well-tested changes from testing to production.

流程图

¥Diagram of flow

流程说明

¥Explanation of flow

在本地开发一个项目并在 Expo Go 或开发构建中测试更改。

¥Develop a project locally and test changes in Expo Go or a development build.
使用名为 "production-rtv-1" 的通道（表示运行时版本为 "1" 的通道）创建构建，该版本最终将接受审核并在应用商店中提供。使用名为 "staging" 的通道创建另一组构建，该版本将用于在 TestFlight 和 Play Store Internal Track 上进行测试。

¥Create builds with channels named "production-rtv-1" (indicating a channel with a runtime version "1"), which will eventually get reviewed and become available on app stores. Create another set of builds with channels named "staging", which will be used for testing on TestFlight and the Play Store Internal Track.
设置 expo-github-action 在合并提交到分支时发布更新。

¥Set up expo-github-action to publish updates when merging commits to branches.
将更改合并到名为 "version-1" 的分支中。

¥Merge changes into a branch named "version-1".
使用网站或 EAS CLI 将 "staging" 通道指向 EAS 更新分支 "version-1"。通过打开 TestFlight 和 Play Store Internal Track 上的应用来测试更新。

¥Use the website or EAS CLI to point the "staging" channel at the EAS Update branch "version-1". Test the update by opening the apps on TestFlight and the Play Store Internal Track.
准备就绪后，使用网站或 EAS CLI 将 "production-rtv-1" 通道指向 EAS 更新分支 "version-1"。

¥When ready, use the website or EAS CLI to point the "production-rtv-1" channel at the EAS Update branch "version-1".
那么，你可能会遇到两种更新场景：

¥Then, there are two update scenarios you may encounter:
- 新版本不需要新的运行时版本：
  
  ¥A new release does not require a new runtime version:
  1. 创建另一个名为 "version-2" 的 GitHub 分支。
    
    ¥Create another GitHub branch named "version-2".
  2. 使用网站或 EAS CLI 将 "staging" 通道指向 EAS 更新分支 "version-2"。
    
    ¥Use the website or EAS CLI to point the "staging" channel at the EAS Update branch "version-2".
  3. 合并提交到 "version-2" 分支，直到新功能和修复准备就绪且稳定。
    
    ¥Merge commits into the "version-2" branch until the new features and fixes are ready and stable.
  4. 使用网站或 EAS CLI 将 "production-rtv-1" 通道指向 EAS 更新分支 "version-2"。这意味着拥有生产版本的每个人（从应用商店下载应用的用户）现在都将获得 "version-2" 分支上的最新更新。
    
    ¥Use the website or EAS CLI to point the "production-rtv-1" channel at the EAS Update branch "version-2". This will mean that everyone with a production build (users who downloaded the app from the app stores) will now get the latest update on the "version-2" branch.
- 新版本需要新的运行时版本（例如，添加新的原生库或升级 SDK 版本时）：
  
  ¥A new release requires a new runtime version (for example, when new native libraries are added or SDK version is upgraded):
  1. 将运行时版本从 "1" 升级到 "2"。
    
    ¥Bump your runtime version from "1" to "2".
  2. 使用新的运行时版本创建新的 "staging" 版本。
    
    ¥Create a new "staging" build with the new runtime version.
  3. 创建另一个名为 "version-2" 的 GitHub 分支。
    
    ¥Create another GitHub branch named "version-2".
  4. 使用网站或 EAS CLI 将 "staging" 通道指向 EAS 更新分支 "version-2"。
    
    ¥Use the website or EAS CLI to point the "staging" channel at the EAS Update branch "version-2".
  5. 合并提交到 "version-2" 分支，直到新功能和修复准备就绪且稳定。
    
    ¥Merge commits into the "version-2" branch until the new features and fixes are ready and stable.
  6. 创建一个名为 "production-rtv-2" 的新版本，该版本最终将接受审核并在应用商店上架。
    
    ¥Create a new build with channel named "production-rtv-2", which will eventually get reviewed and become available on app stores.
  7. 使用网站或 EAS CLI 将 "production-rtv-2" 通道指向 EAS 更新分支 "version-2"。这意味着之前拥有生产版本的每个人（从应用商店下载应用的用户）将继续在 EAS 更新分支 "version-1" 上获取最新更新，直到他们从应用商店下载应用的新版本，此时他们将在 EAS 更新分支 "version-2" 上获得最新更新。
    
    ¥Use the website or EAS CLI to point the "production-rtv-2" channel at the EAS Update branch "version-2". This will mean that everyone who previously had a production build (users who downloaded the app from the app stores) will continue to get the latest update on EAS Update branch "version-1" until they download the new version of the app from the app store, at which time they will get the latest update on EAS Update branch "version-2".

该流程的优点

¥Advantages of this flow

此流程比其他流程更安全。所有更新都在分发给内部测试人员的测试版本上进行测试，并且分支在通道之间移动，因此测试的确切工件就是部署到生产版本的工件。

¥This flow is safer than the other flows. All updates are tested on test builds which are distributed to internal testers, and branches are moved between channels, so the exact artifact tested is the one deployed to production builds.
此流程在 GitHub 分支和 EAS 更新分支之间创建直接映射。它还创建 GitHub 提交和 EAS 更新更新之间的映射。如果你要跟踪 GitHub 分支，则可以为每个 GitHub 分支创建 EAS 更新分支，并将这些分支链接到构建的通道。实际上，这使得你可以推送到 GitHub，然后在 Expo 上选择相同的分支名称来链接到构建。

¥This flow creates a direct mapping between GitHub branches and EAS Update branches. It also creates a mapping between GitHub commits and EAS Update updates. If you're keeping track of GitHub branches, you can create EAS Update branches for each GitHub branch and link those branches to a build's channel. In practice, this makes it so you can push to GitHub, then select the same branch name on Expo to link to builds.
以前的部署版本始终保留在 GitHub 上。一旦部署了 "版本-1.0" 分支，然后再部署另一个版本（如 "版本 1.1"），"版本-1.0" 分支将永远保留，从而可以轻松签出项目的先前版本。

¥Previous versions of your deployments are always preserved on GitHub. Once the "version-1.0" branch is deployed, then another version is deployed after it (like "version-1.1"), the "version-1.0" branch is forever preserved, making it easy to checkout a previous version of your project.

此流程的缺点

¥Disadvantages of this flow

每个生产运行时版本需要一个通道来维护先前生产版本的历史更新。这使得使用运行时版本策略变得更加困难。

¥One channel per production runtime version is needed to maintain historical updates for previous production releases. This makes using a runtime version policy more difficult.
此流程需要记录分支名称，这意味着与你的团队沟通哪些分支当前指向你的测试构建和生产构建。

¥Bookkeeping of branch names is required for this flow, which will mean communicating with your team which branches are currently pointed at your test builds and your production builds.