在 Xcode Cloud 中创建实用的工作流程

♪ ♪

Romain：大家好 我是 Romain 是 Xcode Cloud 的一名工程师 Xcode Cloud 是一个强大的工具 具有足够的灵活性 可以将它 直接集成到团队的开发过程中 Xcode Cloud 有助于 提高团队生产力 帮助他们 向客户提供更好的 App 本次讲座中 我将基于实际工作中可能出现的情况 讲解在 Xcode Cloud 中 如何创建工作流程 团队有各种形式和规模 拥有多样且独特的开发过程 为了帮助我们 设计一些实用的工作流程 我们将设想三个案例研究 这些案例都类似于 人们在使用 Xcode Cloud 时 可能遇到的常见情况

我们先来看一个独立开发者 开发单独 App 的案例 然后我们将逐步 组建一个处理遗留代码 和复杂开发过程的大型团队 在本次讲座里 我们将从众多选择中 展示一些适合任何团队 创建和自定义工作流程的方法

我们开始第一个案例研究 假设有一名独立开发者 他们有一款在 iOS 和 macOS 上都可用的 App 他们的大部分编码工作都是 在 main 分支上完成的 新的代码更改都推送到那里 当然 在尝试新的 API 和平台功能时 他们偶尔也会使用不同的分支 但在大多数情况下 他们使用的都是 main 分支 他们的代码依赖于几个依赖关系 他们选择用 Cocoapods 下载 并将其集成到项目中 最后 他们通过 TestFlight 将 App 构建版本 部署给一些朋友和家人 让他们测试 App 并提供反馈 他们时不时 在 App Store 手动发布 App 的新版本 这个开发者独自完成工作 从构建 App 到 在 App Store 上分发 App 一切都是他们自己管理 对他们来说 简单即是关键 他们需要能够依赖并保持的东西 有了 Xcode Cloud 他们推送新代码、 构建 App 和分发给测试员的整个过程 都可以在一个小型而强大的 工作流程中实现 在深入讲解这些工作流程之前 我们先停下来回想一下 Xcode Cloud 工作流程是什么 比如 可以是 构建你的 App、运行测试、 向测试员分发等等 “Where”就是你想要使用的 Xcode 版本和 macOS 版本 加上任何其他配置 如环境变量 它们共同构成了 运行工作流程的环境 最后 “when”就是 你希望这些操作什么时候发生

你是希望当你向特定的 分支推送代码时启动？ 或者说 每天下午四点启动？ 定义一个或多个启动条件 可以设定工作流程何时运行的标准 很好 现在我们回忆起来了 那么就将“what”、 “where”和“when”应用到 我们的独立开发者案例中吧 我将创建一个他们可以用来 自动化所有过程的 Xcode Cloud 工作流程 我这里有一个已经设置 在 Xcode Cloud 中的项目 在 report navigator 中 我选择 Cloud 图标并右击 我的产品名称 然后选择“管理工作流程”

这样就会打开我的工作流程编辑器 点击加号打开菜单 选择第一项 为我的 App 创建一个新的工作流程 在名称栏 我要输入“CI Workflow” 我将跳过描述栏 但你可以随意添加详细内容 现在 我们看一下“环境”的部分 在这个部分 我可以看到 默认选择的是 最新版本的 Xcode 和最新版本的 MacOS 看起来没问题 所以我不做任何更改 每个新工作流程 都有一个默认的启动条件 我们来看一下

每次更改被推送到 默认分支时 这个启动条件 都会创建一个构建版本 在这个例子中就是 main 分支 基本都正确了 但这个独立开发者 希望在代码被推送到 任何分支时都启动构建版本 而不仅仅是 main 分支 所以我要将“源分支”选项 改为“任何分支”

这个工作流程的目标 是构建和分发 App 我们需要一个归档操作 将要分发的构建版本准备好 我要点击“操作”部分旁边的加号 然后选择“归档”

可以看到 这里已经选择了 iOS 平台 所以我只要在“部署准备”部分中 选择“TestFlight 和 App Store” 选项就可以了

现在我们的工作流程将会生成 一个可以用于分发的构建版本 我要添加一个 post-action 将构建版本上传到 App Store Connect 为此 我要点击 “Post-Actions”部分的加号 选择“TestFlight 外部测试”

在这里 我要点击“分组”部分的加号 然后选择“朋友和家人”测试组

就像这样 我们马上就要完成了 我们的独立开发者开发的是 针对 iOS 和 macOS 的 App 所以我希望我们的工作流程能够 在两个平台上归档并发布 App 为此 我将添加另一个归档操作

选择 macOS 平台 “部署准备”选择 “TestFlight App Store”

然后再添加另一个 “TestFlight 外部测试”的 post-action

“工件”选择 “归档 - macOS”

然后选择相同的测试组

最后 点击“保存” 创建工作流程

我们之前说过 这个开发者使用 Cocoapods 来包含 App 所需的依赖关系 可开箱即用 Xcode Cloud 支持 Swift Package Manager 它是直接构建在 Xcode 中的 但其他依赖关系管理器 也可以在 Xcode Cloud 中使用 只需少量的配置即可 这里有一篇文档是关于如何使用 更普遍的依赖关系管理器的 这篇文档可以作为 如何使用其他管理器的指南 对独立开发者来说 文档中建议 使用克隆后的自定义脚本 安装并运行 Cocoapods 工具

自定义脚本提供了一种 在 Xcode Cloud 构建中 某个特殊节点运行额外操作的方法 在这个例子中 克隆后脚本 在所有源代码克隆到 临时构建环境中之后才运行 在后面的案例研究中 我们会看到另一个自定义脚本示例 这样独立开发者的 工作流程就完成了！ 下次他们推送代码的时候 Xcode Cloud 构建版本就会启动 App 就会在 iOS 和 macOS 中被归档 然后 一个新的构建版本 就会发送到朋友和家人小组手中 他们测试 App 并提供反馈 现在 我们更进一步 看看 第二个用例：一个中等规模的团队 我们想象一下 有一个团队 包括开发人员、 项目经理和 QA 工程师 他们位于世界各地 他们要构建一个 iOS App 适用于 iPhone 和 iPad 每个开发人员 都在自己的分支中工作 他们使用拉取请求将更改合并回 一个名为“beta”的分支 他们的内部 QA 团队安装并测试 该分支生成的构建版本 以确保 App 及其功能按预期运行

当他们想要发布 App 新版本的时候 将 beta 分支 合并到 release 分支 并推送一个新标签以标记这次发布 为了捕捉错误 避免回归 App 经过了仔细的 单元测试和 UI 测试 他们使用 TestFlight 在开发过程中的不同阶段 将 App 部署到 内部和外部测试人员 最后 他们在 Slack 上 对工作进行沟通协作 这是一个非常常见的例子 他们借助工具 并行地工作和协作 同时保持自己工作的高质量 这个过程可以通过 三个 Xcode Cloud 工作流程来实现 首先 我将创建 一个拉取请求工作流程 帮助更改上传到 beta 分支 然后 我将创建一个 beta 工作流程 将内部构建版本传递给 QA 团队 最后 我将创建一个最终工作流程 向外部测试员和 App Store 发布 App 新版本 我们按这个顺序 看一下每个工作流程 团队使用拉取请求来管理 将所有新代码更改 合并到其 App 中的工作 当一名开发人员打开一个拉取请求 他们的团队成员就会检查代码 并运行测试 确保 App 按预期运行 第一个工作流程是为了确保 当新的拉取请求打开时 或已有的拉取请求更新时 都会运行测试 我们来创建这个工作流程吧 首先 我要点击加号按钮 为我的产品创建一个新的工作流程 在名称栏输入“Pull Requests” 在这个工作流程中 团队希望当且仅当新的拉取请求 以 beta 分支为目标被打开时 Xcode Cloud 才会启动构建版本 他们要对每一个构建版本运行测试 我们先来添加一条新的启动条件 在“启动条件”部分点击加号按钮 选择“拉取请求更改”选项 默认条件下 它会 为任何分支启动构建版本 所以在“目标分支”部分 我要选择“自定义分支” 然后我要点击加号按钮 输入“beta”

我们仅请求一个启动条件 所以我可以删除“分支更改”

现在我要添加一个 新的操作来运行测试 点击“操作”部分旁边的加号按钮 选择“测试”

这个 App 以 iOS 和 iPadOS 为目标 所以团队希望能在 不同屏幕尺寸和功能的 设备上通过测试 在“目的地”部分 选择一个小尺寸的 iPhone、 iPhone 13 一个大尺寸的 iPhone、 iPhone 14 Pro Max

一个小尺寸的 iPad、iPad mini

最后选一个大尺寸的 iPad、iPad Pro

然后按“保存”

很好 现在 在 Xcode Cloud 上 成功构建之后 但愿团队成员也 做了详尽的代码审查 开发人员就可以 合并他们的拉取请求 将更改推送到 beta 分支 方便的是 这样就带我们 走入了下一个工作流程 beta 构建版本工作流程

beta 分支是放置 即将进行更改的地方 当开发人员合并拉取请求时 QA 团队希望获得包含 这些新更改的 App 构建版本 这样他们才能进行一些验证测试 向 QA 团队部署构建版本 是这个新工作流程的基础 我们回到 Xcode 并创建这个工作流程

这个 beta 工作流程集合了 我之前创建的几个工作流程 团队希望每当更改 合并到 beta 分支时 都发布一个构建版本 他们需要让这个工作流程 运行测试、归档 App 并将 App 上传到 App Store Connect 为了做到这些 我们要创建一个新的工作流程

命名为“Beta Release”

并相应地更新启动条件 我将选择已经存在的 “分支更改”启动条件 将分支从 main 改为 beta

然后添加一个归档操作

在“部署准备”中 选择“TestFlight 内部测试”

我们在这里使用内部分发 因为我们并不希望 这个构建版本错误地部署到产品 现在 我要添加一个构建后的操作 用于上传到 App Store Connect 这个 post action 将把 App 分发给 一组内部测试员 我将添加一个 “TestFlight 内部测试”的 post action

在“分组”部分点击加号按钮 选择“QA 团队”

好的 到这里本可以结束了 但我们不想冒险 部署一个损坏的构建版本 安全起见 我们将进行测试 也是工作流程的一部分 我将重复一遍 拉取请求工作流程中的测试操作 同样地 选择一个小尺寸 iPhone、 一个大尺寸 iPhone、 一个小尺寸 iPad

以及一个大尺寸 iPad

现在可以点击保存 完成工作流程的创建

beta 构建版本工作流程 将构建版本交付给 QA 团队 但团队还有一件事要做 他们希望 beta 构建版本 使用另一个 App 图标 这样他们就可以快速地确定 哪些是内部构建版本、 哪些是准备好发布到 App Store 的 这正是可以用到 Xcode Cloud 自定义脚本的情况

之前我们看到了一个 在克隆源代码后运行的自定义脚本 这里 我们使用一个 构建前脚本来更改图标

通过使用脚本中可用的环境变量 我可以确保 我们只在 beta 工作流程的 构建阶段更换图标 如果你想进一步了解 如何做到这一点 请参考 WWDC21 的讲座 “自定义你的 高级 Xcode Cloud 工作流程” 其中详细介绍了这个用例 我们只用到了 可用自定义脚本中的三种 如果你想知道其他可以使用的脚本 以及可用的环境变量 我们的文档将详细解释这一切 以上就是 beta 构建版本工作流程 现在我们来看一下该团队 最后一个工作流程 release 工作流程 团队在 beta 分支中 进行了大量更改 经过 QA 验证后 他们准备好了一个新的 release

他们的开发过程需要一个开发人员 将 beta 分支合并到 release 分支 然后创建一个标签标记发布 标签的名字必须以 release 开头 然后是版本号 完成后 App 会得到一个构建版本 上传到 App Store Connect 并分发给一组内部利益相关者 和一些急切的客户 第三个也就是最后一个工作流程 与 beta工作流程非常相似 唯一不同的就是要在推送 新的发布标签时创建构建版本 我们回到 Xcode 创建该工作流程 这个工作流程需要的步骤几乎 和创建 beta 工作流程是一样的 我可以再做一遍所有相同的步骤 比如创建启动条件 归档 App 等 但我想引导你 使用一项 Xcode Cloud 功能 用这个功能 我们可以复制 beta 工作流程 首先 右击“beta 工作流程” 选择“复制” 然后为工作流程重命名 从 Beta 改为 Release

然后我要添加一个新的启动条件 所以我要点击 “启动条件”部分的加号 选择“标签更改”

与分支更改类似 我不想每次推送标签 都创建构建版本 只有当标签以“release”开头时 才需要创建 我要在“标签”部分 选择“自定义标签” 输入“release/”

然后在菜单中选择 “以 release/ 开头的标签” 创建了这个启动条件后 我要回到已经存在的 “分支更改”启动条件 然后删除它 现在我们来到已有的归档操作 beta 工作流程是为了 在内部部署构建版本 特别是针对 QA 团队 但现在团队想为外部测试 和 App Store 准备 release 在“部署准备”部分 我要选择 “Testflight 和 App Store”选项 意思是 我们仍然需要 向利益相关者内部团队 部署构建版本 我要选择已有的构建后操作 并移除 QA 团队分组

然后点击加号 并选择“执行利益相关者”分组 最后一步 我要添加另一个 post action 但这次要选择 “TestFlight 外部测试” 点击“Post-Actions”部分的加号 然后选择“TestFlight 外部测试” 然后点击“分组”部分的加号 选择“早期采用者”分组

现在 release 工作流程 几乎就完成了 我们之前说过 这个团队使用 Slack 进行 彼此之间的沟通协作 对他们来说 如果能在 Slack 中获得构建版本的更新 那么将非常匹配他们的开发过程 尤其当构建版本失败不能发布时 这更加重要 让我们再为工作流程添加最后一步 在 release 工作流程中 点击“Post-Actions”部分的加号 选择“通知” Xcode Cloud 支持通过 电子邮件和 Slack 发送通知 点击 Slack 下面的加号 选择“发布 Feed”通道 然后按“OK” 这样我们第二个用例就完成了 这三个工作流程覆盖了 这个团队所有的开发过程 工作流程持续地 构建 App 并运行测试 让开发者能自信地工作 它们经常归档和分发 App 确保不同分组的人能提供反馈 这是一个十分常见的情况 有了适用于任何流程的工具的帮助 团队可以发布高质量的 App 我们通过第三个也是最后一个用例 来进一步支持这个说法 在该案例中 一个更大的团队 想要迁移到 Xcode Cloud 最后一个案例研究 我们假设有一个庞大的开发团队 这个团队与我们之前研究的中型团队 有很多相似之处 但多了一些转折 团队规模更大 代码库也更复杂 他们有一款适用 iOS 和 iPadOS 的 App 这个 App 自 App Store 成立以来就一直存在 从那时起已经被 重新设计和更新过很多次了 开发人员要处理 大量遗留代码和复杂性 尤其是在做 QA 的时候 他们有很多测试 最近 他们采用了一种 测试驱动的开发方法 每次有新的代码更改 都会添加许多新的测试

App 更新成功需要很多人参与 因此他们经常将新的构建版本分发给 内外部的各种 TestFlight 小组 以收集反馈 团队包括 在世界各地工作的开发人员 他们使用 Slack 来沟通协作 但有一个有趣的转折就是 他们已经依赖于持续集成 和持续部署来完成他们的工作 目前 他们使用由团队成员 维护和操作的内部解决方案 对系统的访问和了解是有限的 这使得问题难以调查 更难以解决 出于这类原因 他们考虑更换到 Xcode Cloud 代替他们的内部解决方案 另外 他们使用一个工程管理工具 来跟踪、协调 为正在做的工作划分优先顺序 他们还创建了各种仪表盘和状态页 这样一来 没有直接 参与 App 开发的人 也可以跟踪项目过程 Xcode Cloud 非常适合这类团队 但将如此复杂的项目迁移到 新的 CI 系统上是很困难的 而且可能会让人感到不知所措 面对这种情况 我的建议是将迁移过程 分解为不同的里程碑 每个里程碑都涉及在一段时间内 将工作量从现有系统 转移到 Xcode Cloud 重点就是保证迁移成功 同时让团队保持高效和愉快 我们不看工作流程配置 而是要看看里程碑都有哪些 我的建议是 将迁移分为不同的里程碑 第一步是创建一个工作流程 来构建可以发布到 App Store 的 App 版本 第二步是让测试可靠地运行 第三是建立剩余的工作流程 用于匹配和改进团队的开发过程 我们将详细了解这些步骤 首先从创建 release 工作流程开始

向 Xcode Cloud 迁移的时候 我建议首先创建一个工作流程 用于归档并上传 App 的 App Store 就绪版本 就像我们之前创建的工作流程示例 这个流程可以在对其他团队成员 零干扰的情况下实现 这样之后 你将能够 使用 Xcode Cloud 中 内置的云代码签名功能 无需使用证书 和配置文件来签署你的构建 这样也可以很好地了解 在依赖关系 和其他配置更改方面 成功构建 App 所需的内容 一旦准备好这个工作流程 就可以将它加入到 团队常规的开发过程中 这部分作为创建 App 的 App Store 就绪版本的过程 这是第一个从现有系统转移到 Xcode Cloud 上的工作量 接下来的重点是让测试可靠地运行 在持续集成系统中 测试可能非常棘手 通常 测试是经过定制的 只能在创建测试时 使用的 CI 环境中运行 在新的 CI 环境中运行时 它们可能无法可靠地运行 这样就会导致构建版本失败 在 Xcode Cloud 的创建期 我们考虑了这个问题 并构建了一个 我们认为可以真正帮助团队 顺利运行测试的功能 这个功能使 Xcode Cloud 忽略工作流程中 某些操作的失败 让构建继续完成

为了激活这个功能 要在工作流程操作中的 “必要条件”下 选择“不需要通过”选项 将操作指定为不需要通过 那么其结果就不会影响 Xcode Cloud 构建的最终结果 测试可能会失败 但构建仍然会成功 你仍然会在 Xcode Cloud 中 看到一个绿色复选标记 并且在源代码管理中 看到你构建的提交状态

这很有用 因为这意味着 你可以不断地 在关键路径之外运行测试 这样 你就可以汇总数据 来评估它们的表现是否足够可靠 让我们看看如何使用此功能 让测试在 Xcode Cloud 中工作

团队进行了很多测试 涵盖了 App 的许多方面 这种情况下 我建议开始创建一个 为所有拉取请求运行的新工作流程 在这个工作流程中 一个构建操作会运行所有的测试 但会标记为不要求通过 无论测试通过或失败 都暂时不会阻止 合并拉取请求 现在要做的是评估测试的可靠性 要记得 测试仍然在 现有的解决方案中运行 因此在一周左右后 仍然可以放心地合并拉取请求 团队可以查看拉取请求 构建版本中的测试结果数据 并看到哪些测试 在 Xcode Cloud 中可靠地通过了 这些测试可以转移到一个新的 测试计划中 名为 Reliable Tests 然后 团队可以编辑 现有的拉取请求工作流程 并添加一个新的测试操作 用于运行该特定测试计划中的测试 这次 在合并拉取请求之前 测试操作需要被通过 关于 Xcode Cloud 中 使用测试计划的更多信息 请参考 WWDC22 的讲座 “为 Xcode Cloud 编写 快速可靠的测试” 你也可以参考我们关于使用测试计划 改进代码评估的文档 对剩下的 目前运行不可靠的测试 可以做进一步调查 找出需要做哪些更改才能使其可靠 随着时间的推移和做出的更改 这些测试可以再次得到信任 它们最终可以移到 Reliable Tests 计划中 并再次用于验证更改 通过这种方法 你可以逐步将测试 转移到关键路径 并在 Xcode Cloud 工作流程中 提供验证和测试覆盖率

一旦你对测试的运行感到满意 就可以在 Xcode Cloud 中可靠地运行 App Store 构建版本和测试了 这两项工作就可以从 已有的 CI 解决方案中移除了 现在只剩下第三步 也就是最后一步： 构建团队开发过程 所需的其余工作流程 其中一些工作流程与我们之前 在讲座中的案例研究相似 通过自定义启动条件和操作 你可以创建一些 非常强大的工作流程 帮助实现 CI 和 CD 流程的自动化 我们还提到 该团队在其 CI 系统之外 还创建了工具和仪表盘 这些工具帮助他们 保持开发过程的优势 也可以与 Xcode Cloud 集成 比如 你可以使用 webhook 功能 配置 webhook 之后 每当一个构建版本完成 就会向服务器发送一个请求 包含有关该构建版本 及启动它的工作流程等内容的信息 然后 如果构建版本是从 beta 工作流程创建的 并且成功了 你就可以在任务管理系统中 创建一个新的票证 跟踪该特定构建版本的 QA 过程

如果你想进一步了解 关于 webhooks 的信息 特别是这些请求何时被发送 以及能够使用的信息有哪些 请参考我们的文档 另一个办法是使用 Xcode Cloud 公共 API 你可以获取有关最近构建版本的信息 以及其他信息 并将其显示在仪表盘或状态页上

同样 你可以参考这篇文档 了解如何使用 Xcode Cloud 的公有 API 以及如何整合进你的工作流程 Xcode Cloud 公有 API 和 webhook 机制 无论对于何等规模的团队来说 都是极其有用的功能 将所有可用的选项组合在一起时 可能性是无限的 在 WWDC22 的讲座 “深入了解面向团队的 Xcode Cloud”中 可以参考到更多示例 本次讲座中 我们介绍了 各类简单而强大的工作流程 这些工作流程 可以帮助你的团队提高工作效率 我们展示了一些关于 如何在构建的各个阶段 使用构建脚本 自定义构建过程的示例 最后 我们展示了一些功能 可以允许开发者 在 Xcode Cloud 的基础上构建工具 并与外部工具集成 我们希望这三个案例研究 可以帮助你理解 Xcode Cloud 如何适应你的团队 并改善你的日常工作 感谢观看 ♪ ♪