用独享 Mac mini 搭建 Mac CI 集群

唯一重要的数字是：在最繁忙的那个小时里，必须同时运行多少个构建。不是开发者人数，也不是代码仓库数量，而是并发构建数。

适用于大多数 iOS 团队的大致规模：

排队时间就是信号。如果高峰期构建等待超过几分钟，就增加一台机器。这比每个开发者等待所耗费的那一小时更便宜。

每台 Mac mini 整机都归您使用：没有虚拟化层（hypervisor），没有争抢资源的邻居。因此有两种可行的模式。

最干净。一次构建独占全部 CPU、GPU 和内存。适用于 Xcode 构建和 UI 测试，这类构建会把您给它的每个核心都用满。

适用于小型且受 I/O 限制的任务：单元测试、代码检查、打包。在 32 GB 的 M4 或 M6 上，两个并行的轻量任务可以从容运行。

两种方式混用很常见：重型机器专门用于发布构建，较轻的机器塞满快速任务。

给机器打上标签，让流水线按标签分配任务。常用的划分方式：

ios-app、sdk、internal-tools。每个代码仓库指向自己的标签，因此一个产品的构建失败绝不会阻塞另一个产品。

pr 机器快速且始终保持预热，release 机器在每次签名构建前都会被抹掉。

外包公司为每个客户分配专属机器，配有各自的凭据和证书。没有任何共享，账户之间没有可泄露的东西。

这一切都在一个 MacDuty 账户下，月底一张发票。

一台构建了一年的 Mac 会积累多个 Xcode 版本、模拟器和缓存。当您把一台机器轮换到新项目时，请联系支持进行全新的重新安装。由于这会抹掉 Mac，我们只在您同意后才执行。

同一机器池中的每台机器使用相同的 Xcode 版本，并有计划地升级。机器版本各自漂移的机群，会产生在一个 Runner 上通过、在另一个 Runner 上失败的构建。

构建机器的 CPU 图表总是看起来很吓人，却很少能据此采取行动。队列等待时间才会告诉您何时该增加硬件。

有十台机器时，一台宕机应该只是小麻烦，而不是事故。

编排平台在虚拟化的 macOS 之上叠加一层 Kubernetes 式调度，而您要为这一层付费。如果您需要大规模地为每个任务启动临时虚拟机，它确实有用。

大多数机器少于二十台的团队并不需要。他们需要的是几台快速、独享、持续在线的 Mac，缓存保持预热，每月费用固定不变。这就是独享机群：整台物理机，固定价格，构建缓存留给下一个任务，而不是随虚拟机一起被丢弃。

还有一个区别会在发布前的凌晨 2 点显现：管理机架的人会回复您的邮件。

告诉我们您的规划：多少台机器，哪些型号，需要安装什么。应您的要求，我们会为机器配置您的 Xcode 版本、Runner 代理、密钥和证书，并在后续处理重新安装和机群变更，每一项都需经您同意。