GitHub Actions macOS-14 iOS CI 迁移应在退役前完成隔离验证，再分批切换正式发布任务，并保留已经演练过的回退方案。本周先选一条真实发布工作流建立基线；只有关键构建、归档和签名均通过验收，才扩大切换范围。
管理 GitHub Actions iOS 发布流水线的 IT 或平台负责人，可用本文确定迁移顺序和生产放行条件。
负责 Xcode 工具链与应用签名的发布工程师，可用验收项核对新 Runner 的发布结果。
负责 Mac CI 预算与容量规划的技术管理者，可据此判断哪些任务需要备用环境。
最后更新于 2026 年 10 月 26 日；退役日期与候选标签核实自 GitHub macOS-14 Runner 退役公告、Runner 选择文档及官方 Runner 镜像仓库。项目兼容性仍须以团队工作流日志复核。
退役前：先定迁移边界，不要只改标签
GitHub 已确认，macos-14、macos-14-large 与 macos-14-xlarge 将于 2026 年 11 月 2 日退役；公告列出的替代标签包括 macos-15、macos-latest（macos-26）、macos-15-xlarge 和 macos-latest-xlarge（macos-26-xlarge）。这些是候选项，不是所有项目都兼容的保证。
这次工作的范围是已运行的 iOS 发布流水线迁移，不是全组织标签扫描，也不是 Brownout 故障排查。不要因为标签仍可用就直接放行：操作系统、CPU 架构和 Xcode 工具链是不同维度。镜像内的软件会变化；官方说明每个 macOS 版本支持的 Xcode 主版本也有范围限制。
迁移开始前，先按发布风险划分任务：
- 普通构建和不接触生产凭证的测试，可先做候选 Runner 验证。
- 使用模拟器的测试，要核实项目需要的运行时是否确实存在于目标镜像。
- 归档、签名、上传任务属于生产发布关键路径，应最后放量；不允许用一次编译成功代替发布验收。
切换前：用真实工作流建立发布基线
不要另写一个“更简单”的验证项目。迁移前的记录要来自团队当前真实发布流程，否则新旧结果无法逐项比较。
为基线留存以下证据：
runs-on标签、工作流触发条件，以及实际运行的 Runner 镜像信息。xcodebuild -version、所选 Xcode 路径、SDK 与模拟器运行时；不要只记录 YAML 中写了什么。- 依赖解析结果、构建配置、归档日志和归档产物标识。
- 签名身份、Provisioning Profile 匹配情况、导出结果，以及上传链路的成功或失败记录。
- 发布窗口中不可中断的任务、失败时的业务影响和负责批准回退的人。
基线还要说明哪些差异可以接受，哪些必须阻止放量。例如，日志显示 Runner 标签变了，但实际选用的 Xcode 没变，并不能证明归档签名链路正常。反过来，Xcode、SDK 或模拟器运行时发生变化时，需按项目兼容要求复核，而不是把差异笼统归为“Runner 升级”。
选候选环境：macOS-14 Runner 切换到 macOS-15 或 macOS-26 怎么验？
先从项目约束倒推候选环境，再决定标签。官方 Runner 选择文档列出受支持标签和对应架构；镜像仓库及其 macOS-15 镜像说明则可核对镜像实际包含的软件。标签本身不等于已经锁定 Xcode 版本，具体内容要在运行日志里确认。
| 迁移选择 | 适用前提 | 放行前核对 |
|---|---|---|
macos-15 |
项目约束与该系统、架构和镜像内工具链相符 | 实际 Runner 架构、Xcode 选择、SDK、模拟器运行时 |
macos-latest（当前指向 macos-26） |
已确认项目能在该系统环境构建和发布 | 不把 latest 当作固定环境；记录实际系统与 Xcode |
macos-15-xlarge 或 macos-latest-xlarge |
需要评估公告列出的较大 Runner 标签 | 先核验该标签对本仓库可用，再跑完整发布工作流 |
| 经核验的备用 Mac CI | 候选托管 Runner 未通过关键任务验收，且任务约束明确 | macOS、架构、签名权限、网络访问、凭证隔离及回退路径 |
上述选项不是性能排名，也不代表所有团队都能使用相同架构。GitHub 的 Runner 选择文档和镜像仓库是核对标签、规格与软件内容的入口；Apple 的 Xcode 系统要求用于检查 Xcode 与 macOS 的支持关系。最终以目标镜像当次运行记录和项目实际结果为准。
隔离验证：把完整构建、归档和签名链路跑通
试验应在非生产分支或隔离工作流运行，使用真实项目和相同发布步骤，但不给试验任务生产发布凭证。这样既能测到真实兼容问题，也避免迁移验证误触发正式上传。
按下面的顺序执行：
- [ ] 建立单独的迁移分支或验证工作流，记录候选标签和触发条件。
- [ ] 运行依赖解析与普通构建，核对错误、警告及生成物。
- [ ] 执行项目实际需要的模拟器测试，确认所需运行时能启动并完成测试。
- [ ] 执行正式归档步骤，保存
xcodebuild日志和归档产物。 - [ ] 复核签名身份、Profile、导出设置和导出产物；只在隔离凭证范围内验证上传链路。
- [ ] 将新旧环境的日志、产物和签名验证结果并排比较，给每项差异标注通过、待查或阻断。
- [ ] 由发布负责人确认通过条件，并把失败原因和对应处理动作写入迁移记录。
Apple 的归档与导出文档将构建 Xcode 归档和从归档导出可分发应用作为不同步骤，并说明这些步骤可通过 xcodebuild 自动化。因此，只有编译成功而没有归档、导出及签名证据，不足以放行正式发布。
分批放量：先迁已验收的工作流，再碰发布关键路径
每批只切换已通过隔离验收、回退步骤明确的工作流。先覆盖低风险任务，确认运行环境与预期一致后，再迁移模拟器测试和正式发布任务。每次切换都记录提交、标签、实际镜像与验收结果，避免多个变量一起变化，导致失败原因无法定位。
生产发布工作流应保留明确的人工放行边界。可通过 GitHub Actions 的部署环境保护规则控制发布任务何时运行、何时获得环境密钥；密钥只应在必要的发布作业中开放。
还要检查并发配置：发布任务若共享签名资源或发布目标，不要直接套用会取消进行中任务的并发设置。GitHub 的并发组文档说明，限制并发时同一并发组默认只保留一个等待中的运行，新增等待任务可能取消先前等待的任务；队列策略要结合发布任务的可中断性配置。
停止放量条件可以直接写入变更记录：
- 新标签实际运行的系统、架构或 Xcode 与验收记录不一致。
- 归档、签名或导出结果无法与基线核对，或失败原因尚未解释。
- 上传链路触及生产凭证，但隔离范围与审批条件未确认。
- 回退路径尚未验证，或回退会重新依赖即将退役的 macOS-14 标签。
最终验收：失败时回退到已验证的流程，不赌旧标签还能用
回退不是把配置改回 macos-14。该标签系列有明确退役日期，继续依赖它不能构成可靠恢复方案。应在切换前定义可执行的替代路径：恢复到已验收的其他 Runner 工作流，或把特定关键任务交给已经按项目要求核验过的备用 Mac CI。
如果考虑远程 Mac CI，先把任务的系统版本、架构、签名权限、网络访问和运行连续性要求写清，再逐项做实际验证。不要仅凭“也是 Mac”就推断兼容；自托管 Runner 也不是自动隔离的干净环境，GitHub 的安全使用说明特别提醒其可能被不可信工作流代码持续影响，必须评估仓库访问者、凭证和 Runner 隔离。
这也是区分托管 Runner 与企业远程 Mac CI 的关键：前者便于按标签使用，但团队要跟踪镜像和工具变化；后者可以作为特定任务的承载候选，却仍须核验权限、隔离、网络、交付与维护责任。我们建议用一条真实发布任务形成最终验收记录，而不是先采购或扩容、再期待流水线适配。若正在评估远程 Mac 的采购与租赁，可以先看 Mac 采购与租赁选择，再把成本方案与任务验收结果一并纳入决策。
如果当前流程依赖退役标签、无法确认 Xcode 实际选择，或把构建、签名和上传都压在同一条不可回退链路上，主要风险不是“换标签多改几行”，而是工具链漂移、生产凭证暴露和发布中断。若托管 Runner 无法通过关键任务验收，而团队又需要临时或阶段性的 Mac 承载环境，可以先查看 MESHLAUNCH 的远程 Mac 方案，按本文验收条件核实环境与交付是否匹配，再决定是否租用备用节点。如果任务长期稳定且负载明确，自购设备也可纳入 TCO 比较；若要求特定物理接口或严格的本地网络条件，则远程方案未必合适。