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 的nice 14天免费试用期内设计、测试和文档化的。
2. 为什么使用 Capgo ? 为什么使用semantic-release ?
Capgo CapacitorUpdater吸引了我,因为它承诺可以使移动应用程序部署更加简单、更加快速和更加灵活,远远超过标准的Apple AppStore/Google PlayStore交付过程。 这是我推送到商店的第一款移动应用程序,我过去一直专注于web应用程序,通常在Salesforce Experience Cloud上开发。
我对学习曲线感到有些害怕,但我还是成功地将应用程序推送到了Apple TestFlight。然后,我就可以使用 Capgo CapacitorUpdater 来快速部署我的更新了。
My first requirement and test case was to deploy for myself to test my app as a real mobile app on my own phone, instead of testing in a mobile emulator or in a simulator via the Nexus mobile browser suggested by IIonic. That’s because my app uses native features such as Geolocation or accessing the Photo Gallery and Camera. Not having the past experience of testing a Capacitor mobile app, I wasn’t sure if everything was going to work properly : nothing better than to test the real app, in real conditions !
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如何融入其中
So now I have my delivery to Capgo servers working correctly, I need to automate this and fit it into my CI/CD pipeline.
This is how I organize my branching and release model
对于每个应用,无论是移动端、web端还是Salesforce:
- 开发 是在
feature/...分支main,并且它们会合并到main,这是大多数开发分支的参考,除了维护和特定功能的定制交付(关于此更多信息见下文) - 部署会触发 从发布分支 可能是:
production,预发布分支(alpha,beta,nightly),以及客户或上下文特定分支用于定制交付 - 部署由 pull 请求触发 因为我不使用标签触发的部署,因为 semantic release 管理标签和其他所有内容
基本上,这是 Gitlab 流程:

Gitlab 流程 - 源 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
关于 semantic-release 的一则小贴士:
在部署分支中,当 semantic-release 被触发时,它将自动计算新版本号,依赖于此分支上之前标签的版本号和修复或特性的交付。修复将创建一个新的小版本号,而特性将创建一个新的小版本号。它还自动包含预发布信息 alpha, beta等等版本号。
语义发布从您的提交生成更改日志,按照传统提交(见“https://www.conventionalcommits.org/en/about”)和语义发布配置的定义,将修复和功能分组。 它还将更新所有您的git(例如__CAPGO_KEEP_0__)合并的拉取请求和相关问题,添加评论,链接到标签和发布。最后,在本__CAPGO_KEEP_1__发布中,它将附加资产,如源__CAPGO_KEEP_2__,二进制文件如果必要等。4.语义发布和__CAPGO_KEEP_0__中的branch,release/prerelease,channel
It will also update all your git (Github, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this Github release, it will attach assets such as source code, binaries if necessary, CHANGELOG.md我希望语义发布生成版本号
Capgo已经开发并文档化了他们自己的“传统提交”的版本,
So what I want semantic release to do for Capgo deployments is the following.
https://__CAPGO_KEEP_0__.com/Cap-go/standard-version
Capgo have developed and documented their own version of the “Conventional Commits” standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (https://github.com/Cap-go/standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionhttps://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-version capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionhttps://Capgo.app/blog/how-version-work-in-__CAPGO_KEEP_1__/https://capgo.app/blog/how-version-work-in-capgo/https://semver.org),这也遵循(显然!)因此,这很好,给我带来了很大的 relief,因为我使用 semantic-release 大量
__CAPGO_KEEP_0__ semantic-release __CAPGO_KEEP_1__
I also want semantic release to generate app deployments on different channels
如上所述,我需要从分支,如 alpha, beta, nightly 等,但也需要为客户专属版本在分支,如 production-customer-jones, production-customer-doe等
Capgo 提供的“channels”功能正是 semantic release 支持的,所以我很期待它们能一起工作。这些也与 XCode Cloud 管理的不同 branch builds 相符(详见下文)。
semantic release 在 prereleases 上生成的 Semver 版本号看起来像 1.0.0-alpha.1此 branch 上的连续构建会将 build 号增加到 1.0.0-alpha.2等。虽然这些版本号没有明确的文档,但它们是 Capgo 支持的,这对我来说是一个好消息:我将使用 semantic release 的 channels 和 prerelease 来生成我的应用的版本号,使用 Capgo channels。
5. 如何使用 Capgo 来发布我的应用程序?
为了自动部署您的应用程序包到 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 是由语义发布生成的(例如
1.0.0-alpha.1) - CAPGO_APIKEY 由 Capgo 提供,用于唯一标识您的 CI/CD pipeline 登录
- CAPGO_APPID 由 Capgo 提供,用于唯一标识您的应用(例如
com.mystartup.mysuperapp)
6. 我的语义发布 + Capgo CapacitorUpdate 配置
最后,这些都如何结合起来?

使用语义发布和 Github Actions 构建的应用程序包版本
使用 Github Actions 的语义发布自动化
语义发布的美妙之处在于,部署自动化,形如 Github Action 工作流,非常简单。这将在其他 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 环境,然后调用语义发布。
对于列表中的每个 branch 上的 mzerge 都会 branchessemantic release 将触发部署。
设置 CAPGO_APIKEY 在您的仓库的密钥中。 CAPGO_APPID 更新您的
这里。 .releaserc.json semantic release 的行为由其
// .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), mapped to the Capgo channel (channel),映射到 __CAPGO_KEEP_0__ 频道 (prerelease),以及如何调用预发布版本号 (branch.prerelease = "development")。例如,如果x.y.z-development.n- ,semantic release 生成的版本号将是
alpha部署到alpha-nocapgo分支将同时在alpha频道上发布应用,但版本号中有不同的预发布名称 - 开发者分支的发布
dev-rupert或dev-paul将同时发布到developmentchannel on Capgo, all with the samedevelopment预发布关键字
verifyConditions: in the first stage of semantic release, it checks that it has the correct access to Github. I hope to add an authentication check for the Capgo CLI here later@semantic-release/commit-analyzer。我希望在这里添加一个认证检查https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)@semantic-release/release-notes-generatorhttps://CHANGELOG.md@semantic-release/git.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formatpackage.json,CHANGELOG.md和ios/App/App.xcodeproj/project.pbxproj- 我不建造 Android,@semantic-release/github: 将CHANGELOG.md文件附加到Github发布版本中作为资产@semantic-release/exec: 使用这两个命令来准备应用程序的构建(prepareCmd),然后有效地将应用程序包装部署到Capgo服务器(publishCmd)
您会注意到没有解释我们如何计算和递增版本号,如何生成更改日志,Github标签或发布等:所有这些都由语义发布默认处理,配置最少。
使用 XCode Cloud 构建新二进制文件
将所有这些与 XCode Cloud 构建新版本的应用程序二进制文件集成起来是简单的(我还没有部署到 Google Play,但该构建应该类似):
- 我设置了一个 XCode Cloud 过程来在我希望使用的分支上构建(例如
production) - 在这个分支上,我将 XCode Cloud 设置为仅在
CHANGELOG.md文件更新时构建。这个文件在语义发布生成的每个版本之后都会更新。 - 我可以在不同分支上触发构建,以模拟不同渠道的部署。在每个XCode Cloud构建的配置中,我手动设置一个环境变量,其值为
branch.channel在releaserc.json(是的,这是一个手动重复)然后,如果我想的话,我可以为每个自定义客户端应用程序从自定义发布分支部署不同的AppStore应用程序,正如之前提到的那样。

在XCode Cloud上使用Capgo渠道构建应用程序二进制文件
7. 结论
总之,我非常高兴能够在14天试用期内快速地将Capgo CapacitorUpdater集成到我的标准语义发布管道中,结果如下:
- 语义发布自动为Capgo服务器生成的包版本号
- 语义发布自动部署Capgo应用程序包,并且使用Capgo渠道
- 这与应用程序二进制文件的XCode Cloud构建非常匹配
下一步
我目前正在开发这个应用程序。很快,我会通过TestFlight (对于iOS)将其提供给测试者。考虑到Capgo的力量,我一定会将应用程序的免费版本部署到AppStore进行测试,并且将其定期更新为Capgo。然后,我将在AppStore上部署另一个(付费)应用程序,并且将其定期更新为Capgo。
我希望在语义发布配置中添加更好的预构建验证 Capgo bundle upload prerequisites into my semantic release configuration.
我现在有一个干净、简单、可复现的语义发布管道,用于未来的移动应用程序,开发者使用Ionic + Angular + Capacitor。
作者 - Rupert Barrow
我有超过22年的Salesforce经验,作为客户和用户,作为合作伙伴和整合者,架构师,开发者,业务分析师和顾问。我共同创立和共同管理Altius Services作为COO和CTO13年,法国成功的Salesforce SI合作伙伴, 之前我开始了作为Salesforce独自创业者, Rapido Cloud
产品提供。 您可以在LinkedIn上找到我在.
https://linkedin.com/in/rbarrow 您可以查看我们的Salesforce产品提供在 https://www.rapido-companion.app https://www.rapido.cloud (正在开发中).
从Rapido Cloud如何管理Semantic Release开始,Capgo CapacitorUpdater
如果您正在使用 Rapido Cloud如何管理Semantic Release,Capgo CapacitorUpdater 计划实时更新交付,连接它到 Capgo Live Updates 在Capgo Live Updates中,为产品工作流程 概述 在概述中,查看实现细节 功能 在功能中,查看实现细节 更新行为 为更新行为中的实现细节 更新类型 为更新类型中的实现细节。