2026年比较Cordova应用的最佳CI/CD平台

2026年最佳Cordova应用的CI/CD平台通常是一个通用的CI, 可以在Linux上运行Cordova CLI 来构建Android应用, 并在macOS上运行Cordova GitHub 来构建iOS应用: GitHub 动作, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, 或 Azure DevOps. 但它们无法取代的是App Center 和 Appflow 为 Cordova 团队提供的管理 live update 服务. 本文对比了每个选项的构建支持, 签名, 应用商店发布, 实时更新, 和长期展望.

Cordova CI/CD的位置

三个管理服务构建了Cordova生态系统, 但所有三个都消失或关闭:

框架仍在发布平台版本。您处理的工作是围绕构建的所有内容：签名、存储、上传到商店、版本号和即时更新。

如果您只需要今天就能工作的管道，请从 开始使用 Cordova 应用程序的 CI/CD,它具有完整的GitHub Actions 工作流程。这篇文章将帮助您选择在哪里运行它。

Cordova 团队应该比较什么

1. Cordova 知名度 该平台是否有 Cordova 步骤或模板，还是您需要编写脚本？ cordova build 编写脚本是可以的；它在任何地方都是相同的三个命令。
2. macOS 运行器 使用 Xcode 26，App Store Connect 自 2026 年 4 月 28 日起要求使用。
3. 签名存储 用于 Android keystore、iOS 证书和配置文件的存储。
4. 应用商店发布 到 TestFlight 和 Google Play 轨道。
5. 实时更新 用于 web 层面的修复
6. Git 主机和自主主机，对于企业和政府应用程序来说很重要，因为它们经常仍然运行 Cordova。

功能矩阵

Capgo 与您选择的 CI 并存，而不是取代它：您的 CI 构建 Cordova 二进制文件， Capgo 实时更新 将仅限 web 的更新推送到已安装的应用。 Capgo 构建 对于Capacitor项目有详细文档，因此不适合用于构建Cordova二进制。

平台对比

GitHub 操作

Cordova 团队中最常用的选择是在 GitHub. Android 构建上 ubuntu-latest 与 actions/setup-java. iOS基于 macos-26 使用 Xcode 26 .p12 解密密钥库并 build.json从 secrets 中读取 cordova build, 写入 xcrun altool, 运行

. 使用 fastlane 上传

, 或社区 Play 上传动作。没有 Cordova 特定功能，但也没有阻止您。私有存储库中的 macOS 分钟成本。 macos-26-xcode-26GitLab CI 相同的脚本方法。 GitLab.com 上的托管 macOS 运行器适用于 Premium 和 Ultimate 的 beta 版本，具有像.

Bitrise

拥有最明确Cordova支持的移动CI。其步骤库包含了Cordova步骤，用于准备项目和存档iOS和Android构建，包括code签名管理和商店发布步骤。如果您想要一个UI驱动的工作流程，并且愿意接受基于信用计费的价格，那么它是最接近旧版App Center构建体验的东西。

Codemagic

Codemagic文档中提到了Ionic Cordova构建 codemagic.yaml,包括托管的Android密钥库，通过App Store ConnectAPI密钥实现的自动iOS签名，以及发布到TestFlight和Google Play。价格是按构建分钟计费或固定年度计划。适合喜欢在仓库中使用YAML但又希望签名处理的团队。

Appcircle

Appcircle通过其iOS和Android构建管道上的自定义脚本来构建Cordova，并添加了签名身份存储、测试者分发、企业应用商店和商店发布。Appcircle Server可以完全在您的基础设施上运行，这是本列表中最强大的自主托管故事。

CircleCI

在Linux Docker执行器上脚本Cordova构建Android，在Apple Silicon macOS执行器上脚本iOS构建。签名和上传是通过fastlane或shell实现的。如果CircleCI已经运行您的后端，那么这是一个合理的选择。

Azure DevOps

Azure Pipelines 将 Cordova CLI 作为脚本步骤运行，并添加了用于从安全文件安装 Apple 证书和配置文件、Android 签名和通过市场扩展发布应用的首发任务。Azure DevOps Server 覆盖了本地需要。许多前 App Center 客户都来到了这里。

Xcode Cloud

仅限 iOS 一半。 A ci_scripts/ci_post_clone.sh hook 安装 Node，恢复 Cordova 平台，构建 web 层，然后 Xcode Cloud 将生成的项目存档。由于 Cordova 在构建时生成，因此工作区路径必须存在于工作流启动时，这使得设置变得不方便。许多 Cordova 团队只使用它，如果他们已经依赖它来构建原生应用。 platforms/ios VoltBuilder

VoltBuilder

A build service rather than a CI: you upload a zip of your project with signing files, and it returns store-ready binaries for Cordova and Capacitor projects. No Git triggers, pipelines, or live updates. Useful for small teams without a CI. See Ionic Appflow.

仍然是最完整的 Cordova 平台，具有构建、签名、发布和实时更新功能。它也是最终期限的平台。如果您使用 Appflow，则问题不在于是否离开，而在于何时离开。请参阅

Alternative to Appflow 填补 __CAPGO_KEEP_0__ 空白.

填补live update空白

每个一般的CI在此列表中都可以生成签名的二进制文件。它们都无法将应用程序的更新推送到已安装的应用程序中，旧的社区热 code 推送插件也没有维护。对于Cordova来说，到2027年底，Appflow，自主托管的更新服务器，或者 Capgo 都是唯一的选择。

Capgo 支持Cordova通过 @capgo/cordova-updater,它反映了 Capacitor 更新器 API 并使用相同的后端，通道和 CLI.它需要Cordova iOS 7+和Cordova Android 13+，并且不能与 cordova-plugin-ionic-webview使用您的Capgo应用ID安装它。

cordova plugin add @capgo/cordova-updater --variable APP_ID=com.example.app
cordova prepare android ios

Call cordova.plugins.Updater.notifyAppReady() context deviceready 在每次启动后

bun run build
bunx @capgo/cli@latest bundle upload --channel=production

原生插件升级或添加仍需要重新构建应用商店包；Capgo标记了与Live Update中原生插件不同的bundle。 插件添加或升级仍然需要一个商店构建； __CAPGO_KEEP_0__ 标记了与实时更新不同的本机插件的捆绑包。详见 和 live update 兼容性.整个管道，包括 live update 任务，位于 Cordova 应用程序的 CI/CD.

可选：将 Capacitor 迁移到 CI 中会添加什么

您不必迁移到获取实时更新。迁移到 __CAPGO_KEEP_0__ 的团队主要是为了构建方面。

Capacitor 会以原样运行大多数 Cordova 插件，保留您的 web code，并将本机项目提交到 Git 代替生成它们，这使 CI 构建更可预测。您的 Capgo 应用程序 ID 和频道会保留下来，只有更新器插件会发生变化。迁移后：

• 您的 Linux CI 任务会运行 bun run build, bunx cap sync,并且每个 bunx @capgo/cli@latest build request 平台都有一个。没有 macOS 运行器需要用于 iOS。
• 仅限 Web 的发布会以实时更新的形式发布，包括频道、回滚和兼容性检查： bunx @capgo/cli@latest bundle upload --channel production.
• bunx @capgo/cli@latest build needed 告诉管道是否需要本机构建。

迁移指南： 从 Cordova 迁移到 Capacitor。如果您需要帮助，请参见 Cordova 到 Capacitor.

如何选择

从 App Center 或 Appflow 迁移的检查清单

• 下载您的 Android 上传密钥和 iOS 分发密钥 .p12 与私有密钥一起。 如果旧平台生成了它们，请在失去访问权限之前导出。
• 记录当前版本代码和构建号，以便新平台的第一个构建不会冲突。
• 创建一个 Google Play 服务账户和一个 App Store Connect API 密钥用于新 CI。
• 列出旧平台在构建时间注入的每个环境变量。
• 在切换生产之前，运行一个内部跟踪和一个 TestFlight 构建。
• 在旧服务关闭之前，而不是之后，决定您的 live update 计划。

对于iOS和Android的决策更深入了解，请阅读 比较CI/CD平台 和 比较CI/CD平台.