Create practical workflows in Xcode Cloud
Developer Tools 进阶 20m

在 Xcode Cloud 中创建实用工作流

Create practical workflows in Xcode Cloud

2023年6月5日

在 Apple 官方观看视频

一句话判断

通过三个真实量级的案例——个人开发者、中型团队、大型企业——这场 Session 展示了 Xcode Cloud 工作流如何从”一个 workflow 搞定一切”平滑演进到”多分支、多环境、多平台”的复杂 CI/CD 体系。

这场 Session 讲了什么

Xcode Cloud 团队的 Romain 通过三个递进的案例演示了如何设计 Xcode Cloud 工作流。

案例一：个人开发者。一个人维护一个跨 iOS 和 macOS 的应用，用 CocoaPods 管理依赖，通过 TestFlight 分发给亲友测试。针对这种场景，一个 workflow 就够了：代码推送到任意分支时触发归档，自动构建两个平台的包并上传到 TestFlight。CocoaPods 依赖通过 post-clone 自定义脚本处理。

案例二：中型团队。有开发者、项目经理和 QA，用 PR 合并到 beta 分支，经过 QA 测试后合并到 release 分支打 tag 发布。团队用 Slack 协作。这种场景需要三个 workflow：PR workflow（跑测试、做代码质量检查）、beta workflow（构建并分发给内部 QA）、release workflow（打 tag 后构建并发布到 App Store）。通过 Slack 集成通知构建状态。

案例三：大型企业团队。处理遗留代码，有复杂的依赖关系和严格的发布流程。需要在多环境（开发、预发布、生产）中运行，处理多种依赖管理器，可能需要自定义构建脚本和并行化测试。

值得深挖的点

工作流设计的”三个 W”框架：What（做什么：构建、测试、分发）、Where（在哪做：Xcode 版本、macOS 版本、环境变量）、When（什么时候做：分支推送、定时触发、PR 创建）。这个框架让工作流设计变得结构化。

自定义构建脚本的时机选择：post-clone 脚本适合安装依赖（如 CocoaPods），pre-build 脚本适合做代码生成或配置。Xcode Cloud 在构建过程的不同阶段提供了挂载点，让你可以插入自定义逻辑。

CocoaPods 的集成方案：Xcode Cloud 原生支持 Swift Package Manager，但 CocoaPods 也完全可行——只需在 ci_scripts/post_clone 脚本中执行 pod install。文档中有常用依赖管理器的配置指南。

多平台构建的独立归档：iOS 和 macOS 需要分开的 Archive action，每个平台有自己的构建产物和分发配置。TestFlight External Testing 的 post-action 需要分别关联对应平台的 artifact。

代码片段

#!/bin/sh
# ci_scripts/post_clone.sh - 安装 CocoaPods 依赖
# 此脚本在 Xcode Cloud 克隆源代码后自动执行

# 安装 CocoaPods
gem install cocoapods

# 执行 pod install
cd "$CI_PRIMARY_REPOSITORY_PATH"
pod install
#!/bin/sh
# ci_scripts/post_clone.sh - 多依赖管理器支持

# 安装 CocoaPods
gem install cocoapods

# 安装 SwiftLint 用于代码质量检查
brew install swiftlint

# 运行依赖安装
cd "$CI_PRIMARY_REPOSITORY_PATH"
pod install
# Xcode Cloud 工作流配置概览

# 中型团队的三个 workflow:

# 1. PR Workflow
#   触发条件: PR 到 beta 分支
#   动作: Build + Test (单元测试 + UI 测试)
#   后置动作: 无（只做验证）

# 2. Beta Workflow
#   触发条件: 推送到 beta 分支
#   动作: Archive (iOS)
#   后置动作: TestFlight Internal Testing → QA 团队
#            Slack 通知

# 3. Release Workflow
#   触发条件: 推送 tag (格式: v*)
#   动作: Archive (iOS)
#   后置动作: TestFlight External Testing → 外部测试员
#            App Store 提交
#            Slack 通知

最佳实践

  • 从小开始，逐步扩展：个人开发者用一个 workflow 就够了。团队增长后再拆分出专门的工作流，不要一开始就过度设计。
  • 用 PR workflow 守住质量门：每个 PR 都跑测试，合并前就有信心代码不会破坏主分支。这是 CI 的最低要求。
  • 利用 Slack 集成减少沟通成本：构建成功或失败时自动通知团队，避免手动检查构建状态。Xcode Cloud 原生支持 Slack webhook。
  • 为不同环境设计不同 workflow：开发、测试、生产各有各的触发条件和分发策略，不要混在一起。
  • 自定义脚本放在 ci_scripts 目录下：Xcode Cloud 会自动识别这个目录下的脚本并按阶段执行。命名约定是 post_clone.sh、pre_build.sh 等。

还有什么值得关注

  • Xcode Cloud 默认使用最新的 Xcode 和 macOS 版本，但你也可以指定特定版本——这对需要稳定构建环境的团队很重要。
  • 大型团队的案例中提到了并行化测试的能力，可以显著缩短构建时间。
  • 工作流支持环境变量配置，可以安全地存储 API key 等敏感信息，不必硬编码在代码中。
  • TestFlight 的 External Testing 和 Internal Testing 是不同的分发渠道，前者面向外部测试员，后者面向团队内部——选择哪个取决于你的测试流程。
  • Session 没有深入讲自定义 CI 脚本的高级用法，但提到了 Xcode Cloud 文档中有详细的依赖管理器集成指南。
WWDC 2023