深入了解适用于团队的 Xcode Cloud

♪ 迷幻音乐 ♪

John：您好 我是 John 我是 Xcode Cloud 团队的工程师 Jo：我是 Jo Lynn Xcode Cloud 团队的设计师 John：今天我们来看看 Xcode Cloud 的一些 在团队中使用时非常有用的功能 无论团队有 5 人还是 500 人 Jo：我将分享一些在团队中 使用 Xcode Cloud 时 表现出色的其他功能和最佳实践 在今天的讲座中 我们将详细介绍 其他讲座中也涉及的一些主题 如果您想了解有关 Webhook 和其他高阶工作流主题的更多信息 请查看 Customize your advanced Xcode Cloud workflows 讲座 在今天的讲座中 我们将了解如何将 Xcode Cloud 集成到您日常已在 使用的工具和技术中 如何轻松管理您的代码依赖项 并展示 Xcode Cloud 最佳实践 如何帮助您设置工作流 持续有效地构建 测试和分发您的 App

让我们开始吧 在将 Xcode Cloud 集成 到您现有的工具中时 我们有几个选择 Webhook 允许与支持 它们的工具和服务轻松集成 您可以在 App Store Connect 中 连接 Webhook 只需要告知 Xcode Cloud 将 Webhook 发送到哪个 URL 您就可以立即 看到那些 Webhook 进来

我们的 API 还给了 您的构建极高的可见度 让您可以轻松地创建构建仪表盘 提取您的构建工件 以及 在我们今天的示例中 将构建信息集成到您现有的软件中

我们一直在为 Food Truck App 构建一系列新功能 但我们也一直在寻找新的错误 现在有一整个团队 一起开发这个 App 我们发现很难了解谁在做什么

为了解决它 我们决定使用问题跟踪器 来跟踪我们 App 中 正在进行的所有工作 如果您正在使用问题跟踪器 通常会看到这样的视图 问题跟踪器的常见 工作流是先创建票证（Ticket） 让设计师和开发者在该票证上工作 最后在功能或错误完成后关闭它 让实际的构建信息 在问题跟踪器中显示 非常有助于将所有点串联在一起 让我们看看现在可以如何做到这一点 我们的计划是创建一个基于 Swift On Server 的简单服务 它将处理我们在将问题跟踪器 与 Xcode Cloud 集成时 需要的一切 为了加快开发速度 我们将使用 Vapor Web 框架 使我们可以专注于 编写 Webhook 处理代码 基本流程看起来就像这样 一个 Webhook 将从 Xcode Cloud 传到我们的服务器 我们将读取 该 Webhook 并检查提交者 编写的提交消息中有某个字符串 映射到我们跟踪器中的问题 如果属实 我们将 使用 Xcode Cloud API 收集有关构建的更多信息 然后我们将构建一个 可以发布到问题跟踪器（Issue Tracker）的注释 其中包含了我们感兴趣的信息

接下来 我们将在 问题跟踪器上调用一个 API 它将针对我们的问题保存消息 首先 让我们看一下 Xcode Cloud API 文档 所有 Xcode Cloud API 都 位于 App Store Connect API 下 如果我们已经为 App Store Connect API 设置了身份验证标记（Authentication Tokens） 那么我们也就做好了访问 Xcode Cloud 数据所需的一切准备 打开 Build Runs 集合 可以看到一些让我们 与构建进行交互的端点 您可以调用端点来创建构建 取消构建 或获取有关 特定构建的更多信息 例如 如果您想创建仪表盘 来显示构建的状态 只需要调用 Ci_Build_Runs 端点 接下来 我们来看一下 文档中的 Artifacts 集合 对于工作流 我们希望将构建工件 保留在 Xcode Cloud 之外 API 可以提供我们需要的一切来实现它 首先 我们可以从 构建操作端点获取工件 ID 这将返回给定操作生成的所有工件 然后我们可以调用 ci_artifact 它会给我们所需的 URL 以在 downloadUrl 属性中 下载我们的工件 让我们从下载来自 App Store Connect 文档的 openAPI 规范开始 并检查我们为 API 创建客户端所需的内容

让我们创建一个新目录 可以在其中创建客户端代码 我将称之为 xcodecloud-client 现在我们需要为生成器 下载命令行工具 在 openAPI 网站上有很多方法 可以做到这一点 为了今天的讲座 我已经提前设置好了 让我们将 刚刚得到的 openAPI 规范 从 app_store_connect_API 复制到我们的目录 很好 现在我们 可以调用 openAPI 生成器 并要求它为我们的 API 创建一个 Swift 客户端

在生成器运行时 我们可以快速谈一谈它在做什么 一个 openAPI 规范由关于 构成 API 的所有路径 和模型的信息组成 生成器正在遍历每个 API 路径 并使用强类型的 Swift 对象 生成可以与 特定路径对话的 Swift 代码 在大多数情况下 这意味着您不必进行 任何 JSON 编码或解码 很好 我们的生成器已经完成了工作 让我们快速浏览一下它创建的文件 很方便的一点是 客户端代码是一个 Swift 软件包 这使它很容易包含在 将更新我们问题跟踪器的 Webhook 服务器中 现在我们可以将代码 提交到新的 git 存储库 然后就可以将它 作为 Swift 软件包引用了 现在我们已经做好了 与 API 对话所需的准备 让我们来设置 Webhook 在 App Store Connect 中 我们可以注册 Webhook 这将使我们的服务器 在每次构建完成时都得到通知 为此 请在 App Store Connect 中访问您的产品 转到设置 然后导航到 Webhook

我将在这里粘贴服务器的 URL 这将使 Xcode Cloud 知道要将 Webhook 发送到哪里 设置好我们的 Webhook 后 唯一要做的事情就是 编写代码来处理它们 所以让我们开始吧 首先我们要定义一个结构体 它与 Webhook 中 我们感兴趣的字段相匹配 Webhook 将包含有关 执行中的特定构建的信息 以及正在执行的每个操作 所以让我们将它们保留在 Webhook 有效负载结构体中

接下来 我们必须编写代码 让 Vapor 正确地 将进来的 Webhook 传入我们的函数 我们将定义一个函数 在对 Webhook 路径的公布请求上运行 在这个函数中 我们在将 传入的 JSON 有效负载 转换为强类型的 Swift 对象时 需要做的只有对它进行解码 所以我们也将添加该代码

很好 现在我们需要做的 就是调用 Xcode Cloud API 获取有关刚才完成的构建的更多信息 这样就可以将它包含 在我们的问题跟踪器页面中 Webhook 有效负载包含大量 有关刚刚运行的构建 以及操作成功或失败的信息 我们或许可以止步于此 但让我们更进一步 我认为如果我们还将在每个操作中 发现了哪些问题这一信息包括进去 将会非常了不起

我们可以为 CiBuildActionsAPI 编写一个扩展函数 这使我们能够轻松返回对于 特定操作感兴趣的问题

在这个扩展中 我们将编写一个函数 将构建操作 ID 作为参数 并返回为特定操作找到的所有问题

在项目中完成它之后 让我们填入其余的代码

我们只希望 Webhook 处理器 在构建完成时运行 所以让我们对此进行防备 接下来 我们可以 开始处理注释字符串 我认为字符串中出现 内部版本号 提交散列 以及作者信息非常重要

现在让我们遍历每个操作 并调用扩展函数 来获取每个操作的问题 现在让我们将这些都传递给问题跟踪器

有了所有这些信息 我认为这将有助于使问题跟踪器 与我们的构建保持同步 我们完成了 这时 我们要将服务器代码托管到 为 Webhook 提供给 Xcode Cloud 的 URL 上 我们也应该开始在问题跟踪器中 看到 Xcode Cloud 构建信息

让我们快速总结一下 到目前为止所了解的内容 Xcode Cloud 有一个 很棒的 AP​​I 可以用来 与您现有的开发工作流 进行更深入的集成 您可以使用该 API 和 Webhook 来建立各点的关联 并将您现有的工具 和技术与 Xcode Cloud 集成 接下来 就由 Jo 来 谈谈其他的功能和最佳实践 Jo：谢谢 John Xcode Cloud 用于集成 您用于创建 App 和框架的 Apple 开发者工具和服务 但是 您的 Xcode 项目 可能需要额外的依赖项 或外部工具来编译您的代码 Xcode Cloud 与 Swift 软件包管理器 （Swift Package Manager）配合得天衣无缝 它支持 Swift 软件包依赖项 无需任何额外配置 只要包的存储库可供公开访问 您还可以将 Xcode Cloud 与第三方依赖项管理器一起使用 比如 Cocoapods 和 Carthage 但您必须使用自定义构建脚本 进行一些额外的准备工作 您可以参考 Xcode 文档中关于 关于如何使依赖项 对 Xcode Cloud 可用的说明

一旦添加了 Swift 软件包 并推送更改以启动工作流 我们就可以转到报告导航器的云标签 并查看我们最新构建的状态

选择“日志”以查看详细的构建日志

我们可以看到 Xcode Cloud 神奇地自动解决了依赖项 Xcode Cloud 成功完成 第一次构建后 您应该计划接下来的步骤 用于完善您的持续集成和交付实践 确保您的 App 或框架 始终处于可发布状态 在本节中 我将讨论如何使用 Xcode Cloud 与 SwiftLint 进行静态代码分析 如何限制对工作流的编辑 以及配置多个开启条件的价值 SwiftLint 是一个 开源的 linter 工具 它执行 Swift 社区普遍接受的 样式指南规则和惯例 它执行静态代码分析以提高 您的代码质量 并防止不良做法 我们发现 SwiftLint 是一个 很好的保持团队代码库一致的方式 尤其是在与更大的团队合作时 我们现在要展示如何使用 自定义构建脚本 集成 SwiftLint 与 Xcode Cloud 我们希望 Xcode Cloud 在从团队的 主存储库中克隆源代码 之后运行 SwiftLint 工具 在项目导航器中 我已经在 ci_scripts 文件夹里 添加了一个 post_clone 脚本 到我的 Food Truck 项目

Xcode Cloud 构建环境 包括 Homebrew 我们就是用它 来安装 SwiftLint 的

在这一行 我们正在执行 SwiftLint 要记住的一点是 脚本在 ci_scripts 目录中执行 所以我们必须告诉 SwiftLint 在 ci_workspace 环境变量中运行 它指向我们的存储库

让我们来看看代码分析的结果 看起来 SwiftLint 发现了一大堆违规行为 其中 15 项是严重违规 由于这是我们第一次 集成我们的工具 我将暂时停用此工作流 这样就可以先与 团队的其他成员进行讨论 就编码风格和惯例达成一致 然后作为一个团队 来决定我们要解决哪些问题 您可以通过 管理工作流（Manage Workflows）菜单 停用 Xcode 中的工作流 这样做会使开启条件停止工作 并且只能开启手动构建

现在我们的静态代码分析 工作流已经停用 我们可以专注于解决想要解决的问题 然后可以回来启用这个工作流 我们的团队规模在不断扩大 我们希望对工作流配置 做出慎重的选择 因为我负责维护和管理 团队的所有工作流 我不希望团队成员 对工作流进行意外的更改 它需要很长时间才能撤消 为防止意外更改 您可以限制谁可以 对您的工作流进行编辑 选择工作流 然后从 语境菜单中选择 限制编辑（Restrict Editing） 团队中的任何人都 可以使用或运行此工作流 但仅有管理员 帐户持有人 和 App 管理者 可以执行限制 让它只能由 这些角色进行编辑

编辑受限的工作流 将带有 钥匙（Key）符号 这意味着它已被锁定 只能由您或者 其他管理用户进行编辑

如果您看到的是 上锁（Lock）符号 则表示它已被管理员锁定 无法由您进行编辑 此功能让您可以轻松 管理复杂工作流的访问 尤其是在您身处一个大团队中时 我们刚刚看到暂停或锁定 工作流是多么容易 现在让我们谈谈工作流的管理和维护

我想在每次提出 拉取请求或合并分支时 运行相同的测试和归档操作 最好的方法是通过多个开启条件 这改善了工作流的维护 因为它减少了您需要 创建和管理的工作流数量 为了进行说明 在这个例子中 我想在给定以下条件时 开启一个构建：如果主分支或 发布分支出现变化 或者出现针对主分支的 预定构建 那么就 运行同一组归档和测试操作 并部署到 TestFlight 进行内部测试 与其创建 3 个工作流 再去管理它们 并使它们保持同步 我会创建单一的工作流 一次性指定所有的开启条件 这提高了可管理性 尤其是当团队有 大量工作流程需要维护时 在 Xcode 中配置 开启条件非常容易 在工作流编辑器中 从 + 按钮菜单 选择开启条件的类型

App Store Connect 中的 Xcode Cloud 提供基于 Web 的全功能体验 我刚才在 Xcode 中为配置 我们的工作流做的全部工作 从停用和锁定它 到设置多个开启条件 也在 App Store Connect 可用 Xcode Cloud 是内置于 Xcode 中的 强大的持续集成和交付（CI/CD）服务 可以帮助到任何规模的开发团队 并可以轻松与您 现有的工具和流程进行集成 帮助您向用户 交付高质量的 App 对于 Xcode Cloud beta 参与者 我们非常感谢您的反馈 并期待听到更多 John：我们希望这些功能可以帮助您完善 团队的持续集成和交付实践 Jo：感谢您的观看 祝您度过愉快的 WWDC ♪ 迷幻音乐 ♪