Explore Xcode Cloud workflows

Highlight

Xcode Cloud 工作流把启动条件、构建环境、构建动作和后续分发串在一起，让团队在 Xcode 和 App Store Connect 中自动完成构建、分析、测试、归档和 TestFlight 分发。

核心内容

团队开发 App 时，最怕变更合并以后才发现问题。有人忘了跑测试，有人只在自己的机器上验证，有人改了 Pull Request 后没有重新检查。最后，主分支承担了所有风险。

Fruta 团队已经有一个默认工作流，用来构建 main 分支。但他们还使用 Pull Request。合并前，团队需要知道这次改动和 main 合在一起是否能编译、测试、归档，还需要把构建结果发给团队成员。

Xcode Cloud 的工作流解决这个问题。它把一次 CI/CD 流程拆成几个可配置部分：什么时候运行、在哪个 macOS 和 Xcode 环境运行、执行哪些动作、结束后通知谁、是否分发到 TestFlight。

Pull Request 合并前验证

以前，Pull Request 的验证常常依赖开发者自觉。有人会本地跑测试，有人只看代码 diff。即使每个人都认真检查，本地环境也可能不同。

Xcode Cloud 可以把启动条件设为 Every Change to a Pull Request。源分支可以是任意分支，目标分支设为 main。每次有人创建或更新 Pull Request，工作流都会自动运行，并且构建源分支和目标分支合并后的结果。

这个设置直接把风险前移。团队在合并前就能看到真实影响，不用等 main 分支坏掉以后再回头定位。

构建环境由工作流固定

本地构建的另一个问题是环境差异。某个人使用新版 Xcode，另一个人还在旧版本。某些问题只在干净构建时出现，增量构建可能掩盖它。

Xcode Cloud 的 Environment（环境）区域允许选择 macOS 和 Xcode 版本，也可以选择 Latest Release 或 Beta。工作流还可以选择增量构建或 Clean 构建。Pull Request 场景可以使用增量构建换取速度；发布场景可以使用 Clean 构建保证产物从头生成。

这样，团队不用追问“你本地是什么环境”。工作流本身就是环境说明。

动作和后续操作分离

一次工作流的核心任务由 Actions（动作）定义。这个 session 重点展示了 Archive、Test、Analyze 和 Build。它们覆盖了 Xcode 本地常用的构建操作。

工作流完成这些动作后，再执行 Post-actions（后续操作）。Xcode Cloud 支持发送通知，也支持把归档产物部署到 TestFlight 内部或外部测试组。

这个拆分让流程更清楚：先验证代码，再通知团队，再把可安装版本交给测试人员。

详细内容

1. 用 Start Condition 触发 Pull Request 工作流

（03:37）Start Condition（启动条件）定义工作流什么时候运行。演讲中的 Pull Request 工作流选择 Every Change to a Pull Request，源分支选择 Any Branch，目标分支选择 Main。

workflow:
  name: Pull Requests
  startCondition:
    type: Every Change to a Pull Request
    sourceBranch: Any Branch
    targetBranch: Main
    autoCancelPreviousBuilds: true

关键点：

name：工作流名称。演讲中命名为 Pull Requests。
type：触发类型。Every Change to a Pull Request 会在 Pull Request 创建或更新时运行。
sourceBranch：源分支。Any Branch 允许团队成员从任意分支发起 Pull Request。
targetBranch：目标分支。这里设置为 Main，对应合并目标。
autoCancelPreviousBuilds：演讲提到可以取消之前正在运行的构建，适合连续推送多个提交的场景。

（04:30）Pull Request 构建时，Xcode Cloud 会构建和测试源分支与目标分支的合并结果。团队看到的是合并后的真实状态。

Pull Request build input:
  source: feature branch
  target: main branch
  build: merged source + target

关键点：

source：开发者正在提交的功能分支。
target：团队准备合入的主分支。
build：Xcode Cloud 检查合并结果，减少合并后才失败的情况。

2. 配置 Xcode、macOS、Clean 构建和环境变量

（05:24）Environment（环境）定义工作流如何运行。Xcode Cloud 运行在 Apple 的云基础设施上，可以选择 macOS 和 Xcode 版本。

environment:
  xcode: Latest Release
  macOS: selected in workflow editor
  clean: false

关键点：

xcode：可以指定具体版本，也可以选择 Latest Release 或 Beta。
macOS：在工作流编辑器中选择构建所用的 macOS 版本。
clean：Pull Request 工作流可以关闭 Clean，利用增量构建缩短时间。

（06:18）Clean 构建会从头编译。演讲说明，部署到 TestFlight 外部测试者或提交 App Store 的构建需要 Clean。

releaseEnvironment:
  clean: true
  reason:
    - External Beta Testing with TestFlight
    - App Store submission

关键点：

clean: true：不使用已有派生数据，从头生成构建产物。
External Beta Testing with TestFlight：外部 TestFlight 测试需要干净构建。
App Store submission：提交 App Store 的发布流程也需要干净构建。

（07:28）Environment 还可以配置环境变量，并把敏感变量标记为 secret。

environmentVariables:
  - name: API_CONFIGURATION
    value: staging
    secret: false
  - name: SERVICE_TOKEN
    value: stored in Xcode Cloud
    secret: true

关键点：

API_CONFIGURATION：普通环境变量，适合控制构建配置。
SERVICE_TOKEN：敏感信息，适合 API token 这类不应提交到仓库的值。
secret: true：演讲提到 secret 标记会提供额外保护。

3. 用 Actions 执行归档、测试和静态分析

（08:12）Actions（动作）定义工作流每次运行要做什么。Xcode Cloud 支持本地 Xcode 的关键动作：Build、Analyze、Test、Archive。

actions:
  - type: Archive
    platform: iOS
    scheme: Fruta iOS
  - type: Test
    requiredToPass: true
    testSource: Use Scheme Settings
    simulators: Recommended
  - type: Analyze
    requiredToPass: false

关键点：

Archive：创建归档产物，为 TestFlight 或 App Store 分发做准备。
platform：演讲中的示例选择 iOS 平台。
scheme：演讲中的示例使用 Fruta 的 iOS scheme。
Test：在云端稳定环境运行测试，释放本地机器。
requiredToPass：测试或静态分析可以设置为是否影响整体构建结果。
Use Scheme Settings：测试可以沿用 Xcode scheme 中的设置。
Recommended：Xcode Cloud 提供推荐模拟器集合，覆盖不同屏幕尺寸。

（09:55）Test action 可以选择特定 test plan，也可以选择推荐模拟器或指定模拟器。指定模拟器时，还能选择旧系统版本。

testAction:
  source: Use Scheme Settings
  alternative: Select a test plan
  destinations:
    option: Recommended
    coverage: different screen sizes

关键点：

source：使用 scheme 设置，适合复用本地测试配置。
alternative：选择 test plan，适合只跑某一组测试。
destinations：定义测试设备。
coverage：推荐模拟器集合覆盖不同屏幕尺寸。

（11:06）Analyze action 会运行静态分析。演讲建议用它发现编译器能识别的 bug 类别，避免问题在团队中积累。

analyzeAction:
  type: Analyze
  requiredToPass: false
  purpose: monitor static analysis results

关键点：

type: Analyze：运行静态分析。
requiredToPass: false：演讲中的 Pull Request 示例只监控结果，不让静态分析失败影响整体构建状态。
purpose：用于持续观察静态分析问题，避免长期累积。

4. 用 Post-actions 通知团队并部署到 TestFlight

（12:35）Post-actions 在 Build、Analyze、Test、Archive 都完成后运行。Xcode Cloud 支持通知和 TestFlight 部署。

postActions:
  - type: Notify
    buildSuccess: All
    buildFailure: All
    slackChannels:
      - ci-builds
    emails: []

关键点：

Notify：发送构建通知。
buildSuccess: All：所有成功构建都通知。
buildFailure: All：所有失败构建都通知。
slackChannels：演讲中选择 Slack 的 ci-builds 频道。
emails：可以加入群组邮箱或需要接收非本人构建通知的用户。

（14:42）TestFlight 部署分为内部测试和外部测试。内部测试可以把 Pull Request 产生的构建快速发给开发团队成员。

archiveAction:
  deployment: TestFlight Internal Testing Only

postActions:
  - type: TestFlight Internal Testing
    artifact: Archive iOS
    groups:
      - QA team

关键点：

deployment：Archive action 需要设为 TestFlight Internal Testing Only。
TestFlight Internal Testing：添加内部测试后续操作。
artifact：选择归档产物。演讲中 Archive iOS 已经预选。
groups：选择 App Store Connect 中已有的内部 TestFlight 组。

（17:25）外部 TestFlight 测试有更严格条件：启动条件选择单一分支，环境选择 Clean，Archive 部署设置为 TestFlight and App Store。

externalTestingWorkflow:
  startCondition:
    branch: release
  environment:
    clean: true
  archiveAction:
    deployment: TestFlight and App Store
  postAction:
    type: TestFlight External Testing
    targets:
      - external groups
      - individual testers

关键点：

branch: release：外部测试建议使用单一分支，保证构建来源一致。
clean: true：从头构建，避免派生数据影响产物。
TestFlight and App Store：Archive action 必须准备好 TestFlight 和 App Store 分发。
external groups：可以部署到外部测试组。
individual testers：外部测试还支持部署给单个测试者。

5. 三种推荐工作流策略

（18:47）演讲最后给出三类工作流：Pull Request、Release、Overnight Testing。它们分别服务于合并前验证、发布候选验证和夜间深度测试。

workflows:
  - name: Pull Requests
    trigger: Every Change to a Pull Request
    actions:
      - Archive
      - Test
      - Analyze
    postActions:
      - Notify
      - TestFlight Internal Testing

  - name: Release
    trigger: Every Change to a Branch on Release
    environment:
      clean: true
      xcode: pinned version
      macOS: pinned version
    actions:
      - comprehensive tests
      - Archive with TestFlight and App Store
    postActions:
      - TestFlight External Testing

  - name: Overnight Testing
    trigger: On a Schedule for a Branch
    schedule: Monday through Friday at 1:00 a.m.
    actions:
      - required test plans on multiple simulators
      - required Analyze
    postActions:
      - Notify failures to QA

关键点：

Pull Requests：合并前自动验证，并把构建交给 QA 团队测试。
Release：发布分支使用 Clean 构建、固定 Xcode 和 macOS 版本，再发给外部 TestFlight 测试者。
Overnight Testing：工作日凌晨定时运行更多测试和静态分析，只在失败时通知 QA。

核心启发

1. 给每个 Pull Request 自动生成内部测试包

做什么：每次 Pull Request 更新后，自动归档 App，并发给内部 QA TestFlight 组。
为什么值得做：演讲展示了 Pull Request 工作流可以构建合并结果，也可以部署到内部 TestFlight 组。
怎么开始：启动条件选 Every Change to a Pull Request，目标分支设为 main，添加 Archive action，把部署选项设为 TestFlight Internal Testing Only，再添加 TestFlight Internal Testing post-action。

2. 给发布分支固定工具链

做什么：为 release 分支创建单独工作流，固定 Xcode 和 macOS 版本，开启 Clean 构建。
为什么值得做：演讲中的 Release Workflow 用固定工具链收敛发布环境，用 Clean 构建排除缓存影响。
怎么开始：启动条件选 release 分支，Environment 中选择具体 Xcode 和 macOS 版本，勾选 Clean，Archive action 选择 TestFlight and App Store。

3. 把长测试移到夜间运行

做什么：创建 Overnight Testing 工作流，在工作日凌晨运行多个 test plan 和模拟器组合。
为什么值得做：演讲指出定时工作流适合长时间测试，团队白天继续开发，夜里让 Xcode Cloud 完整检查。
怎么开始：Start Condition 选择 On a Schedule for a Branch，频率设为 Monday through Friday at 1:00 a.m.，Test action 选择需要通过的 test plan 和模拟器，失败时通知 QA Slack 频道。

4. 让静态分析成为持续信号

做什么：在 Pull Request 或夜间工作流中加入 Analyze action，持续观察静态分析结果。
为什么值得做：演讲提到静态分析常被本地迭代流程跳过，问题会在团队中累积。
怎么开始：添加 Analyze action。早期可以把 Required to Pass 关闭，只监控结果；问题收敛后，再把它改成必须通过。

5. 用通知策略减少噪音

做什么：按工作流类型设置不同通知规则。Pull Request 全部通知，夜间测试只通知失败。
为什么值得做：演讲展示了通知可以分别配置成功和失败事件，并发送到 Slack 或 email。
怎么开始：Pull Request 工作流把 Build Success 和 Build Failure 都设为 All；夜间测试把 Build Success 设为 Don’t Notify，Build Failure 设为 All，目标选择 QA Slack 频道。

关联 Session

Meet Xcode Cloud — 介绍 Xcode Cloud 的基础概念、首个工作流和构建报告。
Customize your advanced Xcode Cloud workflows — 继续讲环境变量、自定义脚本、多仓库依赖和 Webhook。
Distribute apps in Xcode with cloud signing — 解释 Xcode 分发流程和云签名，补足 Archive 到分发的细节。
Review code and collaborate in Xcode — 讲 Xcode 的 Pull Request 和代码评审能力，适合和 Pull Request 工作流一起看。

Highlight

核心内容

Pull Request 合并前验证

构建环境由工作流固定

动作和后续操作分离

详细内容

1. 用 Start Condition 触发 Pull Request 工作流

2. 配置 Xcode、macOS、Clean 构建和环境变量

3. 用 Actions 执行归档、测试和静态分析

4. 用 Post-actions 通知团队并部署到 TestFlight

5. 三种推荐工作流策略

核心启发

1. 给每个 Pull Request 自动生成内部测试包

2. 给发布分支固定工具链

3. 把长测试移到夜间运行

4. 让静态分析成为持续信号

5. 用通知策略减少噪音

关联 Session

评论