团队任务,独享泳道

把排队的流水线
搬到一台独占 Mac

Apple Silicon M4 Mac mini,整机只给一个客户。让 PR 检查、夜间归档和远程 Xcode 使用同一套受控工具链,不再与其他租户分 CPU。

两档 M4 配置 · $20/天起 · 独享物理机,非虚拟机

你的团队泳道
  1. PR提交检查
  2. Test编译与单测
  3. Archive归档与分发

独享的是整台机器。团队内部的任务并发与优先级,由你的 runner 配置决定。

先分任务,再分资源

把四类工作安排进泳道

先确定机器的主要职责,再选择内存与存储。开发者交互、发布归档和模型实验可以使用同类节点,但不适合不加限制地争用同一台机器。

场景一 · PR 检查

每次提交都走编译与单测

适合单项目 CI、SwiftUI 小应用,以及先把办公室构建机迁出的团队。每次 PR 触发检出代码、还原依赖、运行单元测试,把结果回传到原有 CI 平台。

从 Merge M4 S 起步:Apple Silicon M4,16GB RAM / 256GB SSD。整机一个客户,编译任务不会被其他租户占用核心;团队自己的任务仍应设置并发上限,避免多个构建同时挤占内存。

第一条流水线只做三件事

  • 固定仓库提交、依赖锁文件与 Xcode 版本。
  • 先跑一个 scheme 的编译和单元测试。
  • 记录等待、编译、测试三个阶段,分别定位耗时。

选择边界:多 target 或并行模拟器测试明显增加内存占用时,再评估 24GB 配置;不以团队人数直接推算机器数量。

租用 Merge M4 S
场景二 · 每日发布

把 nightly 归档留给发布节点

适合每日生成测试包、定时归档和使用 Fastlane 自动化打包的团队。沿用现有 lane,将归档、导出与上传 TestFlight 串成一条发布任务。

推荐 Merge M4 L:Apple Silicon M4,24GB RAM / 512GB SSD。相比起步档有更多内存与本地存储,便于保留多个项目的依赖和必要的模拟器运行时;实际构建收益取决于项目与缓存状态。

发布任务单独设一道闸

  • 使用独立 runner 标签,避免普通 PR 占用归档时段。
  • 通过 CI 密钥注入证书、描述文件及分发所需凭据。
  • 归档成功后保存日志与产物,再按规则清理本地文件。

选择边界:节点全年 365 天正常运行;定时任务是否触发、上传是否成功,仍需在 CI 平台设置失败通知与重试。

租用 Merge M4 L
场景三 · 远程开发

没有本地 Mac,也能打开 Xcode

通过 VNC 屏幕共享使用 macOS 图形界面,在 Xcode 中查看工程、排查编译错误与运行模拟器;通过 SSH 执行命令行构建、同步文件和管理 runner。

需要同时打开 Xcode、模拟器与依赖工具时,优先评估 Merge M4 L。图形界面与 CI 任务会使用同一台物理机的资源,建议将交互调试与自动归档错峰安排,或拆成不同节点。

先验证连接,再搬完整工程

  • 从控制台获取实例连接信息,先检查 SSH 与 VNC 接入。
  • 降低远程画面分辨率,确认输入与窗口操作的响应。
  • 用小工程验证 Xcode 与模拟器,再同步正式项目。

能力边界:云端适合编译、签名与模拟器测试,不等于能直接访问你手边的 iPhone。需要本地真机连接的环节应单独保留。

查看 SSH 与 VNC 连接说明
场景四 · AI 实验

给 MLX 实验划出资源预算

在 Apple Silicon 上运行 MLX 本地推理,验证量化模型与小模型微调流程。先用较小模型建立可运行基线,再逐步增加上下文长度、批量与训练数据规模。

推荐 Merge M4 L 搭配 +2TB SSD 附加项,用扩展存储保存模型权重、数据集和检查点。24GB RAM 是运行内存预算,额外 SSD 是文件容量,两者不能互相替代。

先看峰值,不只看模型文件大小

  • 记录模型加载、推理与微调各阶段的内存峰值。
  • 为下载、解压与检查点保留额外磁盘空间。
  • 暂停同机 CI 并发,避免实验结果被资源争用干扰。

选择边界:模型能否装入内存还取决于量化精度、上下文和运行方式。+2TB SSD 附加项不增加内存,也不保证任意模型都能运行。

配置 Merge M4 L 与扩展存储

一台独享,不等于任务无限并发。先限制单机并发,再观察内存峰值、磁盘余量和任务等待。如果发布任务需要稳定时段,优先拆分 runner 职责,而不是把所有任务堆到同一条队列。

迁移按依赖顺序推进

先复现环境,再切换流水线

不要一开始就撤掉原构建机。按数据、工具链、CI 接入的顺序完成交接,用同一提交在新旧环境各跑一次,确认产物与日志后再切换正式任务。

  1. 01 · 数据

    工程、签名材料与缓存分开搬

    从仓库重新检出工程与子模块,保留依赖锁文件;不要把本地工作目录整体复制后直接当作可复现环境。

    • 证书与描述文件通过受控渠道传输,密码放入 CI 密钥。
    • 缓存按 Xcode 版本、依赖锁文件和架构区分键值。
    • 只迁移确认可复用的缓存,旧 DerivedData 不作为必需输入。

    验收点:指定提交可检出,签名文件可定位,敏感材料未进入仓库。

  2. 02 · 工具链

    把版本写进记录,不留在记忆里

    对齐 Xcode、Homebrew、Ruby 与 CocoaPods。优先读取项目已有版本文件,避免迁移时顺便升级依赖,让问题来源混在一起。

    xcodebuild -version
    xcode-select -p
    uname -m
    ruby --version
    bundle exec pod --version

    验收点:确认 arm64 环境、所选 Xcode 路径与依赖版本,再用一个 scheme 完成本地命令行构建。

  3. 03 · CI 接入

    先接测试任务,再接正式发布

    按现有平台注册 self-hosted runner 或 agent,为节点设置清晰标签。GitHub Actions 可使用下列任务标签;其他平台沿用各自的调度配置。

    runs-on:
      - self-hosted
      - macOS
      - ARM64
      - macos-m4

    验收点:实际注册相同标签,测试分支命中新节点,日志与产物可取回;正式切换前保留原 runner 的回退配置。

注册令牌与签名材料不写进示例命令或公开日志。节点变更后,检查 CI 平台的 runner 在线状态、任务标签和触发条件,三项都正确再开放团队使用。

让迁移结果可以复核

站会上对比同一提交

构建时长只比较相同输入。把缓存命中和缓存未命中的结果分开,避免把一次下载、一次重试或测试范围变化误认为硬件差异。

笔记本开发工作场景,配合团队站会复核构建日志与迁移记录
开发协作场景配图。构建对比以团队自己的 CI 日志为准,不将配图作为客户案例或性能证明。

固定输入

记录提交哈希、Xcode 版本、scheme、测试设备与依赖锁文件。比较前确认没有改变测试范围。

拆开耗时

分别看等待、拉依赖、编译、测试、归档与传产物。整机独享消除其他租户的资源争用,不会消除网络传输。

保留退路

保存原 runner 标签与流水线配置。确认新环境可重复运行后,再停止旧节点的正式任务。

按场景选配置

PR 检查从 16GB 起步;多 target、模拟器与发布归档评估 24GB。到方案页核对选型表、四种计费周期与存储附加项,再开出你的团队泳道。