1. 简介
在 Rapido 云 (www.rapido.cloud) 中，我正在开发一个 Salesforce 客户的移动应用程序，使他们能够轻松部署自己的品牌移动应用程序，而无需通过 Salesforce Mobile __CAPGO_KEEP_0__ 或 Salesforce Mobile Publisher 的困难环节Rapido 云), I am developing a mobile application for Salesforce clients to easily deploy their own branded mobile application without having to go through the difficult loops of using the Salesforce Mobile SDK or the Salesforce Mobile Publisher.
我已经在一个现代化的、标准化的平台上开发了这个移动应用，使用了广泛的组件和工具，包括Ionic 8、Angular 18、TypeScript、Capacitor 和现在是 Capgo CapacitorUpdater。这些对于不想管理Salesforce平台具体细节的客户来说更简单，例如Lightning Web Components；而且对于我来说更容易、更便宜地招募开发者和维护者来 Ionic + Angular 移动应用。
本文将解释我设计、选择和实现的方法，使得 Capgo 成为管理所有部署的自动化过程的非常简单、非常明智的选择。 semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.
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 请求触发 当 pull 请求被合并到部署分支时
我不使用标签触发的部署，因为语义发布管理标签和所有其他内容
GitLab 流程 GitLab 流程 - 源
https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
语义发布的工作原理：一则附注 alpha, beta, 等等在版本号中。
语义发布从您的提交生成更改日志，按照 conventional commits（请参见 https://www.conventionalcommits.org/en/about）和语义发布配置的定义，将修复和功能分组。 它还将更新所有您的 git（在我的情况下是 __CAPGO_KEEP_0__）合并的 pull 请求和相关问题，通过评论将它们链接到标签和发布。最后，在本次 __CAPGO_KEEP_1__ 发布中，它将附加资产，如源 __CAPGO_KEEP_2__、二进制文件等。, 等等。
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_KEEP_0__ 部署中执行以下操作。
4. Branches, releases/prereleases, channels in semantic release and in Capgo
Capgo 已经开发并文档化了他们自己的“Conventional Commits”工具，使用他们的 forked repo
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 (github，以及他们自己的 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包遵循“标准”语义版本“语义版本控制”（https://semver.org） semantic-release 这也遵循（显然！)
因此，这很好，给我带来了很大的放心，因为我使用 semantic-release 它非常广泛
I also want semantic release to generate app deployments on different channels
如上所述，我需要从以下分支部署预发布版本 alpha, beta, nightly 例如 production-customer-jones, production-customer-doe例如
Capgo provides the “channels” feature which is exactly what semantic release also supports, so I am excited to make them work together. These also fit in with the different branch builds managed by XCode Cloud (see more about this below).
__CAPGO_KEEP_0__ 提供了“渠道”功能，这正是语义发布也支持的功能，所以我很高兴能让它们一起工作。这些也与 XCode Cloud 管理的不同 branch 构建相吻合（请参见下文）。 1.0.0-alpha.1语义发布在预发布版本上生成的 Semver 版本号类似于 1.0.0-alpha.2, etc. Although not documented explicitly, these version numbers are supported by Capgo, which is great news for me : I will use semantic release channels and prerelease to generate versions of my app with Capgo channels.
，等等。虽然这些版本号没有明确文档，但它们是由 Capgo 支持的，这对我来说是一个好消息：我将使用语义发布的渠道和预发布来生成我的应用的版本号，使用 __CAPGO_KEEP_1__ 渠道。
To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle upload为了自动部署您的应用程序包到 __CAPGO_KEEP_0__，您需要使用 __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ 命令 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 环境，然后调用语义发布。
对于每个在列表中的分支上有 mzerge 的分支 branches当你配置好 semantic release 后，Capgo 会自动触发部署。 CAPGO_APIKEY 在您的仓库中保存的机密信息中更新。 CAPGO_APPID 在这里。
在Capgo中，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"版本号由语义发布生成。x.y.z-development.n- 到Capacitor Updater的部署
alpha并且alpha-nocapgo分支将同时部署到__CAPGO_KEEP_0__上alpha但版本号中有不同的预发布名称 - 将部署到开发者分支
dev-rupert或dev-paul将同时部署到__CAPGO_KEEP_0__上developmentchannel on Capgo, all with the samedevelopment:在语义发布的第一阶段，它检查它是否有正确的访问__CAPGO_KEEP_0__
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-generator:生成以下文件的更改日志文件CHANGELOG.md@semantic-release/git:提交以下文件，已由Ionic应用程序的构建和语义发布工作更新 (package.json,CHANGELOG.md和ios/App/App.xcodeproj/project.pbxproj- 我并没有为 Android 构建)@semantic-release/github: 将文件附加到 __CAPGO_KEEP_0__ 发布作为资产CHANGELOG.mdfile to the Github release as an asset@semantic-release/exec)，然后有效地将应用程序包部署到 __CAPGO_KEEP_0__ 服务器（prepareCmd您会注意到没有任何解释我们如何计算和递增版本号，如何生成更改日志，Capgo 标签或发布等：所有内容都由语义发布默认处理，配置最少publishCmd)
You will notice that their is no fiddling around with explaining how we want the version number to be calculated and incremented, how we need to generate a changelog, a Github tag or release, etc. : everything is handled by default by semantic release, with minimal configuration.
将所有这些与 XCode Cloud 集成，构建应用程序二进制文件的新版本是简单的（我尚未在 Google Play 部署，但该构建应该类似）：
我设置了一个 XCode Cloud 过程，以便在我希望使用的分支上构建（例如
- 在此分支上，我将 XCode Cloud 设置为仅在文件更新时构建。该文件在语义发布生成的每个版本之后都会更新。
production) - 在此分支上
CHANGELOG.md文件 - 我可以在不同分支上触发构建，以模拟不同渠道的部署。在每个 XCode Cloud 构建的配置中，我手动设置一个环境变量，其值为
branch.channel设置为releaserc.json(是的，这是一个手动重复)
在 XCode Cloud 上使用 Capgo 渠道构建应用程序二进制文件
在 XCode Cloud 上使用 __CAPGO_KEEP_0__ 渠道构建应用程序二进制文件
In conclusion, I am very happy to have been able to integrate Capgo CapacitorUpdater into my standard semantic release pipeline, rapidly within the delay of the 14-day trial period, and the result is the following :
- 总之，我很高兴能够在 14 天试用期内快速地将 Capgo CapacitorUpdater integrate 到我的标准语义发布管道中，结果如下：
- semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
- 语义发布会自动部署 __CAPGO_KEEP_0__ 应用程序包，同样利用 __CAPGO_KEEP_1__ 渠道
这与 XCode Cloud 构建应用程序二进制文件的方式非常匹配
I am currently in the development phase of this app. I will quickly make it available to testers through TestFlight (for iOS). Considering the power of Capgo, I will most certainly deploy a free version of the app to the AppStore for tests, which will be updated regularly with Capgo during tests. I will then deploy another (paid) version of the app on the AppStore, under another record, and also update that regularly with Capgo.
I hope to add better pre-build verification of Capgo bundle upload my semantic release configuration.
I now have a clean, simple and reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
作者 - Rupert Barrow
我有超过 22 年的 Salesforce 经验，作为客户和用户，作为合作伙伴和整合者，架构师，开发者，业务分析师和顾问。我共同创立和共同管理 Altius Services 作为 COO 和 CTO 13 年，一个成功的 Salesforce SI 合作伙伴在法国，之后开始了一个新的冒险作为 Salesforce solo 企业家和我的 Rapido 云 您可以在 LinkedIn 上找到我
https://linkedin.com/in/rbarrow 您可以查看我们的 Salesforce 产品.
https://www.rapido-companion.app 和 context https://www.rapido.cloud (开发中).
Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater
如果您正在使用 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater 计划实时更新的交付,连接它到 Capgo Live Updates for the product workflow in Capgo Live Updates, 概览 为实现细节在概览中 功能 为实现细节在功能中 更新行为 对于更新行为的实现细节，以及 更新类型 对于更新类型的实现细节。
