用 EAS 工作流自动化生产部署

添加一个 production.yml

🌐 Add a production.yml

在 .eas/workflows/ 里面，创建一个名为 production.yml 的新文件，使用 eas.json 里的 production 构建配置：

🌐 Inside .eas/workflows/, create a new file called production.yml that uses the production build profile from eas.json:

name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  build_android:
    name: Build Android
    type: build
    params:
      platform: android
      profile: production
  build_ios:
    name: Build iOS
    type: build
    params:
      platform: ios
      profile: production

这会在推送到任何符合 release/* 模式的分支时，为 Android 创建一个 .aab 文件，为 iOS 创建一个 .ipa 文件。

🌐 This creates a .aab artifact for Android and an .ipa artifact for iOS on a push to any branch that matches the pattern release/*.

在工作流程中添加指纹

🌐 Add fingerprints to the workflow

让我们在工作流中添加一个 fingerprint 任务，以检查本地代码是否有更改，并基于该检查更新现有的 build_android 和 build_ios 任务。我们还添加了 get-build 任务，用于查看已有的 Android 和 iOS 构建。

🌐 Let's add a fingerprint job to the workflow to check if there are changes to native code and update existing build_android and build_ios jobs based on that. We are also adding get-build jobs to look up existing builds for Android and iOS.

用以下代码更新 production.yml 文件：

🌐 Update the production.yml file with the following code:

name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  fingerprint:
    name: Fingerprint
    type: fingerprint
    environment: production
  get_android_build:
    name: Check for existing Android build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }}
      profile: production
  get_ios_build:
    name: Check for existing iOS build
    needs: [fingerprint]
    type: get-build
    params:
      fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }}
      profile: production
  build_android:
    name: Build Android
    needs: [get_android_build]
    if: ${{ !needs.get_android_build.outputs.build_id }}
    type: build
    params:
      platform: android
      profile: production
  build_ios:
    name: Build iOS
    needs: [get_ios_build]
    if: ${{ !needs.get_ios_build.outputs.build_id }}
    type: build
    params:
      platform: ios
      profile: production

在上面的工作流程中，fingerprint 任务首先运行，并根据代码库的更改生成一个哈希值。接着，get-build 任务会检查是否有已有的 Android 和 iOS 构建使用相同的指纹哈希。如果没有现有的构建，build 任务就会运行，生成新的生产构建。

🌐 In the above workflow, the fingerprint job runs first and generates a hash based on the changes in the codebase. The get-build jobs then check if there are existing builds for Android and iOS with the same fingerprint hash. If there are no existing builds, the build jobs run to create new builds for production.

fingerprint 任务中的 environment 字段告诉 EAS 在计算指纹时要加载哪些环境变量。我们的生产环境中，像 API_URL 或功能开关这样的变量可能有不同的值。这些值在 EAS 将它们烘焙进构建时可能会影响原生层。设置 environment: production 可以确保指纹反映实际发布的内容。

🌐 The environment field on the fingerprint job tells EAS which environment variables to load when computing the fingerprint. Our production environment may have different values for variables such as API_URL or feature flags. Those values can affect the native layer when EAS bakes them into the build. Setting environment: production ensures the fingerprint reflects what ships.

build_android 和 build_ios 任务上使用的 if 字段是一个布尔表达式。当它的值为 false 时，构建任务会被跳过。! 运算符意味着构建任务只在 get-build 没有找到匹配的构建时才会运行。

🌐 The if field used on the build_android and build_ios jobs is a boolean expression. When it evaluates to false, the build jobs are skipped. The ! operator means the build job runs only when get-build did not find a matching build.

添加一个更新任务

🌐 Add a job for updates

目前，我们的工作流程只有在本地代码有更改时才会创建生产版本。如果只是 TypeScript/JavaScript 文件有更改，我们希望触发 OTA 更新，而不是本地构建。

🌐 Currently, our workflow only creates production builds when there are changes to native code. If there are only changes to TypeScript/JavaScript files, we want to trigger an OTA update instead of a native build.

让我们添加两个作业 update_android 和 update_ios，当本地代码没有变化时运行，并使用 update 作业类型来触发 OTA 更新：

🌐 Let's add two jobs update_android and update_ios that run when there are no changes to native code and use update job type to trigger an OTA update:

name: Deploy to production

on:
  push:
    branches: ['release/*']

jobs:
  fingerprint:
    # ...
  get_android_build:
    # ...
  get_ios_build:
    # ...
  build_android:
    # ...
  build_ios:
    # ...
  update_android:
    name: Publish Android update
    needs: [get_android_build]
    if: ${{ needs.get_android_build.outputs.build_id }}
    type: update
    params:
      branch: production
      platform: android
  update_ios:
    name: Publish iOS update
    needs: [get_ios_build]
    if: ${{ needs.get_ios_build.outputs.build_id }}
    type: update
    params:
      branch: production
      platform: ios

我们的工作流程只构建面向生产的应用二进制文件或发布 OTA 更新。自动化应用商店提交是接下来常讨论的一个步骤，具体见下文的 自动化应用商店提交 部分。

🌐 Our workflow only builds production-ready app binaries or publishes OTA updates. Automating store submission is a common next step discussed below in the Automate app store submissions section.

创建一个发布分支并推送更改

🌐 Create a release branch and push changes

信息 注意： 确保此时工作流文件已经是我们 GitHub 仓库的一部分，并且在 main 分支上可用。

为了测试我们的工作流程，让我们创建一个发布分支，然后从终端窗口将其推送到我们的 GitHub 仓库：

🌐 To test our workflow, let's create a release branch and push it to our GitHub repository from a terminal window:

打开 EAS 仪表板并找到工作流运行。由于这个指纹还没有构建，build 任务应该会运行，而 update 任务应该是灰色的。

🌐 Open the EAS dashboard and find the workflow run. Since no build exists yet for this fingerprint, the build jobs should run, and the update jobs should be grayed out.

Android 和 iOS 的构建正在同时进行。一旦每个任务完成，我们就会收到新的 Android 和 iOS 工件。

🌐 Both Android and iOS builds are running in parallel. Once each job completes, we receive a new artifact for Android and iOS.

现在，让我们在相同的发布分支上，在示例项目中仅做一个 TypeScript/JavaScript 的修改，然后使用下面的命令再次推送：

🌐 Now, let's make a TypeScript/JavaScript only change in our example project on the same release branch and push again using the commands below:

工作流运行后，注意在 EAS 仪表板上指纹与上次推送的构建匹配。build 任务完全被跳过，update 任务则发布了 OTA 更新。

🌐 After the workflow runs, notice in the EAS dashboard that the fingerprint matches the build from the last push. The build jobs are skipped entirely, and the update jobs publish an OTA update.