Highlight
Xcode Cloud 新增 Usage Dashboard 帮助团队监控和优化构建消耗，通过精细配置 Start Conditions、精简测试目的地和排除无关文件变更，可以在不降低质量的前提下显著减少 CI 计算用量。
核心内容
你的团队正在使用 Xcode Cloud，但每个月的计算额度消耗得很快。Release 工作流经常构建没有代码变更的版本，测试在大量相似的模拟器上重复运行，文档更新也触发了完整的构建流程。
（02:17）Session 用 Food Truck 项目演示了如何诊断和优化这些问题。
理解构建时长与用量
（02:25）Xcode Cloud 中两个关键指标：
- Duration：墙上时钟时间，从构建开始到结果呈现的总时长
- Usage：所有 action 的计算时间之和
因为 Analyze、Archive、Build、Test 等 action 是并行执行的，duration 等于最慢的那个 action 的时间，而 usage 是它们相加的总和。一次 14 分钟的构建可能消耗 32 分钟的用量。
（02:43）在构建详情中可以查看 usage distribution，看到每个 action 分别消耗了多少时间，这是优化的切入点。
Usage Dashboard
（03:55）App Store Connect 中新增的 Usage Dashboard 提供：
- 当前计费周期的总用量百分比和剩余额度
- 30 天构建数量和用量趋势
- 按产品查看用量分布
- 按工作流查看用量统计
（04:55）进入具体产品后，可以看到每个工作流的用量。Release 工作流通常是最值得优化的目标。
优化 Start Conditions
（05:34）Start Conditions 决定什么事件触发构建。Food Truck 的 Release 工作流原来使用 Scheduled 条件，定期构建，经常遇到没有新变更的情况。
（06:30）替换为 Branch Changes 条件：只在代码推送到远程分支时构建。进一步限制为只匹配 release/* 前缀的分支，避免 feature 分支的变更触发 Release 工作流。
（07:52）还可以排除特定文件夹的变更。Food Truck 的 docs 目录只包含开发文档，修改文档不需要触发构建：
- 在 Start Conditions 中选择 Files and Folders > Custom Conditions
- 选择 “Don’t start a build”
- 添加条件：Any Folder > docs
精简测试目的地
（09:08）测试 action 中，每个目的地并行运行。选择过多的模拟器会增加用量，同时引入相似设备上的噪声失败。
（09:31）Xcode Cloud 提供 “Recommended” 别名，是精心筛选的模拟器列表，覆盖不同屏幕尺寸的代表性设备。用 Recommended iPhones 替代手动选择的大量模拟器，既能保证测试覆盖面，又能减少用量。
跳过特定提交
（10:42）某些提交不需要触发 CI，比如只更新了 README。在提交消息末尾添加 [ci skip]：
git commit -m "Update README [ci skip]"推送后 Xcode Cloud 会忽略这个事件。注意必须使用确切的格式。
优化效果
（12:10）应用这些最佳实践后，Food Truck 的构建 duration 减少了 1 分钟，usage 减少了 4 分钟。Integration Workflow 长期运行后，用量趋势明显下降，腾出了额度用于新的 watchOS 工作流。
详细内容
Start Condition 配置
（06:40）Release 工作流的 Start Condition 配置示例：
Start Condition: Branch Changes
Source Branch: Custom Branches
- Branches beginning with: "release"
Files and Folders: Custom Conditions
- Don't start a build when: Any Folder = docs关键点：
- Branch Changes 只在代码推送时触发，避免 Scheduled 的空跑
- 自定义分支支持精确匹配或前缀匹配
- 文件排除支持精确文件路径或文件夹
- 多个条件之间是 AND 关系
测试目的地选择
（09:46）测试 action 的目的地配置：
Test iOS
Destinations:
- Recommended iPhones (替代 iPhone 8, iPhone 11, iPhone 12, iPhone 13...)关键点：
- Recommended 别名覆盖不同屏幕尺寸和特性组合
- 每个目的地独立运行测试，并行执行
- 相似设备上的测试失败通常是噪声，减少目的地可以降低误报
- 如果项目有设备特定的代码路径，可以额外添加对应目的地
Custom Scripts
（11:07）每个 action 在多个时间点执行自定义脚本：
# 清理未使用的依赖
brew cleanup
# 对不可靠的 API 请求进行重试
for i in {1..3}; do
curl -f https://api.example.com/data && break
sleep 5
done关键点：
- 脚本在 action 的 pre-build、post-build 等阶段执行
- 清理临时文件和缓存可以减少构建时间
- 对外部服务的请求添加重试逻辑，避免偶发网络问题导致构建失败
测试可靠性
（11:30）不稳定的测试（flaky tests）会导致反复重试构建，浪费大量用量。应该优先修复这些测试，而不是依赖重试。
常见的 flaky test 原因：
- 异步操作没有正确等待
- 测试之间共享状态
- 依赖外部服务或网络
- 时间敏感的断言
核心启发
-
做什么：为团队建立 Xcode Cloud 用量监控机制
-
为什么值得做：Usage Dashboard 让用量透明化，帮助识别浪费并合理分配额度
-
怎么开始：定期查看 App Store Connect 中的 Usage Dashboard，按工作流分析用量分布
-
做什么：为不同分支类型配置独立的工作流
-
为什么值得做：feature 分支只需要快速构建和测试，release 分支才需要完整的 archive 和 analyze
-
怎么开始：创建多个工作流，用 Start Conditions 的 Branch Changes 匹配不同分支前缀
-
做什么：在提交规范中引入 CI 跳过标记
-
为什么值得做：文档更新、配置文件调整等不需要完整 CI 流程的提交可以节省用量
-
怎么开始：在团队的 Git 工作流文档中添加
[ci skip]使用规范 -
做什么：为 watchOS companion app 配置独立的 Xcode Cloud 工作流
-
为什么值得做：watchOS 构建和测试与 iOS 独立，分开配置可以更灵活地控制触发条件和目的地
-
怎么开始：在 Xcode 的 Report Navigator 中创建新工作流，选择 watchOS 相关的 scheme 和测试计划
关联 Session
- Meet Xcode Cloud — WWDC21 Xcode Cloud 入门
- Deep dive into Xcode Cloud for teams — 团队 Xcode Cloud 深度使用
- Author fast and reliable tests for Xcode Cloud — 编写快速可靠的测试
评论
GitHub Issues · utterances