中文网
🌐 Nodejs.cn
首页指南EAS参考教程

替代部署模式

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

一旦我们在应用中创建了功能并修复了漏洞，我们希望尽可能快速且安全地将这些功能和漏洞修复交付给用户。通常，在向用户交付代码时，“安全”和“快速”是相互对立的因素。我们可以直接将代码推送到生产环境，这样速度会很快，但由于代码未经测试，安全性较低。另一方面，我们可以制作测试版本，与 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.

根据你的项目，你在向用户交付更新时，对“速度”和“安全性”的要求会有一定的容忍度。

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

  1. 创建构建
    • (a) 我们只能为生产使用创建构建版本。
    • (b) 我们可以为生产使用创建构建，并为预生产更改测试创建单独的构建。
  2. 测试更改
    • (a) 我们可以通过 TestFlight 和 Play 商店内部测试渠道来测试更改。
    • (b) 我们可以使用内部分发版本来测试更改。
    • (c) 我们可以使用 Expo Go 或 开发版 测试更改。
  3. 发布更新
    • (a) 我们可以向单个分支发布更新。
    • (b) 我们可以创建基于环境的更新分支，例如“生产环境”和“预发布环境”。
    • （c）我们可以创建基于版本的更新分支，例如“version-1.0”，这使我们能够将更新从一个渠道推广到另一个渠道。

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

🌐 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) 仅为生产使用创建构建。

测试更改： 使用 Expo Go 或 开发构建 测试更改。

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

流程图

🌐 Diagram of flow

Two-command deployment diagram

流程说明

🌐 Explanation of flow

  1. 在本地开发项目并在开发版本或 Expo Go 中测试更改。
  2. 运行 eas build 来创建构建，然后将它们提交到应用商店。这些构建是供公众使用的，应提交/审核并在应用商店发布。
  3. 当我们有想要发布的更新时，运行 eas update --branch production 可立即向我们的用户推送更新。

该流程的优点

🌐 Advantages of this flow

  • 此流程不需要记录额外的版本或环境名称，这使得与其他人交流变得容易。
  • 向构建提供更新的速度非常快。

此流程的缺点

🌐 Disadvantages of this flow

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

持续的分期流程

🌐 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) 为生产环境创建构建，并为测试创建单独的构建。

测试更改： (a) 在 TestFlight 和 Play 商店内部测试渠道上测试更改；和/或 (b) 使用内部分发构建测试更改。

发布更新: (b) 创建基于环境的更新分支，如“预发布”和“生产”。

流程图

🌐 Diagram of flow

Staging deployment diagram

流程说明

🌐 Explanation of flow

  1. 在本地开发一个项目并在 Expo Go 中测试更改。
  2. 创建名为“production”的构建渠道，这些渠道的构建最终会被审核并在应用商店上线。创建另一组名为“staging”的构建渠道，这些渠道的构建将用于在 TestFlight 和 Play 商店内部测试渠道进行测试。
  3. 设置 expo-github-action 在合并提交到分支时发布更新。
  4. 将更改合并到名为“staging”的分支中。GitHub Action 会发布更新，并在我们的测试版本中提供。
  5. 准备好后，将更改合并到“production”分支，以发布生产版本的更新。

该流程的优点

🌐 Advantages of this flow

  • 这个流程允许你独立于开发速度来控制部署到生产环境的节奏。这增加了额外的机会来测试你的应用，并避免了每次合并一个 PR 时用户都必须下载新更新的情况。
  • 与团队沟通很容易，因为在合并到名为“staging”和“production”的 GitHub 分支时，就会部署更新。

此流程的缺点

🌐 Disadvantages of this flow

  • 检查应用的早期版本稍微复杂一些，因为我们需要检查旧的提交而不是旧的分支。
  • 当合并到“生产”时，更新将被重新构建和重新发布，而不是从“预发布”渠道的版本移动到“生产”渠道的版本。

特定于平台的流程

🌐 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) 为生产环境创建构建，并为测试环境创建单独的构建。

测试更改： (a) 在 TestFlight 和 Play 商店内部测试渠道上测试更改；和/或 (b) 使用内部分发构建测试更改。

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

流程图

🌐 Diagram of flow

Platform specific deployment diagram

流程说明

🌐 Explanation of flow

  1. 在本地开发一个项目并在 Expo Go 中测试更改。
  2. 创建名为“ios-staging”、“ios-production”、“android-staging”和“android-production”的渠道构建。然后将“ios-staging”构建上传到 TestFlight，并将“ios-production”构建提交到公开的 App Store。类似地，将“android-staging”构建发布到 Play 商店内部测试渠道，并将“android-production”构建提交到公开的 Play 商店。
  3. 设置 expo-github-action，以便在将提交合并到分支时向所需平台发布更新。
  4. 然后，将 iOS 应用的更改合并到分支“ios-staging”，准备好时再合并到“ios-production”分支。同样，将 Android 应用的更改合并到分支“android-staging”，准备好时再合并到名为“android-production”的分支。

该流程的优点

🌐 Advantages of this flow

  • 此流程让你完全控制更新发送到 Android 和 iOS 构建版本的情况。更新绝不会同时应用于两个平台。

此流程的缺点

🌐 Disadvantages of this flow

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

分店促销流程

🌐 Branch promotion flow

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

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

警告 此流程需要更多的记录管理，并且不支持自动的 运行时版本策略（"sdkVersion"、"appVersion"、"nativeVersion" 和 "fingerprint"）。你需要在此流程中 手动指定 运行时的版本。

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

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

创建构建： (b) 为生产环境创建构建（每个主版本一个）并为测试创建单独的构建。

测试更改： (a) 在 TestFlight 和 Play 商店内部测试渠道上测试更改；和/或 (b) 使用内部分发构建测试更改。

发布更新： (c) 创建基于版本的更新分支，例如“version-1.0”。分支会动态映射到通道，以将经过充分测试的更改从测试环境推广到生产环境。

流程图

🌐 Diagram of flow

Branch deployment diagram

流程说明

🌐 Explanation of flow

  1. 在本地开发项目，并在 Expo Go 或 开发构建 中测试更改。
  2. 创建名为“production-rtv-1”的渠道构建（表示运行时版本为“1”的渠道），这些构建最终将被审核并在应用商店上发布。创建另一组名为“staging”的渠道构建，这些构建将用于在 TestFlight 和 Play 商店内部测试通道进行测试。
  3. 设置 expo-github-action 在合并提交到分支时发布更新。
  4. 将更改合并到名为“version-1”的分支中。
  5. 使用网站或 EAS CLI 将“staging”通道指向 EAS 更新分支“version-1”。通过在 TestFlight 和 Play 商店内部测试通道打开应用来测试更新。
  6. 准备好后，使用网站或 EAS CLI 将“production-rtv-1”通道指向 EAS 更新分支“version-1”。
  7. 那么，你可能会遇到两种更新场景：
    • 新版本不需要新的运行时版本：
      1. 创建另一个名为“version-2”的 GitHub 分支。
      2. 使用网站或 EAS CLI 将“staging”通道指向 EAS 更新分支“version-2”。
      3. 将提交合并到“version-2”分支，直到新功能和修复准备就绪且稳定。
      4. 使用网站或 EAS CLI 将“production-rtv-1”通道指向 EAS 更新分支“version-2”。这意味着所有使用生产版本（从应用商店下载应用的用户）的人现在都将获得“version-2”分支上的最新更新。
    • 新版本需要新的运行时版本（例如，添加新的原生库或升级 SDK 版本时）：
      1. 将你的运行时版本从“1”升级到“2”。
      2. 使用新的运行时版本创建一个新的“暂存”构建。
      3. 创建另一个名为“version-2”的 GitHub 分支。
      4. 使用网站或 EAS CLI 将“staging”通道指向 EAS 更新分支“version-2”。
      5. 将提交合并到“version-2”分支，直到新功能和修复准备就绪且稳定。
      6. 创建一个名为“production-rtv-2”的新构建版本，该版本最终将经过审核并在应用商店上线。
      7. 使用网站或 EAS CLI 将 "production-rtv-2" 渠道指向 EAS 更新分支 "version-2"。这意味着之前拥有生产版本的所有人（从应用商店下载应用的用户）在下载应用的新版本之前，将继续从 EAS 更新分支 "version-1" 获取最新更新；在他们从应用商店下载新版本时，将开始从 EAS 更新分支 "version-2" 获取最新更新。

该流程的优点

🌐 Advantages of this flow

  • 这个流程比其他流程更安全。所有更新都会在测试版本上进行测试，这些测试版本会分发给内部测试人员，并且分支会在不同渠道之间移动，因此测试的确切构件就是部署到生产版本的构件。
  • 此流程在 GitHub 分支和 EAS Update 分支之间创建了直接映射。它还在 GitHub 提交和 EAS Update 更新之间创建映射。如果你正在跟踪 GitHub 分支，可以为每个 GitHub 分支创建 EAS Update 分支，并将这些分支链接到构建的渠道上。实际上，这意味着你可以先推送到 GitHub，然后在 Expo 上选择相同的分支名称以链接到构建。
  • 你以前的部署版本始终保存在 GitHub 上。一旦“version-1.0”分支被部署，随后又部署了另一个版本（例如“version-1.1”），那么“version-1.0”分支将被永久保留，使你可以轻松检出项目的先前版本。

此流程的缺点

🌐 Disadvantages of this flow

  • 每个生产运行时版本需要一个渠道来维护以前生产版本的历史更新。这使得使用运行时版本策略更加困难。
  • 此流程需要记录分支名称，这意味着与你的团队沟通哪些分支当前指向你的测试构建和生产构建。