WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Create practical workflows in Xcode Cloud

Create practical workflows in Xcode Cloud

Xcode CloudCI/CDDeveloper ToolsWorkflow
观看原视频

Highlight

Xcode Cloud 通过”何时触发（Start Conditions）+ 执行什么（Actions）+ 在什么环境运行（Environment）“的三维配置模型，让个人开发者用单个 workflow 实现自动构建分发，让中型团队用三个 workflow（PR 验证 / Beta 内测 / Release 发布）覆盖完整开发流程，让大型团队通过”Not Required To Pass”测试模式平滑迁移遗留测试到云端。

核心内容

个人开发者：一个 workflow 搞定全部

一个人维护 iOS + macOS 双平台应用，用 CocoaPods 管理依赖，通过 TestFlight 给亲友测试。手动构建和分发占用大量时间。

Xcode Cloud 的解法是创建一个 CI Workflow：

  • 触发条件：任意分支的代码推送（Any Branch）
  • 构建动作：iOS 和 macOS 双平台 Archive，选择 “TestFlight and App Store” 部署准备
  • 后置动作：自动上传到 TestFlight 的 “Friends and Family” 测试组

CocoaPods 依赖通过 post-clone 自定义脚本处理。Xcode Cloud 原生支持 Swift Package Manager，其他依赖管理器只需在 ci_scripts/post_clone.sh 中安装即可。

（02:28）

中型团队：三个 workflow 分工协作

跨时区团队，有开发者、项目经理和 QA。工作模式：开发者在自己的分支开发，通过 PR 合并到 beta 分支，QA 测试后合并到 release 分支打 tag 发布。

PR Workflow：

  • 触发条件：目标分支为 beta 的 Pull Request
  • 动作：在 iPhone 13、iPhone 14 Pro Max、iPad mini、iPad Pro 四种设备上跑测试
  • 目的：合并前确保代码质量

Beta Release Workflow：

  • 触发条件：beta 分支的代码推送
  • 动作：先跑测试，再 Archive（选择 TestFlight Internal Testing）
  • 后置动作：分发给 “QA Team” 测试组
  • 自定义脚本：pre-build 阶段替换应用图标为 Beta 版本图标

Release Workflow：

  • 触发条件：tag 名以 “release/” 开头的推送
  • 动作：Archive（选择 TestFlight and App Store）
  • 后置动作：先分发给内部 “Executive Stakeholders”，再分发给外部 “Early Adopters”
  • 通知：构建完成后发送 Slack 消息到 “Releases Feed” 频道

（07:30）

大型团队：渐进式迁移策略

大型团队有复杂代码库和大量遗留测试，已经在用自建的 CI/CD 系统。直接全部迁移风险太高。

推荐分三步走：

  1. 先建 Release Workflow：把 App Store 归档构建迁到 Xcode Cloud，利用内置的云端代码签名（Cloud Code Signing），省去证书和描述文件管理
  2. 再迁测试：创建 PR workflow，把所有测试标记为 “Not Required To Pass”。测试失败不会阻塞合并，但可以收集测试可靠性数据。运行一段时间后，把稳定通过的测试移入 “Reliable Tests” Test Plan，再新建一个 Required 的测试动作只跑这些稳定测试。不稳定的测试继续修复，逐步迁移
  3. 最后补齐其他 workflow：利用 webhook 和 Xcode Cloud Public API 与现有的项目管理工具、Dashboard 集成

（19:12）

详细内容

Workflow 的核心概念

Xcode Cloud 的 workflow 由三个维度定义：

  • What（做什么）：Build、Test、Archive、Analyze 等 Actions
  • Where（在什么环境）：Xcode 版本、macOS 版本、环境变量
  • When（何时触发）：Branch Changes、Pull Request Changes、Tag Changes、Schedule

自定义构建脚本

Xcode Cloud 在构建的不同阶段提供钩子脚本，放在项目根目录的 ci_scripts/ 文件夹中：

脚本名执行时机用途
ci_post_clone.sh代码克隆完成后安装依赖（如 CocoaPods）
ci_pre_xcodebuild.shXcode 构建开始前修改构建配置（如替换图标）
ci_post_xcodebuild.shXcode 构建完成后上传额外产物、发送通知

Beta 图标替换脚本示例

（14:38）

#!/bin/sh
# ci_pre_xcodebuild.sh

if [[ "$CI_XCODEBUILD_ACTION" == "archive" && "$CI_WORKFLOW" == "Beta" ]]; then
    echo "Replacing app icon with beta icon"
    mv BetaAppIcon.appiconset ../App/Assets.xcassets/AppIcon.appiconset
fi

关键点：

  • CI_XCODEBUILD_ACTION 环境变量标识当前执行的动作（archive / build / test 等）
  • CI_WORKFLOW 环境变量标识当前 workflow 的名称
  • 通过条件判断只在 Beta workflow 的 Archive 阶段替换图标
  • 脚本放在 ci_scripts/ci_pre_xcodebuild.sh，Xcode Cloud 会自动识别执行

”Not Required To Pass” 测试迁移模式

（23:21）

大型团队迁移测试时的核心痛点：测试在旧 CI 环境中稳定运行，但在新环境中可能因时序、资源等差异失败。如果直接设为 Required，会阻塞正常开发。

Xcode Cloud 允许把测试 Action 的 Requirement 设为 “Not Required To Pass”：

  • 测试失败不会导致构建失败
  • PR 仍可以合并
  • 团队可以观察测试在新环境中的稳定性

运行一段时间后，把稳定通过的测试移入新的 Test Plan，再创建一个 Required 的测试 Action 专门跑这些测试。不稳定的测试逐个修复，逐步迁移到 Required。

Webhook 与 Public API 集成

（26:44）

Xcode Cloud 支持两种外部集成方式：

Webhook：构建完成后向指定 URL 发送 HTTP 请求，包含构建状态、workflow 信息、提交信息等。可以在自己的服务器上接收后创建工单、更新 Dashboard。

Public API：通过 App Store Connect API 查询构建历史、获取构建详情、下载构建产物。适合在内部 Dashboard 或状态页展示构建数据。

工作流复用技巧

（16:16）

Xcode Cloud 支持右键复制 workflow。Release workflow 和 Beta workflow 通常高度相似，可以直接复制后修改：

  • 改触发条件（Branch Changes → Tag Changes）
  • 改部署准备选项（Internal Testing → TestFlight and App Store）
  • 改测试组（QA Team → Executive Stakeholders + Early Adopters）
  • 加通知渠道（Slack / Email）

核心启发

1. 为不同分支自动切换应用配置

做什么：根据构建目标（Debug / Beta / Release）自动切换 Bundle ID、应用图标、API endpoint。

为什么值得做：避免手动维护多个 target 或 scheme，减少配置错误。Xcode Cloud 的自定义脚本 + 环境变量让这件事完全自动化。

怎么开始：在 ci_pre_xcodebuild.sh 中根据 CI_WORKFLOW 和 CI_BRANCH 环境变量，用 plutil 修改 Info.plist 中的 API endpoint，用 mv 替换 AppIcon。

2. 构建失败自动创建 Jira/Linear 工单

做什么：Xcode Cloud 构建失败时，自动在项目管理工具中创建修复工单并指派给相关开发者。

为什么值得做：大型团队中构建失败容易被忽略。通过 webhook 接收构建状态，自动创建工单可以确保问题被跟踪和修复。

怎么开始：配置 Xcode Cloud webhook 指向自己的服务器，解析构建失败信息，调用 Jira/Linear API 创建工单。commit author 可以从 webhook payload 的 scmCommit.author 字段获取。

3. 测试稳定性 Dashboard

做什么：用 Xcode Cloud Public API 拉取历史构建数据，生成测试通过率趋势图。

为什么值得做：“Not Required To Pass” 模式下的测试数据可以量化哪些测试不稳定，帮助团队优先修复 flaky test。

怎么开始：用 App Store Connect API 的 /ciBuildRuns 端点获取构建历史，统计每个测试用例的失败率和失败原因，用 Grafana 或自建页面展示。

4. PR 构建时间优化

做什么：根据 PR 修改的文件路径，只跑相关的测试子集。

为什么值得做：大型项目测试套件可能跑几十分钟。通过分析 git diff 中的修改文件，只触发相关模块的测试，可以大幅缩短 PR 反馈时间。

怎么开始：在 PR workflow 的 pre-build 脚本中用 git diff 分析修改文件，结合测试映射表（如 Models/ 目录修改只跑 Model 测试），动态生成 Test Plan 并传入 xcodebuild。

关联 Session

评论

GitHub Issues · utterances