1. 引言
在 Rapido Cloud (www.rapido.cloud)，我正在为 Salesforce 客户开发一款移动应用，让他们能轻松部署自有品牌移动应用，而无需经历使用 Salesforce Mobile SDK 或 Salesforce Mobile Publisher 的那些繁琐流程。
我使用一套现代且“标准”的平台开发了这款移动应用，其中包含广泛使用的组件和工具，例如 Ionic 8、Angular 18、TypeScript、Capacitor 以及现在的 Capgo CapacitorUpdater。对于不想处理 Salesforce 平台特定技术（如 Lightning Web Components）的客户来说，这些工具更易于上手；同时，对我而言，招聘和维护 Ionic + Angular 移动应用的开发者也更容易、成本更低。
本文将介绍我的设计思路、技术选型以及实现方案，这些方案让 Capgo 与 semantic-release 通过 Github Actions 自动管理所有部署变得非常成功且毫不费力。这一切都是在 Capgo CapacitorUpdater 为期 14 天的愉快免费试用期内完成设计、测试和文档编写的。
2. 为什么要使用 Capgo？为什么要使用 semantic-release？
Capgo CapacitorUpdater 吸引我的地方在于，它承诺让移动应用部署比走标准的 Apple AppStore/Google PlayStore 发布流程更简单、更快速、更灵活。 这是我第一次将移动应用发布到应用商店，过去我一直专注于 Web 应用，通常是在 Salesforce Experience Cloud 上开发的。
我原本挺担心学习曲线会让这件事难以成功，但实际上我很轻松就把应用传到了 Apple TestFlight。随后，我便能用 Capgo CapacitorUpdater 更快地部署更新。
我的第一个需求也是测试用例：将应用部署到我自己手机上，作为真正的移动应用进行测试，而不是像 Ionic 建议的那样，通过 Nexus 移动浏览器在模拟器或仿真器中测试。这是因为我的应用使用了地理位置、访问相册和相机等原生功能。由于之前没有测试过 Capacitor 移动应用的经验，我不确定一切是否都能正常运行：没有什么比在真实条件下测试真实应用更靠谱的了！
So Capgo CapacitorUpdater helped me update my application on my mobile, live, 1 minute after saving a new feature or fix in my source code : so relieving, and so flexible, and easy to set up !
3. 我的分支与发布模型，以及 semantic-release 如何融入其中
现在，我的交付到 Capgo 服务器的流程已经正常工作，我需要将其自动化，并整合到我的 CI/CD 流水线中。
我是这样组织分支和发布模型的
对于每个应用，无论是移动端、Web 还是 Salesforce：
- 开发 在
feature/...分支上进行main，并合并到main，这是大多数开发分支的基准，维护分支和特定定制交付功能除外（详见下文） - 部署由 发布分支触发 ，这些分支可能是：
production，预发布分支（alpha,beta,nightly等），以及用于定制交付的客户特定或上下文特定分支 - 部署由拉取请求触发 当拉取请求合并到部署分支时。我不使用基于标签的部署，因为 semantic release 会为我管理标签及其他所有事项。
基本上，这就是 Gitlab Flow：
Gitlab Flow - 来源 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
关于 semantic release 工作原理的补充说明：
在部署分支中，当 semantic release 被触发时，它会根据该分支上一个标签的版本号以及交付的修复或功能，自动计算新的版本号。修复会创建新的补丁版本，而功能会创建新的次要版本。它还会自动包含预发布 alpha, beta等标识在版本号中。
Semantic release 根据你的提交生成变更日志，按照 conventional commits 的定义对修复和功能进行分组（参见 https://www.conventionalcommits.org/en/about）并在 semantic release 中配置。
它还会更新所有已合并的 git（在我的情况下是 Github）拉取请求及相关 issue，并添加评论将它们链接到标签和发布。最后，在这次 Github 发布中，它会附加诸如源代码 code、必要时还有二进制文件等资源。 CHANGELOG.md等。
4. semantic release 和 Capgo 中的分支、发布/预发布、通道
因此，我希望 semantic release 为 Capgo 部署执行以下操作。
我希望 semantic release 生成版本号
Capgo 开发并文档化了他们自己的“Conventional Commits”版本 standard-version 工具，以及他们的 fork 仓库 standard-version (https://github.com/Cap-go/standard-version），以及它们自己的 capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version），以及 capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version）仓库。他们在博客中记录了 Capgo 在部署中使用的版本方案（https://capgo.app/blog/how-version-work-in-capgo/）。JavaScript bundles 遵循“标准” semver“语义化版本”（https://semver.org），它 semantic-release 也遵循（显而易见！）
这太棒了，也让我松了一口气，因为我用得 semantic-release 很多。
我还希望 semantic release 能为不同 channel 生成应用部署
如上所述，我需要从诸如 alpha, beta, nightly 等分支部署预发布版本，同时也从诸如 production-customer-jones, production-customer-doe等。
Capgo 提供了“channels”功能，这与 semantic release 支持的功能完全一致，因此我很期待将它们结合起来使用。这些功能也与 XCode Cloud 管理的不同分支构建相契合（详见下文）。
semantic release 在预发布版本中生成的 Semver 版本号看起来像 1.0.0-alpha.1。在此分支上的后续构建会将构建号递增为 1.0.0-alpha.2等。虽然文档中没有明确说明，但这些版本号受 Capgo 支持，这对我来说是个好消息：我将使用 semantic release 的 channels 和 prerelease 来生成带有 Capgo channels 的应用版本。
5. 如何使用 Capgo 发布我的应用程序？
要自动化将您的应用 bundle 部署到 Capgo，您需要使用 Capgo CLI 命令 bundle upload。输入 npx @capgo/cli@latest bundle upload --help 以获取众多上传选项。其中，我们将使用以下选项：
npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID- CHANNEL 是我们想要部署到的 Capgo 通道（例如
alpha) - VERSION 由 semantic release 生成（例如
1.0.0-alpha.1) - CAPGO_APIKEY 由 Capgo 提供，用于唯一标识您的 CI/CD 流水线登录
- CAPGO_APPID 由 Capgo 提供，用于唯一标识您的应用程序（例如
com.mystartup.mysuperapp)
6. 我的 semantic release + Capgo CapacitorUpdate 配置
最后，这一切是如何整合在一起的？
使用 semantic release 和 Github Actions 构建的应用 bundle 版本
使用 Github Actions 实现 semantic release 自动化
semantic release 的美妙之处在于，部署自动化（以 Github Action workflow 的形式）非常简单。在其他 CI/CD 平台上看起来也会非常相似。
# ./github/workflows/release.yml
name: Release
on:
workflow_dispatch:
push:
branches: [alpha, alpha-nocapgo, dev-rupert] # <--- adapt this
env:
CAPGO_APPID: com.mystartup.mysuperapp # <--- adapt this
CAPGO_APIKEY: ${{ secrets.CAPGO_APIKEY }}
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: "npm"
- run: npm install
- run: npx semantic-release
env:
DEBUG: true
GITHUB_TOKEN: ${{ github.token }}这只会安装 NodeJS 环境，然后调用 semantic release。
对于在以下列表中列出的分支上的每次 merge： branches，semantic release 将触发一次部署。
设置 CAPGO_APIKEY 在你的仓库 secrets 中。
更新你的 CAPGO_APPID 这里。
semantic release 的行为在其 .releaserc.json 配置文件。
以下是我的设置，具体说明如下：
// .releaserc.json
{
"branches": [
{
"name": "release",
"channel": "production"
},
{
"name": "alpha",
"channel": "alpha",
"prerelease": "alpha"
},
{
"name": "alpha-nocapgo",
"channel": "alpha",
"prerelease": "alpha-nocapgo"
},
{
"name": "dev-rupert",
"channel": "development",
"prerelease": "development"
},
{
"name": "dev-paul",
"channel": "development",
"prerelease": "development"
}
],
"ci": true,
"debug": true,
"dryRun": false,
"repositoryUrl": "https://github.com/RupertBarrow/mysuperapp",
"verifyConditions": ["@semantic-release/github"],
"plugins": [
[
"@semantic-release/commit-analyzer",
{
"preset": "angular",
"releaseRules": [
{ "type": "breaking", "release": "major" },
{ "type": "feat", "release": "minor" },
{ "type": "fix", "release": "patch" },
{ "type": "ci", "release": "patch" },
{ "type": "doc", "release": "patch" },
{ "type": "docs", "release": "patch" },
{ "type": "refactor", "scope": "core-*", "release": "minor" },
{ "type": "refactor", "release": "patch" },
{ "scope": "no-release", "release": false }
]
}
],
"@semantic-release/release-notes-generator",
["@semantic-release/changelog", { "changelogFile": "CHANGELOG.md" }],
[
"@semantic-release/git",
{
"assets": ["package.json", "CHANGELOG.md", "ios/App/App.xcodeproj/project.pbxproj"],
"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
}
],
["@semantic-release/github", { "assets": ["CHANGELOG.md"] }],
[
"@semantic-release/exec",
{
"prepareCmd": "npm run build",
"publishCmd": "npm add -D @capgo/cli && npx @capgo/cli bundle upload --channel ${branch.channel} --apikey $CAPGO_APIKEY --bundle ${nextRelease.version} --bundle-url $CAPGO_APPID"
}
]
]
}branches:branches设置各分支的配置（name），映射到 Capgo 通道（channel）以及预发布版本号的命名方式（prerelease）。例如，如果branch.prerelease = "development"，semantic release 生成的版本号将是x.y.z-development.n- 部署到
alpha以及alpha-nocapgo分支都会将应用部署到alpha通道，但版本号中的预发布名称不同 - 部署到开发分支
dev-rupert或dev-paul都会部署到developmentCapgo 上的 channel，且版本号中都带有相同的developmentprerelease 关键字
verifyConditions: 在 semantic release 的第一阶段，它会检查对 Github 的访问权限是否正确。我希望之后能在这里为 Capgo CLI 添加身份验证检查@semantic-release/commit-analyzer: 标准的 semantic release 操作 - 参见其文档 (https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generator: 将 changelog 文件生成为CHANGELOG.md@semantic-release/git提交以下由应用的 Ionic 构建和 semantic release 流程更新过的文件 (package.json,CHANGELOG.md以及ios/App/App.xcodeproj/project.pbxproj- 我目前还不构建 Android 版本)@semantic-release/github: 将CHANGELOG.md文件作为 asset 附加到 Github release 中@semantic-release/exec：使用以下 2 条命令来准备应用构建（prepareCmd），然后实际构建应用 bundle 并部署到 Capgo 服务器（publishCmd)
你会注意到，无需纠结如何计算和递增版本号，如何生成 changelog、Github tag 或 release 等：semantic release 默认处理所有事项，配置极简。
使用 XCode Cloud 构建新二进制文件
将所有这些与 XCode Cloud 集成以构建新应用二进制版本很简单（我尚未部署到 Google Play，但该构建应类似）：
- 我设置了一个 XCode Cloud 流程，在我希望用于此的分支（例如
production) - 在此分支上，我设置 XCode Cloud 仅在
CHANGELOG.md文件更新时构建。该文件在 semantic release 生成每个版本后更新 - 我可以针对不同分支触发 build，来模拟不同 channel 的部署。在 XCode Cloud 每个针对不同分支的 build 配置中，我都会手动设置一个环境变量，其值为
branch.channel设置于releaserc.json（是的，这是手动重复操作）接着，如果需要，我可以像前文提到的那样，为从自定义 release 分支部署的每个定制客户应用，部署不同的 AppStore 应用。
在 XCode Cloud 上使用 Capgo channels 构建应用二进制文件
7. 总结
总之，我很高兴能在 14 天试用期内快速将 Capgo CapacitorUpdater 集成到我的标准 semantic release pipeline 中，结果如下：
- bundle 版本号由 semantic release 自动生成，并与 Capgo 服务器兼容
- semantic release 会自动部署 Capgo 应用 bundle，同时也用到了 Capgo channels
- 这与 XCode Cloud 的应用二进制文件 build 配合得非常好
后续步骤
目前该应用处于开发阶段。我会通过 TestFlight (iOS) 快速提供给测试人员。考虑到 Capgo 的强大功能，我肯定会先在 AppStore 部署一个免费版进行测试，并在测试期间通过 Capgo 定期更新。随后，我会在另一个记录下部署另一个（付费）版本的应用，并同样使用 Capgo 定期更新。
我希望在我的 semantic release 配置中，为 Capgo bundle upload 前提条件加入更好的构建前验证。
现在，对于未来使用 Ionic + Angular + Capacitor 开发的移动应用，我已经有了一套干净、简单且可复现的 semantic release pipeline。
作者 - Rupert Barrow
我在 Salesforce 领域拥有超过 22 年的经验，身份涵盖客户、用户、合作伙伴、集成商、架构师、开发人员、业务分析师和顾问。我曾共同创立并共同管理 Altius Services（法国一家成功的 Salesforce SI 合作伙伴），担任 COO 和 CTO 长达 13 年；之后，作为 Salesforce 独立创业者，我带着我的 Rapido Cloud 产品系列，踏上新征程。
你可以在 LinkedIn 上找到我： https://linkedin.com/in/rbarrow.
你可以在这里查看我们的 Salesforce 产品与服务： https://www.rapido-companion.app 以及 https://www.rapido.cloud （开发中）。
继续了解 Rapido Cloud 如何使用 Capgo CapacitorUpdater 管理 Semantic Release
如果你正在使用 Rapido Cloud 如何用 Capgo CapacitorUpdater 管理 Semantic Release 要规划 live update 的交付，请将其与 Capgo Live Update 用于 Capgo Live Updates 中的产品工作流， 概览 用于 Overview 中的实现细节， 功能 用于 Features 中的实现细节， 更新行为 有关 Update Behavior 中的实现细节，请参阅 更新类型 关于 Update Types 中的实现细节。
