2026 年 Cordova 应用的最佳 CI/CD 平台通常是通用的 CI 工具，它们可以在 Linux 上运行 Android 版 Cordova CLI，或在 macOS 上运行 iOS 版：GitHub Actions、GitLab CI、Bitrise、Codemagic、Appcircle、CircleCI 或 Azure DevOps。但它们都无法取代 Cordova 团队曾从 App Center 和 Appflow 获得的托管式 live update 服务。本次对比涵盖了各选项的构建支持、签名、应用商店发布、Live Update 以及长期发展前景。
Cordova CI/CD 的现状
曾有三款托管服务构建了 Cordova 生态系统，但目前它们都已停止或即将关闭：
| 服务 | 状态 |
|---|---|
| PhoneGap Build | 已于 2020 年 10 月 1 日停止服务 |
| Microsoft App Center (构建、分发、CodePush) | 2025 年 3 月 31 日退役 |
| Ionic Appflow (构建、Live Update) | 自 2025 年 2 月起不再接受新客户，服务将于 2027 年 12 月 31 日结束 |
Cordova 框架本身仍负责发布平台版本。而转移到你手中的工作则涵盖了构建周边的所有环节：签名存储、应用商店上传、版本号管理以及 Live Update。
如果你现在就需要一个可用的 pipeline，可以从 Cordova 应用的 CI/CD开始，它拥有完整的 GitHub Actions 工作流。本文将帮助你决定在哪里运行它。
Cordova 团队应对比什么
- 对 Cordova 的支持程度。 该平台是否提供 Cordova 步骤或模板，还是需要你自行编写
cordova build脚本？使用脚本也没问题，因为到处都是那三个相同的命令。 - macOS 运行器 需配备 Xcode 26，这是 App Store Connect 自 2026 年 4 月 28 日起的要求。
- 签名存储 用于 Android keystore、iOS certificate 以及 provisioning profiles。
- 应用商店发布 至 TestFlight 和 Google Play 轨道。
- Live Updates 用于修复 Web 层问题。
- Git 托管与自托管，这对通常仍在使用 Cordova 的企业和政府应用很重要。
功能矩阵
| 平台 | Cordova 支持 | iOS 使用 macOS | 托管签名 | 应用商店发布 | Cordova Live Update | 自托管选项 |
|---|---|---|---|---|---|---|
| GitHub 操作 | 脚本化 CLI | 托管式 Apple Silicon | 仅限 Secrets | fastlane 或脚本 | 否 | 自托管 Runner |
| GitLab CI | 脚本化 CLI | 托管版 (beta, Premium/Ultimate) 或自托管 | 安全的文件与变量 | fastlane 及应用商店集成 | 否 | 支持，完整的 GitLab 环境 |
| Bitrise | 专用的 Cordova 构建步骤 | 托管 Apple Silicon 环境 | 是 | 内置构建步骤 | 否 | 否 |
| Codemagic | 有文档的 Ionic Cordova 工作流 | 托管的 Mac mini | 是 | 内置 | 否 | 否 |
| Appcircle | 自定义脚本步骤 | 托管或自建 | 是 | 内置 | 否 | 是的，Appcircle Server |
| CircleCI | 脚本化 CLI | 托管 Apple Silicon | 仅限 Contexts | fastlane | 否 | 自托管 Runner |
| Azure DevOps | 脚本化 CLI | Microsoft 托管 | 安全文件及安装任务 | 存储扩展任务 | 否 | 自托管 Agent，Azure DevOps Server |
| Xcode Cloud | 通过 ci_scripts hooks，仅限 iOS |
Apple 托管 | 自动 | 内置 | 否 | 否 |
| VoltBuilder | 上传 zip、Cordova 和 Capacitor | 托管 | 上传中的证书 | 可直接上架 | 否 | 否 |
| Ionic Appflow 替代方案 | 一流 | 托管 | 是 | 是 | 支持，直至 2027 年底 | 否 |
| Capgo（实时更新） | @capgo/cordova-updater 插件，Cordova iOS 7+ / Android 13+ |
并非 Cordova 的构建服务 | 不适用 | 不适用 | 支持 Channel 和 Rollback | 支持开源后端 |
Capgo 是你所选 CI 的补充而非替代品：你的 CI 负责构建 Cordova 二进制文件，然后 Capgo 实时更新 将仅限 Web 的变更推送至已安装的应用。 Capgo 构建 已为 Capacitor 项目提供文档，因此无法用于构建 Cordova 二进制文件。
逐平台对比
GitHub 操作
在 GitHub 上，Cordova 团队最常用的选择是 Android 构建在 ubuntu-latest 配合 actions/setup-java。iOS 构建在 macos-26 ，并预装了 Xcode 26。你只需从 secrets 中解密 keystore 并 .p12 ，编写一个 build.json，然后运行 cordova build。上传使用 fastlane、 xcrun altool或社区提供的 Play upload actions。虽然没有 Cordova 专用功能，但也并不限制使用。请注意私有仓库的 macOS 分钟成本。
GitLab CI
采用相同的脚本化方式。GitLab.com 为 Premium 和 Ultimate 用户提供托管式 macOS runners（测试版），镜像包括 macos-26-xcode-26。许多受监管的 Cordova 团队使用的自托管 GitLab 实例需要配置自己的 Mac runners。Secure files 是存放 keystore 和 provisioning profile 的理想位置。参见 在 GitLab 中配置 CI/CD.
Bitrise
对 Cordova 支持最明确的移动端 CI。其 step 库包含用于准备项目以及归档 iOS 和 Android 构建的 Cordova steps，同时还支持 code 签名管理和商店发布 steps。如果你想要 UI 驱动的工作流，并且能接受基于积分的计费模式，它的体验最接近早期的 App Center build。
Codemagic
Codemagic 在 codemagic.yaml中详细记录了 Ionic Cordova 构建流程，支持托管 Android keystores，通过 App Store Connect API key 实现 iOS 自动签名，并可发布至 TestFlight 和 Google Play。计费方式按构建分钟数或固定年费计划计算。非常适合喜欢在仓库中使用 YAML 但希望由平台处理签名的团队。
Appcircle
Appcircle 通过在其 iOS 和 Android 构建 pipeline 之上运行工作流自定义脚本来构建 Cordova，并增加了签名身份存储、测试员分发、企业级 App Store 以及商店发布功能。Appcircle Server 可以完全运行在你的基础设施上，这是该列表中自托管能力最强的方案。
CircleCI
在 Linux Docker 执行器上进行 Android 的脚本化 Cordova 构建，在 Apple Silicon macOS 执行器上进行 iOS 构建。使用 fastlane 或 shell 进行签名和 upload。如果你的后端已在使用 CircleCI，那么这套方案很合理。
Azure DevOps
Azure Pipelines 将 Cordova CLI 作为脚本步骤运行，并添加第一方任务，用于从安全文件安装 Apple 证书和 provisioning profiles、进行 Android 签名，以及通过 marketplace 扩展发布到商店。Azure DevOps Server 可满足本地部署需求。许多前 App Center 客户最终选择了这里。
Xcode Cloud
仅 iOS 部分可行。一个 ci_scripts/ci_post_clone.sh hook 会安装 Node、恢复 Cordova platforms，并在 Xcode Cloud 归档生成的项目之前构建 Web 层。由于 Cordova 会在 platforms/ios 构建时生成内容，因此在 workflow 启动时 workspace 路径必须已存在，这让配置过程很麻烦。大多数 Cordova 团队只有在原生应用已经依赖它时才会使用。
VoltBuilder
它是构建服务，而不是 CI：你上传包含签名文件的项目 zip 包，它就会返回适用于 Cordova 和 Capacitor 项目的可直接上架二进制文件。没有 Git 触发器、pipeline 或 Live Updates。适合没有 CI 的小团队。请参阅 VoltBuilder 替代方案 对比页面。
Ionic Appflow 替代方案
它仍然是最完整的 Cordova 平台，涵盖构建、签名、发布和 Live Updates。它也是那个有终止日期的。如果你正在使用 Appflow，问题不在于是否离开，而在于何时离开。请参阅 Appflow 替代方案.
填补 live update 的空白
此列表中的通用 CI 都能生成签名二进制文件。但它们都无法为已安装的应用提供 OTA 更新，而旧的社区热 code 推送插件也已停止维护。对于 Cordova 开发者来说，目前的方案只有 Appflow（有效期至 2027 年底）、自托管更新服务器或 Capgo。
Capgo 通过以下方式支持 Cordova： @capgo/cordova-updater，它镜像了 Capacitor 更新器 API 并使用相同的后端、channels 和 CLI。它需要 Cordova iOS 7+ 和 Cordova Android 13+，且不得与 Capacitor 结合使用。 cordova-plugin-ionic-webview使用您的 Capgo app ID 进行安装：
cordova plugin add @capgo/cordova-updater --variable APP_ID=com.example.app
cordova prepare android ios调用 cordova.plugins.Updater.notifyAppReady() 之后 deviceready 在每次启动时运行，然后在您的 CI 中为仅 Web 版本的发布添加一个步骤：
bun run build
bunx @capgo/cli@latest bundle upload --channel=production添加或升级插件仍需通过应用商店构建；Capgo 会标记那些原生插件与当前运行版本不一致的 bundles。详情请参阅 Cordova updater 文档 以及 live update 兼容性. 完整的 pipeline（包括 live update 任务）位于 Cordova 应用的 CI/CD.
可选：迁移到 Capacitor 能为 CI 带来什么
你无需迁移也能用上 live updates。真正迁移的团队大多是为了 build 这一侧。
Capacitor 可以原样运行大多数 Cordova plugin，保留你的 Web code，并把 native 项目提交到 Git 而不是每次生成，这让 CI build 更可预测。你的 Capgo app ID 和 channels 会继续沿用，只需更换 updater plugin。迁移完成后：
- 你的 Linux CI 任务会运行
bun run build,bunx cap sync，以及bunx @capgo/cli@latest build request按平台执行。iOS 不需要 macOS runner。 - 仅 Web 端的发布将以 live updates 形式发出，包含 channels、回滚和兼容性检查：
bunx @capgo/cli@latest bundle upload --channel production. bunx @capgo/cli@latest build needed告诉 pipeline 到底需不需要 native build。
迁移指南： 从 Cordova 迁移到 Capacitor。如需帮助，请参阅 从 Cordova 迁移到 Capacitor.
如何选择
| 你的情况 | 适用场景 |
|---|---|
| GitHub 上的 Code，小团队，熟悉 YAML | GitHub 操作 |
| 自托管 GitLab 上的 Code，或本地部署需求 | 使用自有 Mac runner 的 GitLab CI、Appcircle Server 或 Azure DevOps Server |
| 想找最接近 App Center 构建的替代方案 | Bitrise 或 Codemagic |
| 完全不用 CI，只需要二进制文件 | VoltBuilder |
| 在 Appflow 或 App Center 之后需要 live updates | 上述任意 CI 加上 Capgo 配合 @capgo/cordova-updater |
| 想要无需 macOS runner 的 iOS build | 迁移到 Capacitor，然后使用 Capgo Build |
从 App Center 或 Appflow 迁移的检查清单
- 下载你的 Android upload keystore 和 iOS distribution 证书
.p12以及私钥。如果私钥由旧平台生成，请在失去访问权限前导出。 - 记录当前的 version code 和 build number，避免新平台上的首次 build 发生冲突。
- 为新的 CI 创建 Google Play 服务账号和 App Store Connect API key。
- 列出旧平台在 build 时注入的所有环境变量。
- 在切换生产前，先跑一个 internal track 和一个 TestFlight build。
- 在旧服务停用前，请提前确定您的 live update 方案。
如需深入了解 iOS 和 Android 的决策细节，请阅读 iOS 应用 CI/CD 平台对比 以及 Android 应用 CI/CD 平台对比.
