充分利用 Xcode Cloud

♪ ♪ Adam：嗨 我是 Adam 我是开发者体验团队的经理 Sasan：我是 Sasan 是 Xcode Cloud 团队的工程师 Adam：在今天的讲座中 我们将向您展示 如何充分利用 Xcode Cloud 的功能 通过查验现有工作流 并着重探讨全新的 Xcode Cloud 用量（Xcode Cloud Usage）仪表盘 之后 我们将看看 如何运用我们学到的知识 从查看现有项目的用量情况 到进一步优化它 然后开始为项目 开发新 watchOS App 版本 在开始之前 我们先 快速介绍一下 Xcode Cloud 在 WWDC 2021 上 我们发布了 Xcode Cloud 它是 Xcode 中内置的 持续集成和交付服务 专为 Apple 开发者设计 Xcode Cloud 让您能够 采用持续集成和交付 这是一种标准软件开发实践 能帮助您开发 和维护您的代码 并将 App 交付给测试人员和用户 Xcode Cloud 之所以能加速 高质量 App 的开发和交付 是通过汇集有助于 构建 App 的基于云的工具 并列运行自动化测试 将 App 交付给测试人员、查看 并管理用户反馈 并在实现这些的同时 对用户隐私进行保护 如果您想了解有关首次设置 Xcode Cloud 的更多信息 请查看 WWDC 2021 的 Meet Xcode Cloud 讲座 Holly 和 Geoff 详细介绍了 应该如何设置您的第一个工作流 现在 让我们来看看 Xcode Cloud 中 Food Truck App 的 现有工作流和构建 这是 App Store Connect 中的 Xcode Cloud 仪表盘 它展示了最近构建的 Food Truck 项目概览 我们最近决定添加 配套的 watchOS App 让流动餐车运营者可以 快速接收来自手表的订单 而无需在每次收到 新订单时都拿起手机 在我们开始在 Xcode Cloud 中构建新的 watchOS App 之前 我们想确保当前的 工作流和项目得到充分优化 以便尽快为我们提供 理想的构建和测试结果 我们认为可能有一些方法 可以用于 节约时间和资源

为了更好地了解我们可以从哪里开始 进行其中的一些优化 让我们来仔细看看 构建的详细信息概述 首先 我们注意到我们 在上午 9:15 开启构建 需要 14 分钟才能 完成并向我们展示结果 我们还看到了一个与用量相关的时间 在这个案例中是 32 分钟 这是我们 14 分钟的构建中所有操作 完成所花费的总时间 在用量旁边 您会看到一个选项 用于查看此构建的操作分布

每个操作都被分解 并列出了各自的用量 32 分钟的总时间显示在底部 用量分布让我们了解到某些地方 可能还需要进行优化 但在开始之前 让我们花点时间仔细看看 Xcode Cloud 如何执行这些操作 以及构建持续时间和用量之间的差异

每个构建都分解为一系列操作 视您工作流的设置而定 您可以看到 Xcode Cloud 将每个操作分解为多个并列操作 例如分析 存档 构建和测试 由于这些动作是并列执行的 构建的持续时间 等于最长操作运行时间 在这个案例中 也就是 我们在工作流中配置的 需要 14 分钟才能完成的测试 而在计算用量时 通过对每一个操作 按顺序观察 得出我们构建的 总计算用量 在本例中为 32 分钟 这就是 Xcode Cloud 计算给定构建持续时间 和用量的方式

现在 让我们在 App Store Connect 中看一下 Xcode Cloud 用量仪表盘 顶部是 Truck to Table 团队从月度周期开始 至今的用量概览 包括使用的总百分比 此外 我们还可以看到 以分钟为单位的总用量 以及团队当前周期中 可用的剩余计算量

在下方 我们可以看到专门 展示我们团队用量趋势的区域 按创建的构建 总体用量 以及过去 30 天内的 百分比增减划分 如果我们想查看不同时间段的用量 可以更改位于趋势区域 右上角的时间段

再往下一点 我们可以看到每个 使用 Xcode Cloud 的产品的用量 不过是在我们先前选择的时间段内 好的 让我们选择 Food Truck 这样就可以看到它的总用量明细

在这里 我们首先在 团队视图中看到相同的趋势 但现在具体到 Food Truck 项目 再往页面下方一点 我们可以看到每一个 工作流的用量统计 一眼看去 我发现 发布（Release） 工作流中 有几个非常适合进行优化的地方 现在 我要把时间交给 Sasan 他会在观察构建细节和计算用量之后 向我们展示几种优化项目的方法 向开发者们展示该怎么做吧 Sasan Sasan：谢谢您 Adam 让我们用 Food Truck 项目 来介绍一些使用 Xcode Cloud 的 最佳实践 这将使我们可以在新的 watchOS App 上快速开始迭代 工作流使用 开启条件（Start Conditions） 来定义何时开启构建 很重要的一点是 需要将 Start Conditions 配置为 使构建只为用于工作流的更改开启 让我们来看看如何将这种做法 应用到 Food Truck 项目的 Release 工作流中 但首先 我推荐您查看 Explore Xcode Cloud Workflows 讲座 了解更多详细信息

我在 Xcode 中打开的构建 与 Adam 之前向我们展示的一致 首先 让我在编辑器窗口中 打开 Release 工作流

我用右键轻点导航面板中的工作流 并选择 编辑工作流（Edit Workflow）

在编辑器窗口中 我可以看到组成工作流的 所有可配置的区域 包括 Start Conditions 区域 我们发现有时计划的构建 并不包含任何新的变化 为了处理这个问题 我们来添加一个新的开启条件 让分支更改替换现有的计划开启条件 这将确保我们不会创建重复的提交 我轻点加号按钮并选择 分支更改（Branch Changes）

现在 要删除计划的开启条件 我将选择它并轻点垃圾桶图标

Branch Changes 开启条件将在 每次有新提交被 推送到远程分支时运行 默认情况下 源分支（Source Branch） 配置为 任意分支（Any Branch） 这意味着对库的任意分支所做的更改 都将导致此工作流开启构建 由于我们的发布工作流被配置为彻底 我想限制这一点 以确保 只为我们的发布分支开启构建

我点击 自定义分支（Custom Branches） 可以立即看到 我需要指定自定义分支

我点击 添加（Plus）按钮 并输入分支名称

编辑器将允许我从确切的 分支名称或前缀中进行选择 在这个案例中 我们已知有多个发布分支 所以我会选择 以 release 开头的分支

接下来 我想要指定发布分支中 哪些文件和文件夹 可以开启构建 我的目标是在修改 docs 文件夹时不开启构建 此文件夹仅包含我们的开发文档 因此可以放心跳过 对 文件和文件夹（Files and Folders）选项 我选择 Custom Conditions

我选择 开启构建（Start a Build）下拉菜单 并选择 不开启构建（Don't start a build）

我点击 Plus 按钮添加一个新条件

我将通过选择 任意文件夹（Any Folder） 和 选择（Choose） 指定要排除的文件夹

最后 这将打开一个文件选择器 现在我可以选择 docs 文件夹并点击 打开（Open）

要完成这一步 我将点击 保存（Save） 以保留我的更改

我现在已将 Start Condition 配置得更具选择性 仅限于对使用 release 前缀的分支开启 并忽略对 docs 文件夹的更改 工作流还通过使用预定义的操作 定义了如何运行您的构建 操作允许您分析 存档 构建和测试您的更改 测试操作的一个重要组成部分 是测试目的地的选择 为确保快速交付结果 一旦构建了测试产品 每个目的地都将并列运行

我想确保为我的测试选择 一组简洁的模拟器目的地 除了加快我的构建速度 这也有助于减少在其他相似设备上 可能会产生故障的测试噪音

Xcode Cloud 为 推荐的目的端提供别名（Alias） 它们是一系列精选出的模拟器 用于表示屏幕尺寸的截面

让我们再次访问 Release 工作流 看看如何为 iOS 测试操作选择一套 合理的模拟器目的端 选择 测试 iOS（Test iOS）操作后 我们可以看到大量选中的测试目的端 要删除测试目的端 我将一一选择 然后点击 减号（Minus）按钮 然后我轻点最后一项的下拉菜单 并选择 推荐的 iPhone（Recommended iPhones）

同样地 我将点击 保存（Save） 以保留我的更改

现在我有一组测试目的端 这将有助于在引入回归时 提供清晰的信号

正如我们之前所讨论的 Xcode Cloud 将在您将新更改推送到 存储库时 运行您的工作流 有时 您可能想根据提交的更改类型 跳过 CI 中的构建 我们增加了实现这一点的能力 让我们在 Xcode 中看一下

要跳过 Xcode Cloud 中的提交 只需附加 ci skip 到提交信息的末尾 现在 当您向远端推送时 Xcode Cloud 就知道应忽略此事件

请确保您使用与此处显示的 ci skip 标签完全一致的格式

对于每项操作 自定义脚本均在多点执行 整理未使用的依赖项并弹性重试 已知不可靠的 API 请求 将确保构建快速且持续稳定地完成 如需有关自定义脚本 和其他高阶自定义的更多信息 请查看 Customize your advanced Xcode Cloud workflows 讲座

对于测试环节 您应当确保 不稳定和不可靠的测试 很快得到纠正 当不稳定测试失败时 本能反应是立即重试构建 根据您的测试套件的可靠性 这可能会导致多次重试构建 请确保花更多时间编写可靠的测试

如想了解更多关于 如何有效地做到这一点的信息 请查看我们的另一个讲座 Author fast and reliable tests for Xcode Cloud 到目前为止 我们已经 讨论了一些最佳实践 并将它们应用于 Food Truck 项目 让我们将之前的构建与我们更新后 工作流中的构建进行比较 看看这些变化产生了什么样的影响 这是在应用最佳实践后开启的构建 与 Adam 向我们展示的 之前的构建相比 持续时间减少了 1 分钟 但用量减少了 4 分钟 整体看来我们做了 一些相当不错的改进

让我们返回用量仪表盘 来更好地理解产生的影响

由于可能很难立即 看到单个构建的影响 我们已将最佳实践 应用于我们的另一个工作流 集成工作流 我们运行使用最佳实践的 构建已经有一段时间了 可以看出我们的改变是有效的 因为用量呈现出下降趋势

这意味着我们现在 能够添加更多工作流 并开始为开发 watchOS App 开启更多构建

使用用量仪表盘 您可以继续对 在现有项目和工作流中 采用相同的最佳实践 以充分发挥 Xcode Cloud 的功能 如需了解如何为大型团队 管理 Xcode Cloud 的更多信息 请查看 Deep Dive into Xcode Cloud for teams 讲座 希望您喜欢我们的讲座 Adam：感谢您的观看

♪ ♪