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 来更快速地部署我的更新。
I was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.
2. 为什么使用 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，这是大多数开发分支的参考版本，除了维护和特定功能的定制交付（关于这个问题的更多信息请参见下文） - 部署 从发布分支中触发 which may be :
production, 预发布 branch (alpha,beta,nightly, 等）以及客户端或上下文特定分支用于定制交付 - 部署由 pull request 触发 因为我不使用标签触发的部署，因为 semantic release 管理标签和其他所有内容
基本上，这是 Gitlab 流程 :
Gitlab 流程 - 源 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
关于 semantic-release 的一则小贴士 :
在部署 branch 中，当 semantic-release 被触发时，它将自动计算新版本号，依赖于此 branch 上的前一个标签版本号和修复或特性的修订。修复将创建一个新的小版本号，而特性将创建一个新的小版本号。它还自动包含预发布 alpha, beta等等在版本号中。
Semantic release 根据您的提交生成 changelog，按照 conventional commits（请参见 https://www.conventionalcommits.org/en/about) 和 semantic release 的配置进行分组修复和功能。
它还将更新所有您的 git (Github, 在我的情况下) 合并的拉取请求和相关问题，通过评论将它们链接到标签和发布。最后，在本次 Github 发布中，它将附加资产，如源 code、二进制文件（如果需要，等等。 CHANGELOG.md4. semantic release 和 __CAPGO_KEEP_0__ 中的分支、发布/预发布、频道
因此，我希望 semantic release 为 Capgo 部署做的事情是以下几点。
So what I want semantic release to do for Capgo deployments is the following.
__CAPGO_KEEP_0__ 已经开发并文档化了他们自己的“Conventional Commits”工具版本，使用他们的分叉仓库
https://Capgo.com/Cap-go/standard-version standard-version ) 和他们自己的 standard-version (githubCapacitor 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 extensively.
I also want semantic release to generate app deployments on different channels
As mentioned above, I need to deploy prerelease version from branches such as alpha, beta, nightly 等等，但也需要为客户定制的版本在分支上 production-customer-jones, production-customer-doe，等等
Capgo 提供了“频道”功能，这正是语义发布也支持的功能，所以我很期待能让它们一起工作。这些也与 XCode Cloud 管理的不同分支构建相吻合（详见下文）
语义发布在预发布版本上生成的 Semver 版本号类似于 1.0.0-alpha.1。该分支上的连续构建将会将构建号递增到 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 is the Capgo channel to which we want to deploy (eg
alpha) - 版本由语义发布 (例如
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，语义发布都会触发一次部署。
设置 branches__CAPGO_KEEP_0__ 和 __CAPGO_KEEP_1__ 保留未被翻译 CAPGO_APIKEY 在您的仓库的密钥中。
更新您的 CAPGO_APPID 这里。
语义发布的行为由其 .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- 部署到
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: 将文件附加到 __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 构建的不同配置中，我手动设置一个环境变量，其值为 - buildCommand
branch.channel在releaserc.json(是的，这是一个手动重复)然后，如果我想，我可以为每个来自自定义发布分支的自定义客户端应用程序部署一个不同的AppStore应用程序，正如之前提到的那样。
使用XCode Cloud在Capgo频道上构建app二进制文件
7. 结论
总之，我非常高兴能够在14天试用期内快速地将Capgo CapacitorUpdater集成到我的标准语义发布管道中，并且结果如下：
- 语义发布自动为Capgo服务器生成的bundle版本号
- 语义发布自动部署Capgo应用程序包，同样利用Capgo频道
- 这与XCode Cloud构建应用程序二进制文件的方式非常匹配
下一步
我目前正在开发这个应用程序。很快，我将通过TestFlight (用于iOS)将其提供给测试者。考虑到Capgo的力量，我将肯定地将应用程序的免费版本部署到AppStore进行测试，并且将在测试期间定期更新Capgo。然后，我将在AppStore上部署另一个（付费）应用程序，另一个记录，并且也将定期更新Capgo。
我希望能够添加更好的预构建验证Capgo bundle upload 为我的语义发布配置添加必要条件。
我现在有一个干净、简单、可重复的语义发布管道，用于未来的移动应用程序，开发者使用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 (under development).
继续使用How Rapido Cloud管理Semantic Release与Capgo CapacitorUpdater
如果您正在使用 How Rapido Cloud管理Semantic Release与Capgo CapacitorUpdater 计划实时更新交付时,将其与 Capgo Live Updates 在Capgo Live Updates中查看产品工作流程 概览 在概览中查看实现细节 功能 在功能中查看实现细节 更新行为 关于在 Update Behavior 中的实现细节, Update 类型 关于在 Update Types 中的实现细节.
