1. 项目概述：为什么游戏开发需要CI/CD？

如果你和我一样，在游戏开发这条路上摸爬滚打了好些年，肯定经历过这样的场景：策划提了个新需求，程序吭哧吭哧改完代码，本地跑起来一切正常，然后自信满满地提交。结果，负责打包的同事（或者就是你自己）在构建服务器上点了“构建”按钮，等待半小时后，屏幕上赫然出现一片飘红的编译错误。更糟的是，好不容易构建成功，发给测试团队，他们反馈说某个核心功能在打包后的版本里失效了。于是，所有人停下手中的活，开始“捉虫”，项目进度被无情阻塞。这种“人肉集成”和“手动发布”的模式，在项目初期或许还能应付，一旦团队规模扩大、版本迭代加速，它就会成为效率的“黑洞”和质量的“盲区”。

这正是我们需要为Unity游戏项目引入CI/CD（持续集成/持续部署）流水线的核心原因。CI/CD不是大厂的专属玩具，它是任何追求高效、稳定交付的现代开发团队的必需品。简单来说，它是一套自动化的工作流：每当有新的代码提交到版本库（如GitHub），这套流水线就会自动触发，完成代码编译、资源导入、单元测试、打包构建，甚至自动发布到测试平台或分发渠道。对于Unity项目，这意味着你可以将那些重复、繁琐且容易出错的手动操作——比如处理不同的平台构建设置、管理各种版本的AssetBundle、运行自动化测试——全部交给机器。

我选择Unity + GitHub Actions这个组合，是因为它几乎为零成本启动提供了最佳路径。Unity是游戏开发的事实标准，而GitHub Actions作为GitHub原生集成的自动化工具，无需自建Jenkins服务器，配置直观，与代码仓库无缝结合。想象一下，你提交代码后，可以去喝杯咖啡，回来时，一个完整的、经过基础测试的APK/IPA/EXE文件已经生成，并自动上传到了你指定的内测分发平台（如TestFlight、Google Play Internal Testing），测试同事立刻就能收到通知进行体验。这种“提交即发布”的流畅感，能极大提升团队的开发节奏和信心。

2. 核心需求与方案设计拆解

在动手搭建之前，我们必须想清楚，我们到底要这个流水线做什么？一个完整的游戏CI/CD流水线，远不止是“自动打个包”。我们需要拆解出核心需求，并据此设计我们的GitHub Actions工作流。

2.1 核心需求解析

基于常见的Unity团队协作痛点，我将核心需求归纳为以下四点：

1. 自动化构建（Build Automation）：这是基础。流水线必须能根据不同的目标平台（Android, iOS, Windows, WebGL等），使用一致的参数和环境，自动完成Unity项目的构建。这消除了因开发者本地环境差异（如Unity版本、SDK路径、构建设置）导致的“在我机器上是好的”问题。
2. 自动化测试（Test Automation）：构建成功不代表功能正常。我们需要在打包后，立即运行一套自动化测试来验证核心逻辑。这包括：
   • 单元测试（Unit Tests）：针对游戏逻辑代码（非MonoBehaviour）的快速测试。
   • 集成测试/Play Mode Tests：在Unity编辑器中模拟游戏运行，测试MonoBehaviour组件间的交互和游戏流程。
   • 冒烟测试（Smoke Test）：构建完成后，自动安装到模拟器或真机，执行一个最简化的启动-登录-主界面流程，确保应用不崩溃、能运行。
3. 自动化发布（Release Automation）：构建和测试都通过后，我们需要将产物（安装包）自动分发出去。对于移动端，这可能意味着：
   • 将APK上传到Google Play Console的Internal Test轨道。
   • 将IPA上传到App Store Connect，并使用TestFlight进行内部分发。
   • 将包体上传到内网服务器或第三方分发平台（如Fir.im, 蒲公英）。
4. 状态反馈与质量门禁（Feedback & Gating）：整个流水线的状态必须透明。每次运行的成功或失败，都应该通过GitHub Commit Status、Slack/钉钉消息等方式通知团队。更重要的是，可以将测试结果作为“质量门禁”，只有所有测试通过的构建，才允许被标记为可发布版本，甚至自动触发发布流程。

2.2 技术方案选型：为什么是GitHub Actions？

市面上CI/CD工具很多，比如Jenkins、GitLab CI、CircleCI、Azure DevOps。选择GitHub Actions，主要基于以下几点考量：

• 零成本与开箱即用：对于开源项目完全免费，私有仓库也有充足的免费额度（每月2000分钟）。它直接集成在GitHub仓库中，无需额外维护一台Jenkins Master服务器，省去了大量的运维成本。
• 与GitHub生态深度集成：工作流的触发条件（如push, pull_request）定义非常直观。可以方便地读取提交信息、对比代码变更，并将构建状态直接反馈到Pull Request界面，非常适合基于Git Flow或GitHub Flow的开发模式。
• 强大的社区市场（Marketplace）：有大量预制的、维护良好的Action可供使用。例如，有官方和社区维护的actions/setup-java、actions/upload-artifact，以及专门为Unity优化的game-ci/unity-builder和webbertakken/unity-test-runner。这让我们可以像搭积木一样组合功能，避免重复造轮子。
• 跨平台支持：GitHub Actions的Runner支持Windows、Linux和macOS。这对于游戏构建至关重要，因为iOS构建必须在macOS环境下进行，而其他平台则可以在Linux或Windows上完成，我们可以通过矩阵策略来管理多平台构建。

Unity项目CI/CD的特殊性：Unity项目不是纯代码项目，它包含大量的二进制资源（纹理、模型、音频等）。这带来了两个挑战：1) 仓库体积巨大；2) 构建过程需要在特定的Unity编辑器环境中进行。因此，我们的方案核心是：使用一个轻量级的“构建器”Docker镜像或特定版本的Unity Editor，在云端Runner中拉取项目代码，然后调用Unity的命令行接口（Batchmode）执行构建和测试任务。

3. 环境准备与基础配置

在编写第一个工作流文件之前，我们需要在Unity项目本地和GitHub仓库中进行一些必要的配置。

3.1 Unity项目本地配置

为了让Unity项目能在无界面的服务器环境下进行构建和测试，我们需要进行一些设置。

1. 启用版本控制兼容模式：在Edit -> Project Settings -> Editor中，将Version Control模式设置为Visible Meta Files，将Asset Serialization模式设置为Force Text。这是为了确保所有的场景和预制件文件以文本格式存储，便于Git进行差异比较和合并，避免二进制文件冲突。
2. 设置正确的构建场景：在File -> Build Settings中，将需要打包的场景拖入Scenes In Build列表，并调整好顺序。这个列表决定了最终包体中包含哪些场景。
3. 配置Player Settings：根据目标平台，配置好包名（Bundle Identifier）、版本号（Version）、图标、分辨率设置等。一个关键技巧：对于需要自动化管理的版本号，我们可以不在这里写死，而是通过命令行参数在构建时动态传入。例如，我们可以将版本号格式定为[Major].[Minor].[BuildNumber]，其中BuildNumber由CI系统（如GitHub Actions的run_number）自动生成。
4. 创建必要的Editor脚本：我们需要编写一些C#脚本，放在Assets/Editor目录下，以便通过命令行调用。
   • 构建脚本：创建一个静态方法，使用BuildPipeline.BuildPlayerAPI来执行构建。这个方法应该能接收命令行参数，比如输出路径、目标平台、开发/发布模式等。

   // Assets/Editor/BuildScript.cs using UnityEditor; using System.Linq; public static class BuildScript { public static void PerformBuild() { // 从命令行参数获取构建选项 var args = System.Environment.GetCommandLineArgs(); string outputPath = GetArgValue(args, "-outputPath"); BuildTarget target = GetBuildTargetFromArgs(args); // 解析平台 BuildOptions options = BuildOptions.None; if (args.Contains("-development")) options |= BuildOptions.Development; BuildPlayerOptions buildOptions = new BuildPlayerOptions { scenes = EditorBuildSettings.scenes.Where(s => s.enabled).Select(s => s.path).ToArray(), locationPathName = outputPath, target = target, options = options }; BuildPipeline.BuildPlayer(buildOptions); } private static string GetArgValue(string[] args, string argName) { // 简易的参数解析逻辑 int index = System.Array.IndexOf(args, argName); return index > -1 && index + 1 < args.Length ? args[index + 1] : null; } }

   • 测试脚本：如果使用Unity Test Runner，通常不需要额外脚本，可以通过命令行直接运行。但如果你有自定义的测试流程，可能需要编写相应的Editor脚本来启动。

3.2 GitHub仓库配置

1. 设置.gitignore：确保你的.gitignore文件排除了Library/、Temp/、Obj/、Build/等文件夹，以及*.csproj、*.sln等由IDE生成的文件。只提交Assets/、ProjectSettings/、Packages/（或Packages/manifest.json）等核心内容。这能极大减小仓库体积。
2. 使用Unity Package Manager：通过Packages/manifest.json来管理所有依赖（包括来自Asset Store的包，如果它们支持UPM）。这能确保CI服务器和每个开发者的环境拥有一致的依赖版本。
3. 创建GitHub Secrets（关键安全步骤）：我们绝对不能将敏感信息（如证书、密码、API密钥）硬编码在代码或工作流文件中。GitHub提供了Secrets功能。
   • 进入你的仓库 ->Settings->Secrets and variables->Actions。
   • 点击New repository secret。
   • 你需要添加的Secrets可能包括：
     • UNITY_LICENSE: 你的Unity专业版序列号（用于激活无头模式编辑器）。获取方式：从Unity开发者后台获取。
     • UNITY_EMAIL和UNITY_PASSWORD: 用于自动激活License的账号（注意安全，建议使用服务账号）。
     • ANDROID_KEYSTORE_BASE64: 经过Base64编码的Android签名密钥库（.keystore）文件内容。
     • ANDROID_KEYSTORE_PASS,ANDROID_KEYALIAS_NAME,ANDROID_KEYALIAS_PASS: 密钥库的密码和别名信息。
     • APPLE_CERTIFICATE_BASE64和APPLE_CERTIFICATE_PASSWORD: iOS发布证书。
     • APPLE_PROVISIONING_PROFILE_BASE64: iOS描述文件。
     • TESTFLIGHT_API_KEY和TESTFLIGHT_API_ISSUER_ID: 用于上传到TestFlight的App Store Connect API密钥。
     • GOOGLE_PLAY_API_CREDENTIALS: 用于上传到Google Play的Service Account JSON密钥。

重要提示：如何生成Base64编码的Secret？在本地终端执行：cat yourfile.keystore | base64 | pbcopy(macOS/Linux) 或certutil -encode yourfile.cer temp.b64 && findstr /v /c:- temp.b64(Windows)，然后将输出的字符串粘贴到Secret中。

4. 构建GitHub Actions工作流

一切就绪，现在我们来编写核心的.github/workflows/ci.yml文件。我将分模块详细解释。

4.1 工作流结构与触发器

首先定义工作流的基本信息和触发条件。

name: Unity CI/CD Pipeline on: push: branches: [ main, develop ] # 推送到主分支和开发分支时触发 pull_request: branches: [ main ] # 针对主分支的PR创建或更新时触发 workflow_dispatch: # 允许在GitHub Actions页面手动触发 inputs: platform: description: 'Target Platform' required: true default: 'Android' type: choice options: - Android - iOS - WebGL - Windows env: UNITY_VERSION: '2022.3.31f1' # 指定项目使用的Unity版本

• on.push和on.pull_request：这是最常用的触发器。每次代码推送或创建PR时，都会自动运行CI，确保新代码不会破坏现有功能。
• on.workflow_dispatch：提供了手动触发流水线的能力，并可以输入参数（如选择构建平台），非常灵活。
• env：定义全局环境变量，方便统一管理版本号等配置。

4.2 构建任务详解

接下来，我们定义一个构建Android平台的工作。这里我强烈推荐使用社区维护的game-ci/unity-builderAction，它封装了Unity激活、项目缓存、多平台构建等复杂逻辑，极其好用。

jobs: build-android: name: Build for Android runs-on: ubuntu-latest # Android构建可以在Linux环境下进行 if: github.event_name == 'push' || (github.event_name == 'workflow_dispatch' && github.event.inputs.platform == 'Android') # 条件执行 steps: - name: Checkout repository uses: actions/checkout@v4 with: lfs: true # 如果使用了Git LFS管理大文件，必须开启 fetch-depth: 0 # 获取所有历史，这对生成版本号可能有用 - name: Cache Unity Library uses: actions/cache@v4 with: path: Library key: Library-${{ runner.os }}-${{ env.UNITY_VERSION }} restore-keys: | Library-${{ runner.os }}- - name: Build Android APK uses: game-ci/unity-builder@v4 env: UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }} UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }} UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }} with: unityVersion: ${{ env.UNITY_VERSION }} targetPlatform: Android customParameters: -outputPath Builds/Android/my_game.apk buildName: MyGame-Android androidAppBundle: false # 构建APK而非AAB androidKeystoreName: user.keystore androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }} androidKeystorePass: ${{ secrets.ANDROID_KEYSTORE_PASS }} androidKeyaliasName: ${{ secrets.ANDROID_KEYALIAS_NAME }} androidKeyaliasPass: ${{ secrets.ANDROID_KEYALIAS_PASS }} - name: Upload APK as artifact uses: actions/upload-artifact@v4 with: name: MyGame-Android-APK path: Builds/Android/my_game.apk retention-days: 7 # 产物保留7天

步骤解析与避坑指南：

1. Checkout：拉取代码。fetch-depth: 0对于需要基于Git历史生成版本号（如git describe --tags）的场景很重要。
2. Cache Unity Library：这是加速构建的关键。Unity项目的Library文件夹包含了导入后的资源数据，体积巨大，重新导入耗时极长。此步骤将Library目录缓存起来，下次构建时直接复用，通常能将构建时间从30分钟缩短到10分钟以内。缓存键（key）需要包含Unity版本，因为不同版本生成的Library不兼容。
3. Build with unity-builder：核心构建步骤。
   • env部分传入了Unity激活所需的Secrets。
   • customParameters：可以传递给我们之前编写的BuildScript.cs的命令行参数。
   • androidKeystore...：这里演示了如何安全地使用Secrets进行Android签名。unity-builderAction会在构建过程中自动使用这些信息签名APK。
   • 避坑点：确保你本地的Android SDK & NDK设置与构建环境兼容。unity-builder使用的默认镜像包含了较新的SDK，如果你的项目指定了特定版本的SDK，可能需要通过androidSdkManagerParameters参数进行额外配置。
4. Upload Artifact：将构建好的APK文件上传到GitHub Actions的产物存储区，供后续步骤下载或手动下载。

4.3 集成自动化测试

构建成功只是第一步，我们还需要验证产物质量。我们将测试任务设计为依赖构建任务。

test-android: name: Run Tests on Android Build runs-on: ubuntu-latest needs: build-android # 依赖构建任务，只有构建成功才会运行测试 if: always() # 即使构建失败，也尝试运行测试（例如，运行单元测试检查代码问题） steps: - name: Download APK artifact uses: actions/download-artifact@v4 with: name: MyGame-Android-APK - name: Setup Android Emulator uses: reactivecircus/android-emulator-runner@v2 with: api-level: 33 script: echo "Emulator is ready." - name: Install APK on Emulator run: | adb devices -l adb install my_game.apk adb shell monkey -p com.yourcompany.yourgame -c android.intent.category.LAUNCHER 1 - name: Run Unity Tests (Edit Mode & Play Mode) uses: webbertakken/unity-test-runner@v2 with: unityVersion: ${{ env.UNITY_VERSION }} testMode: all # 运行所有模式的测试 artifactsPath: test-results customParameters: -projectPath . - name: Upload Test Results uses: actions/upload-artifact@v4 if: always() # 即使测试失败也上传结果 with: name: Unity-Test-Results path: test-results/ retention-days: 30 - name: Publish Test Results uses: EnricoMi/publish-unit-test-result-action@v2 if: always() with: files: test-results/*.xml # 解析Unity Test Runner生成的NUnit格式结果

测试策略详解：

1. 模拟器测试：我们使用android-emulator-runner在CI环境中启动一个Android模拟器，然后安装刚刚构建的APK，并使用adb shell monkey命令自动启动应用。这是一个最简单的“冒烟测试”，确保应用能安装和启动。
2. Unity单元/集成测试：unity-test-runnerAction是一个专门用于在CI中运行Unity Test Runner测试的工具。它可以在无头模式下运行Edit Mode测试（纯代码逻辑）和Play Mode测试（需要运行编辑器）。artifactsPath指定了测试报告的输出目录。
3. 测试结果处理：我们将测试结果文件（XML格式）作为产物上传，便于存档。同时，使用publish-unit-test-result-action将测试结果汇总并展示在GitHub的Actions运行详情页和Pull Request的Checks区域，提供直观的通过/失败反馈。

实操心得：Play Mode测试在CI中运行相对较慢且不稳定（依赖于图形环境）。建议将核心业务逻辑尽量编写为不依赖Unity引擎的纯C#单元测试（Edit Mode），它们运行速度极快。Play Mode测试则用于验证重要的、与引擎交互紧密的集成场景，并做好失败重试机制。

4.4 实现自动化发布

当构建和测试都通过后（通常是在main分支的推送时），我们可以自动将产物发布到分发渠道。

deploy-android-internal: name: Deploy to Google Play Internal runs-on: ubuntu-latest needs: [build-android, test-android] # 依赖构建和测试任务 if: github.ref == 'refs/heads/main' && needs.build-android.result == 'success' && needs.test-android.result == 'success' steps: - name: Download APK artifact uses: actions/download-artifact@v4 with: name: MyGame-Android-APK - name: Decode Google Play API Credentials run: | echo "${{ secrets.GOOGLE_PLAY_API_CREDENTIALS }}" > ~/play-api-key.json - name: Publish to Google Play Internal Track uses: r0adkll/upload-google-play@v1 with: serviceAccountJsonPlainText: ${{ secrets.GOOGLE_PLAY_API_CREDENTIALS }} packageName: com.yourcompany.yourgame releaseFiles: my_game.apk track: internal # 发布到内部测试轨道 status: completed

发布步骤解析：

1. 条件触发：if语句确保了只有main分支的推送，并且前置的构建和测试任务都成功时，才会执行发布。
2. 使用Google Play API：r0adkll/upload-google-playAction封装了与Google Play Developer API的交互。你需要先在Google Cloud Console创建一个服务账号，并授予其Google Play Console的访问权限，然后将生成的JSON密钥内容保存为GitHub SecretGOOGLE_PLAY_API_CREDENTIALS。
3. 发布轨道：track: internal表示发布到“内部测试”轨道，该轨道的测试人员列表在Play Console中管理。你也可以发布到alpha或beta轨道。

对于iOS，流程类似，但需要使用apple-actions/upload-testflight-build等Action，并提前配置好App Store Connect的API密钥和证书。

5. 高级优化与实战技巧

基础流水线搭建完成后，我们可以从效率、可靠性和管理性上进行深度优化。

5.1 使用构建矩阵实现多平台并行

为每个平台单独写一个job很冗余。GitHub Actions的matrix策略可以让我们用一个job定义，并行构建多个平台。

jobs: build-matrix: name: Build for ${{ matrix.targetPlatform }} runs-on: ${{ matrix.runsOn }} strategy: matrix: include: - targetPlatform: Android runsOn: ubuntu-latest buildExtension: .apk - targetPlatform: WebGL runsOn: ubuntu-latest buildExtension: .zip - targetPlatform: Windows runsOn: windows-latest buildExtension: .exe - targetPlatform: iOS runsOn: macos-latest # iOS构建必须在macOS上 buildExtension: .ipa steps: # ... 步骤与之前类似，使用 matrix.targetPlatform 等变量 - name: Build uses: game-ci/unity-builder@v4 with: targetPlatform: ${{ matrix.targetPlatform }} buildName: MyGame-${{ matrix.targetPlatform }}

5.2 智能缓存与依赖管理

除了缓存Library，我们还可以缓存Unity Editor本身和Package Manager的包，进一步提速。

- name: Cache Unity Editor uses: actions/cache@v4 with: path: /opt/unity/Editor key: Unity-${{ env.UNITY_VERSION }}-${{ runner.os }} - name: Cache UPM Packages uses: actions/cache@v4 with: path: /root/.local/share/unity3d/cache key: upm-cache-${{ runner.os }}-${{ hashFiles('Packages/packages-lock.json') }}

注意：缓存Unity Editor路径需要知道unity-builderAction将Editor安装在了哪里，这可能需要查阅该Action的文档或源码。

5.3 动态版本号与Changelog生成

手动维护版本号容易出错。我们可以让CI系统自动生成。

- name: Generate Build Version id: version run: | # 示例：使用Git提交次数和短哈希作为构建号 BUILD_NUMBER=$(( $(git rev-list --count HEAD) )) SHORT_SHA=$(git rev-parse --short HEAD) VERSION="1.0.$BUILD_NUMBER-$SHORT_SHA" echo "VERSION=$VERSION" >> $GITHUB_OUTPUT # 将版本号写入一个环境文件，供Unity构建脚本读取 echo "BUILD_VERSION=$VERSION" >> $GITHUB_ENV - name: Build uses: game-ci/unity-builder@v4 with: customParameters: -outputPath Builds/${{ matrix.targetPlatform }}/MyGame-${{ steps.version.outputs.VERSION }}${{ matrix.buildExtension }} -buildVersion ${{ env.BUILD_VERSION }}

在Unity构建脚本中，读取-buildVersion参数，并赋值给PlayerSettings.bundleVersion。

5.4 安全与权限管理

• 最小权限原则：为Google Play/App Store Connect的API密钥设置尽可能小的权限范围（例如，仅能上传到内部测试轨道）。
• Secret轮换：定期更新你的API密钥和证书。
• 分支保护规则：在GitHub仓库设置中，为main分支启用保护规则，要求必须通过CI检查（build-android,test-android）才能合并PR。这是实现“质量门禁”的关键。

6. 常见问题排查与调试实录

即使配置再仔细，在CI/CD实践中也难免会遇到问题。这里记录几个我踩过的坑和解决方法。

6.1 构建失败：Unity License激活问题

现象：构建任务失败，日志显示“Unity license is not activated.”或激活过程出错。排查：

1. 检查UNITY_LICENSE、UNITY_EMAIL、UNITY_PASSWORD这三个Secrets是否填写正确。特别注意：UNITY_LICENSE应该是从Unity开发者后台获取的序列号，而不是License文件。
2. 确认你的Unity订阅是否有效，并且允许在无头模式下使用。
3. 尝试在本地使用相同的序列号通过命令行激活Unity，验证其有效性：/path/to/Unity -batchmode -nographics -quit -manualLicenseFile /path/to/your.ulf。

6.2 构建失败：Android SDK/NDK版本不匹配

现象：Android构建失败，错误信息提及androidSDKPath找不到或NDK not found。排查：

1. 在Unity Editor中，查看Edit -> Preferences -> External Tools，记录下你本地使用的Android SDK和NDK路径及版本。
2. 在GitHub Actions工作流中，unity-builderAction使用的默认镜像可能安装了不同的版本。你可以在构建步骤中通过androidSdkVersion和androidNdkVersion参数指定版本。

   with: androidSdkVersion: "34" # 指定SDK Platform版本 androidNdkVersion: "25.2.9519653" # 指定NDK版本

3. 如果问题依旧，考虑在构建步骤前增加一个步骤，使用sdkmanager命令行工具安装特定版本的组件。

6.3 测试失败：Play Mode测试超时或卡死

现象：unity-test-runner运行Play Mode测试时超时，没有生成结果。排查：

1. Play Mode测试需要在Unity编辑器中“运行”游戏，这比Edit Mode测试慢得多且更不稳定。首先，检查你的测试代码是否有死循环或阻塞操作。
2. 在unity-test-runnerAction中增加超时时间和调试输出：

   with: testMode: playmode artifactsPath: test-results customParameters: -projectPath . -batchmode -nographics -testResults test-results/playmode-results.xml -logFile Editor.log

3. 构建结束后，下载Editor.log产物文件，查看Unity编辑器的详细输出，寻找错误线索。
4. 终极方案：将复杂的、不稳定的Play Mode测试拆解，核心逻辑用单元测试覆盖，引擎交互部分如果必须测试，考虑使用更轻量级的测试框架或编写专门的、可独立运行的集成测试场景。

6.4 发布失败：Google Play API权限错误

现象：upload-google-play步骤失败，提示403 Forbidden或The caller does not have permission。排查：

1. 确认服务账号JSON密钥是否正确无误地配置到了GitHub Secret中。
2. 登录Google Play Console，进入设置 -> 开发者账号 -> API访问。确保你创建的服务账号已被添加，并且授予了至少“发布管理员”或“编辑”角色。特别注意：需要为服务账号授予对特定应用的权限，并在“用户和权限”部分为服务账号邮箱添加相应角色。
3. 在Google Cloud Console，确保已为服务账号启用了“Google Play Android Developer API”。

6.5 性能问题：构建时间过长

现象：每次构建都需要30分钟以上，大部分时间花在导入资源上。优化：

1. 确保Library缓存生效：检查缓存步骤的key是否稳定。如果UNITY_VERSION或项目结构（影响缓存键）频繁变动，缓存会失效。
2. 拆分流水线：将“代码检查-单元测试”作为一个快速流水线在PR时触发；将“资源导入-打包构建”作为另一个流水线，仅在合并到主分支后或定时触发。
3. 优化项目资源：检查是否有不必要的巨大资源文件。考虑使用AssetBundle动态加载，减少初始包体大小和导入时间。
4. 使用自托管Runner：如果GitHub托管的Runner性能不足，可以在自己更强大的服务器上部署Self-hosted Runner，这尤其适合需要大量CPU和内存的Unity构建。

搭建和维护一套顺畅的Unity CI/CD流水线，初期确实需要投入一些时间和精力去调试和优化。但一旦它稳定运行起来，所带来的开发效率提升、质量保障和团队协作的流畅度，会让所有投入都变得无比值得。它把开发者从重复劳动中解放出来，让大家能更专注于创造游戏内容本身。每当看到一次提交自动触发，并最终将新版本推送到测试人员手中，那种自动化带来的确定性和秩序感，是支撑现代高效游戏开发团队不可或缺的基石。