作者：林永坚，超越十年移动开发经历，从前是微软 Window Phone MVP，了解 iOS、Android 等渠道。现在在 REA Group 担任 Mobile Tech Lead，担任公司 Customer 产品部一切移动产品的开发。并担任移动 App 的架构，以及项目主动化与工程化建设。开发 IBAnimatable 和 SwiftWeather 等开源项目，并编写了 iOS开发进阶 课程。
审阅： 红纸，iOS 开发，老司机技能周报修改，就职于淘系技能部
Damonwong，iOS 开发，老司机技能周报修改，就职于淘系技能部
Parsifal，老司机技能周报担任人，微医集团移动治疗担任人
作为 WWDC 21 的一个要点产品 Xcode Cloud，咱们有必要了解和了解它。Xcode Cloud 是专为苹果开发者设计的一款内置于 Xcode 中的 CI/CD （继续集成和交给服务）。那 Xcode Cloud 到底能干嘛，咱们该怎样运用它呢？最好的方法是亲身运用，可是我的 Xcode Cloud Beta 请求还没有下来，只能经过下面视频来一窥终究了。
- 10267 – Meet Xcode Cloud
- 10268 – Explore Xcode Cloud workflows
- 10269 – Customize your advanced Xcode Cloud workflows
请留意，这篇文章不是这些视频的直接翻译，而是我看完这些视频后对 Xcode Cloud 的一些理解和主意。老司机技能周报会有专门的文章具体地叙述这些视频的内容，你能够订阅哦。
假如你也想试用 Xcode Cloud，能够登录 App Store Connect 进行请求。如下图所示，在请求下来之前，咱们是没有方法运用 Xcode Cloud 的。
Xcode Cloud Workflow
CI 已经成为项目开发中必不可少的一个工程环节，一起也是推进团队工程师文明的重要手段。为了便利苹果开发者快速建立 CI 体系，苹果公司推出了 Xcode Cloud 服务。Xcode Cloud 服务归于全服务 CI。一般咱们能够把 CI 分红三大类，下面是我在《继续集成：怎么实现无需人手的快速交给？》文章中对这些 CI 分类的描述：
现在盛行的 CI 构建中介首要分红三大类。
- 全手艺保护 CI。该类 CI 从物理主机、操作体系、Ruby 环境以及 Xcode 版别都由开发团队保护。这类型的 CI 保护本钱比较高，例如，需求办理物理主机和网络联通性，需求保护操作体系的安全更新等，但一起也给了咱们很大管控性和灵活性。
- 云端虚拟机 CI。该类 CI 是经过租用云 Mac 虚拟机来进行建立，现在比较盛行的 Mac 虚拟机服务供给商有亚马逊的 AWS 和 MacStadium。有了这些云服务供给商，咱们就不必再进行安全补丁等惯例保护了，只需挑选特定的 Mac OS 版别来发动虚拟机，然后在虚拟机上履行脚原本建立 Ruby 和 Xcode 环境即可，就如 Moments App 项目里履行 setup.sh 脚本就能完结项目建立。
- 全服务 CI。该类 CI 不仅为咱们供给了虚拟机，并且还供给了 Ruby 和 Xcode 等环境，咱们只需求供给一个 CI 管道装备文件就能完结这个 App 的主动构建。
没有一类 CI 是完美的，它们都有各自的优缺点。这三类 CI 从上往下看，保护本钱越来越低，但从久远来看，运转本钱却越来越高。从便利性来看，下面的类型会比上面的更加易用，但一起也牺牲了灵活性。
我主张你依据团队的自身状况来挑选。假如你地点的团队没有专门的人员来保护 CI，能够从全服务 CI 开始。随着项目和团队的发展，慢慢地晋级为云端虚拟机 CI 和全手艺保护 CI。作为一个只要一个开发者的开源项目，Moments App 也挑选了全服务 CI。
接下来咱们就从下图中的构建流程看看 Xcode Cloud 是怎么运作的。
在 Xcode Cloud 里边，一个构建流程称作为 Workflow，而其他 CI 常常经过 Pipeline 来界说流程。 Xcode Cloud 的 Workflow 首要由有三大部分所组成。第一部分是触发构建，这一部分一般由 Git 分支上的改变所触发。第二部分是构建服务，一般由构建，测验，打包等动作所组成。第三部分是构建后的使命，例如发送构建状况更新告诉，上传 App 到 App Store Connect 等等。下面就看一下这三部分别离做了些什么事情。
触发构建
要触发主动化构建，首要需求装备代码保管服务，在视频的演示里，运用了 GitHub 作为代码保管服务。如下图所示：
为了拜访 GitHub，咱们需求在 Xcode 上手艺装备对 GitHub 的衔接。在实在项目中，咱们一般运用 GitHub API Key 来拜访 GitHub，这样能协助咱们便利办理拜访的权限。
成功衔接 GitHub 以后，咱们就能够指定 Repo 的地址以及要构建的 Workspace 姓名。
接着就能够装备发动条件了。
发动条件一般由 Repo 分支上的改变所触发，例如 push 了新 commit 到 main 分支上，或许提交了新的 Pull Request 等等。咱们能够依据团队的需求来增加发动条件。在装备里边有一个 “Auto-cancel Builds” 的选项。当选中该选项时，一旦分支有新的更新，Xcode Cloud 会主动取消原有的构建使命来节约花费。这个选项非常实用，咱们一般会在 CI 上翻开该选项。
装备完好发动条件后，咱们能够在 Environment 下装备运转环境。
例如在上图中，咱们指定了 Xcode 和 macOS 的版别，咱们能够为不同的 Workflow 指定不同的运转环境。例如指定 beta 版别的 Xcode 来测验代码的兼容性。
构建服务
构建服务 是 Xcode Cloud 的核心组成部分。Xcode Cloud 为咱们供给了构建所需的云服务基础设施，咱们只需求装备构建动作就能完结构建使命。
默许状况下，Xcode Cloud 为咱们增加了 Archive 动作，咱们还能够按需增加 Build，Test 以及 Analyze 等动作。如下图所示：
咱们先看一下 Test 动作。
咱们能够挑选渠道，Scheme，测验的设备类型及体系版别来履行测验。在 Requirement 选项中，咱们能够决定当测验失利时是否继续构建过程。在 CI 装备中，咱们一般翻开这一开关，这样能使得 App 在发布到 App Store 之前有必要经过一切测验，从而减少 App 的 bug 和崩溃率。
现在回来看看 Archive 动作。
如上图所示，在打包的过程中，咱们能够把 App 打包成内部测验的 Ad hoc 版别，或许打成 App Store 版别。Xcode Cloud 的一个亮点是为它能为咱们主动办理证书和 Provisioning Profile 等文件，大大减轻办理私钥和证书等很多的手艺操作。在其他 CI 里，咱们往往运用 fastlane match 来办理签名信息。
构建后使命
Xcode Cloud 供给了构建后使命让咱们发送状况告诉以及把 App 上传到 App Store Connect 上。其他 CI 往往会把这些使命作为 Pipeline 的一部分，也便是类似构建服务里边的 Build，Test 等普通的使命。
先看看状况更新告诉， Xcode Cloud 答应咱们发送两类告诉音讯，如下图所示：
第一类是成功音讯：咱们能够挑选发送一切的成功音讯；或许只发送修正后的成功状况，或许不发送任何成功音讯。 第二类是失利音讯：咱们能够挑选发送一切的失利音讯；或许发送从前成功但后来失利的构建使命；或许不发送失利音讯。
装备构建后使命也很简单，只需求在 Post-Actions 菜单点击增加即可。
现在支撑的告诉方法有 Slack 和邮件。
第二种构建后使命是把打包后的 App 上传到 TestFlight。
上图是苹果引荐的装备信息。这种做法与咱们往常装备 CI 的做法基本一致，咱们常常把 Pull Request 构建并发布到内部测验组，而把 release 分支发布到 App Store Connect 进行审阅。
当上传内部测验版别的时候，咱们还能够挑选测验组。如下图所示：
自界说脚本
为了提高可扩展性，Xcode Cloud 答应咱们经过自界说脚原本履行一些 Xcode Cloud 没有供给的操作。如下图所示：
依据运转机遇的不同，咱们能够发明三种不同的脚本：post-clone，pre-xodebuild 和 post-xcodebuild。咱们能够运用他们来完结不同使命，例如能够在 post-clone 脚本里安装 CocoaPods 等第三方依靠库。
在视频中演示了 pre-xodebuild 脚本的例子。你能够看到，这个脚本运用 CI_PULL_REQUEST_NUMBER 和 CI_XCODEBUILD_ACTION 等环境变量。这些环境变量都是由 Xcode Cloud 所供给的。便利咱们履行脚本时能够进一步定制构建的流程。在上述的脚本里，咱们能够为 App 替换不同的图标。
当运用自界说脚本时，需求留意苹果给咱们的主张。
其间最重要的是第三点，要留意脚本时的返回值，Xcode Cloud 会依据返回值来决定是否继续当时的结构流程。
装备 Workflow 时的一些技巧
下面咱们看看装备 Workflow 时的一些技巧，这些技巧能帮咱们进一步按照团队的需求来自界说构建流程。
New Build System
谢谢 红纸 指出参考链接，要在已有项目上运用 Xcode Cloud，有必要契合下面的要求。
特别留意的是 Build system。 咱们需求点击菜单 File -> Project Settings (或许 File -> Workspace Settings) 翻开下面的装备框。
然后在 Build System 里挑选 New Build System 选项。
“Restrict Editing” 选项
咱们能够经过选中 “Restrict Editing” 选项来控制 Workflow 装备的拜访权限，这样能保证其他团队成员不会因为不小心而做不必要的改动。
守时使命
除了监听 Git 分支的改变以外，咱们还能够经过 On schedule 的方法来发动构建使命。这是常见的构建方法，例如，咱们会在每天晚上履行很多测验来保证 main 分支上代码能很好地在各种设备上正常运转。下图演示了怎么装备一个 On Schedule 的构建使命。
恢复 derived data
咱们能够在 Environment 选项中不选中 “Clean” 选项来加速构建的速度，如下图所示。
需求留意的是，假如要构建 App Store 版别的 App，咱们需求选中 “Clean” 选项来保证 App 在构建的过程中不会遭到任何缓存的影响。
环境变量
为了能够构建出功用不一样的 App，例如为测验版别的 App 衔接内部的 API 服务器，咱们能够为 Workflow 装备不同环境变量。假如环境变量保护私密信息时，咱们能够选中 Secret 选项来保证该环境变量的值不再明文显现了。下图是环境变量的装备。
依靠库办理
当时， Xcode Cloud 只支撑 Swift Package Collections 来办理依靠库。如下图所示：
假如咱们增加的依靠库来自于私有的 Repo，在第一次构建时会失利。咱们需求在 App Store Connect 上修正这一错误，例如给 GitHub 拜访装备权限等等。
Webhook
Xcode Cloud 供给了 Webhook 来协助咱们与外部体系进行交互。咱们能够为不同构建状况装备各种Webhook，下图演示了在创建 Build，发动 Build 和完结 Build 时调用不同 Webhook 的状况。
视频中还给了一个怎么运用 AWS Lambda 来处理 Webhook 请求的例子。
这个 Lambda 能帮咱们把构建成功的信息发送到推特上。
一些主意
CI 已经成为一个团队的标配，苹果公司也意识到这一点，尝试供给官方的处理方案 Xcode Cloud，这是一个很好的开始。但苹果收买 BuddyBuild 也有三年多了，三年的时刻只做出视频中产品，我感觉还远远不能满意一个老练团队的需求，首要原因如下：
- Xcode Cloud 还不支撑 code as configuration （代码即装备），现在 Xcode Cloud 上一切的装备都有必要经过手艺点击来完结。这样做简单犯错，不便利重用，并且无法查看历史记录。很难应用到大型项目中。
- 作为全服务 CI，Xcode Cloud 便利咱们快速建立 CI 体系，但是，Xcode Cloud 的构建体系只能完结 Build，Test，Archive 等几个默许操作，不便利扩展。虽然供给了自界说脚本，Webhook 等方法，但仍是逗留在三年前 BuddyBuild 的做法，可扩展性不强，基本上无法满意大型项目的要求。在大型项目中，咱们能够运用 fastlane 等东西来自界说简直任何的动作和流程。
- 也由于 Xcode Cloud 是全服务 CI，无法进行本地调试，每次操作都需求在 Xcode Cloud 进行验证。
- 由于不支撑 code as configuration，很难从全服务 CI 晋级到其他 CI，例如云端虚拟机 CI 或许全手艺保护 CI。
- Xcode Cloud 只支撑苹果生态，不利于公司范围内多体系的重用。当咱们建立一个 CI 体系的时候，除了构建部分以外还需求连通监控体系和工单体系等。假如运用一个通用的 CI，咱们就能够为 iOS，Android 以及后台体系装备一致的监控体系，便利一致办理一切的指标和流程。运用 Xcode Cloud 反而增加了额定的作业来完结对其他体系的整合。
- 在视频里边说，Xcode Cloud 能够支撑多种 Git 保管服务，也便是能够支撑 GitLab 等服务。但是从咱们曾经运用 BuddyBuild 的经历来看，BuddyBuild 不能做到精确约束 GitHub 的拜访权限。经过后来做了一些 SSH 的支撑，但功用上远比不上其他 CI。希望 Xcode Cloud 在这方面做得更好。
那 Xcode Cloud 是不是一无可取呢？当然不是，这仍是第一个版别，我信任苹果还会依据用户反馈不断优化，并且苹果公司有硬件设备的本钱优势，加上完善的云服务基础设施，假如能不断优化，或许能成为主流的 CI 渠道。并且假如 Xcode Cloud 价格优惠，也适合小型团队快速建立 CI 体系。
有几点我特别感兴趣的，假如运转本钱很低，咱们能够运用 Xcode Cloud 来守时履行很多的测验。假如能支撑 Device farm 就更好了。还有，假如 Xcode Cloud 能履行开发中的代码和并行履行测验，就能很便利处理本地机器的功能问题。
不管怎么说，我觉得苹果开了个好头，我们拭目以待，多提点主张，让他们越做越好吧。
怎么建立 CI
在文章的最后，我想共享一下怎么建立一个常用的 CI。在 《iOS开发进阶》 课程里边，我具体叙述过怎么从头建立一个 CI。这儿我总结一下，这只是我理解的一个 CI 建立流程，各个公司依据具体状况或许有所不同。
首要，咱们会把构建过程中的一切的过程都开发成主动化脚本，常用的方法是运用 fastlane，也有公司直接运用 xcodebuild 或许直接调用 LLVM。准则是把常用的操作，例如构建、测验、打包、签名、上传、发送告诉音讯等等动作都封装成可履行的指令。这样做的好处是能够在本地开发和测验这些脚本。并且脚本能够运用到任何的 CI 体系上。现在 Xcode Cloud 无法做到这一点，它为咱们供给了 Build，Test，Archive 等动作，但由于这些动作都是有苹果公司预先界说，很难进一步的优化。我举个例子，假如咱们自己开发主动化脚本，就能够在构建过程中做一些优化，例如合并 Frameworks，依据 LVVM 来优化编译，减少包的巨细等等。现在 Xcode Cloud 没有方法让咱们进行这些优化。
然后，依据团队需求挑选其间一种 CI，例如全服务 CI，云端虚拟机 CI 或全手艺保护 CI。不管挑选那种 CI，准则基本是，这些 CI 能够调用上一步界说好的脚本，然后经过 YAML 文件来装备构建的 Pipeline，例如主分支构建内部版别，发布分支构建 App Store 版别。还能够界说守时使命，例如晚上 12 点在多种设备上履行测验等等。有了可装备的 YAML 文件，能够便利咱们快速地晋级 CI，例如从全服务 CI 晋级为云端虚拟机 CI。虽然 Xcode Cloud 是全服务 CI，但由于 Xcode Cloud 现在不支撑 YAML 装备，一切的装备都需求手艺点击，所以很难支撑晋级。
除了上述的 Pipeline 装备以外，依据不同的 CI 类型，额定的作业有所不同。例如，当咱们挑选全服务 CI 时，首要的使命是在 YAML 文件上装备 macOS 和 Xcode 的版别。
当咱们挑选云端虚拟机 CI 时，需求租用云 Mac 虚拟机来进行建立，现在比较盛行的 Mac 虚拟机服务供给商有亚马逊的 AWS 和 MacStadium。要运用这类型的 CI，咱们需求有一个构建 CI 的 CI。这个母 CI 能够依据她自己的 YAML 文件来快速地构建出一个用于构建 App 的 CI 的 VM （虚拟机），这样能帮咱们把构建环境的 VM 快速地复制到各个云 Mac 虚拟机上。当咱们需求支撑新的 macOS 或许 Xcode 版别时，需求更新母 CI，然后测验 App CI 的构建状况。
当咱们挑选全手艺保护 CI 时，需求有专门的团队办理物理主机，网络联通性，安全性等等。但不代表咱们把 CI 直接运转在 Host OS（宿主操作体系）上。其做法与云端虚拟机 CI 一致。也是运用一个母 CI 来构建 VM，然后把 VM 布置到咱们自己保护的 Host OS 上，而不是云 Mac 虚拟机上。除非地点的公司有强大的 IT 支撑团队，不然我不主张自己保护各个物理 Mac 主机。
虽然不同的 CI 建立的过程有点差异，但你或许已经看到，在构建 CI 时，咱们基本上是遵从组成化和容器化的准则，尽量保持一切模块都能够快速重用。一起也遵从主动化的准则，不管哪一类型的 CI，都能够做到无人手主动构建，连 VM 也是由母 CI 主动构建出了的。所以 CI 是推进工程师文明建设的重要手段，标准咱们的开发流程，让咱们从繁重的重复劳动中解放出来。
重视咱们
咱们是「老司机技能周报」，一个继续追求精品 iOS 内容的技能公众号。欢迎重视。
重视有礼，重视【老司机技能周报】，回复「2021」，收取 2017/2018/2019/2020 内参
支撑作者
在这儿给我们引荐一下 《WWDC21 内参》 这个专栏，一共有 102 篇关于 WWDC21 的内容，本文的内容也来历于此。假如对其他内容感兴趣，欢迎戳链接阅览更多 ~
WWDC 内参 系列是由老司机牵头组织的精品原创内容系列。 已经做了几年了，口碑一直不错。 首要是针对每年的 WWDC 的内容，做一次精选，并召唤一群一线互联网的 iOS 开发者，结合自己的实际开发经历、苹果文档和视频内容做二次创作。
