2026年App Center停用迁移窗口：短周期移动构建用托管CI还是按天云Mac自托管Runner？私有依赖与签名注入决策矩阵FAQ

Microsoft App Center 进入停用倒计时后，很多移动团队会把迁移窗口和版本冲刺撞在一起：既要替换构建、测试、分发链路，又不能让 iOS 签名、Android keystore、私有 Pod 或 npm registry 在新平台里裸奔。短周期团队最容易纠结的是两个方向：直接上托管 CI，还是租一台按天云 Mac 做自托管 Runner。

迁移窗口先看两条约束

不要先问“哪家 CI 便宜”，先问“哪些东西不能离开内网”和“哪条链路必须今天恢复”。App Center 的替代通常拆成四块：源码触发、构建执行、测试分发、崩溃与分析。前两块决定 Runner 形态，后两块可以慢慢替换到 TestFlight、Firebase App Distribution 或自建分发页。

托管 CI 还是按天云 Mac Runner？

托管 CI 的优势是接入快、权限模型清晰、日志集中；云 Mac Runner 的优势是环境可控、网络可控、签名状态可控。如果你只是把公开仓库的 Android nightly build 从 App Center 挪走，托管 CI 足够。如果你要在两天内恢复 iOS 热修复出包，并且依赖私有 Git 子模块、内部 CocoaPods 源和多个 Apple Team，云 Mac 更像“救火执行面”。延伸阅读可参考 2026年Xcode Cloud分钟包与并发打满后：按天云Mac承接Archive、公证与TestFlight的切换信号、路径规划与回退决策矩阵FAQ。

私有依赖与签名注入分三层

第一层是拉代码和拉依赖：Git deploy key、npm token、Maven password、CocoaPods 私有源凭据。第二层是构建期环境变量：API base URL、feature flag、Sentry DSN。第三层才是签名：Apple p12、Provisioning Profile、Android keystore。前两层可以由 CI 密钥库注入，第三层建议在云 Mac 会话内短时导入 Keychain，构建完成后删除。

# 1. 拉取私有依赖，只给只读 deploy key
bundle install
pod install --repo-update

# 2. 构建前临时导入签名材料
security import dist.p12 -k build.keychain -P "$P12_PASSWORD" -T /usr/bin/codesign

# 3. Archive 后清理 Keychain 与 profile
xcodebuild archive -scheme App -configuration Release

缓存也要跟着密钥边界拆开。DerivedData、CocoaPods、SPM、Gradle 可以跨 Job 复用，但不要把含 token 的 .netrc、gradle.properties 或临时 Keychain 打进缓存包。需要自托管 Git 控制面时，可参考 2026年短周期自托管Git（Gitea/Forgejo）配轻量VPS控制面与按天云Mac原生iOS构建执行面 的 Webhook 与令牌分层做法。

FAQ：迁移当天最常见的四个问题

• 是否要一次性替换 App Center？ 不建议。先并跑一周，保留 App Center 最后成功产物与新流水线产物的版本号、符号表和签名校验记录。
• 托管 CI 会不会泄露私有依赖？ 风险来自权限过宽而不是平台本身。只读 token、短 TTL、仓库级 secret 和固定出口白名单要同时做。
• 按天云 Mac 是否适合长期跑？ 如果构建高峰集中在发版周，按天更灵活；如果每天都有稳定负载，再升级为常驻 Runner 池。
• 回滚点放在哪里？ 放在脚本和签名材料清单，不只放在 CI YAML。能在任意一台干净 Mac 上复现 Archive，才算迁移完成。

最终选择可以很务实：托管 CI 负责标准化、低权限、可审计的部分；云 Mac Runner 负责 App Center 停用窗口里最怕中断的 iOS 原生构建与签名。两条链路并跑到日志、产物和回滚手册都稳定，再下线旧流程。