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？为什么使用语义发布？
Capgo CapacitorUpdater吸引了我，因为它承诺可以使移动应用程序的部署更加简单、快速和灵活，远远超过通过标准的Apple AppStore/Google PlayStore交付过程。 这是在过去专注于web应用的基础上，我第一次推送到商店的移动应用程序。 我过去专注于开发web应用，通常在Salesforce Experience Cloud上开发。
Capgo CapacitorUpdater使我能够轻松地将我的应用程序推送到Apple TestFlight，我然后可以使用Capgo CapacitorUpdater来部署我的更新更快。
我的第一个要求和测试案例是将应用程序部署到我的手机上，作为一个真正的移动应用程序，而不是在移动模拟器或在IIonic建议的Nexus移动浏览器中测试。因为我的应用程序使用native特性，如地理位置或访问相册和摄像头。没有过去的经验来测试Capacitor移动应用程序，我不确定一切是否会正常工作：没有比在真实条件下测试真实应用程序更好的方法了！
Capgo CapacitorUpdater帮助我在我的手机上更新应用程序，实时，1分钟后保存新功能或修复到我的源code：这太放心了，太灵活了，太容易设置了！
3. 我的分支和发布模型，以及semantic-release如何融入
现在我已经将Capgo服务器的交付工作正确完成了，我需要自动化并将其融入我的CI/CD管道
这是我如何组织我的分支和发布模型
对于每个应用程序，无论是移动、web还是Salesforce：
- 开发 在
feature/...分支main并且它们被合并到main这是大多数开发分支的参考，除了维护和特定特性外（关于此的更多信息请参见下文） - 部署 从发布分支 可能是：
production，预发布分支（alpha,beta,nightly，等等）以及客户专用或上下文专用分支用于定制交付 - 通过 pull 请求触发部署 因为语义发布管理标签和其他所有内容，所以我不使用基于标签的部署
基本上，这是 Gitlab 流程 :
Gitlab 流程 - 源 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
语义发布的工作原理 :
在部署分支中，当语义发布被触发时，它会自动计算新版本号，根据分支上的上一个标签的版本号和修复或新功能的提交。修复会创建一个新的小版本号，而新功能会创建一个新的小版本号。它还自动包含预发布版本号 alpha, beta，等等。
语义发布从您的提交生成更改日志，按照传统提交（请参见 https://www.conventionalcommits.org/en/about)和语义发布配置的方式分组修复和新功能
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, 等。
4. 分支、发布/预发布、语义发布中的通道和 Capgo
因此，我希望语义发布在 Capgo 部署中执行以下操作。
我希望语义发布生成版本号
Capgo 已经开发并文档化了他们自己的 "Conventional Commits" standard-version 工具，使用他们的分叉仓库 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 如上所述，我需要从分支，如
等等，部署预发布版本
但我也需要从分支，如 alpha, beta, nightly 等等，部署客户专属版本 production-customer-jones, production-customer-doe, etc.
Capgo 提供了“频道”功能，这正是语义发布也支持的功能，所以我很高兴能让它们一起工作。这些也与 XCode Cloud 管理的不同 branch 构建相吻合（请参见下文）。
语义发布在预发布版本中生成的 Semver 版本号看起来像 1.0.0-alpha.1连续构建此 branch 的 build 号将增加到 1.0.0-alpha.2等等。虽然这些版本号没有明确文档，但它们是由 Capgo 支持的，这对我来说是一个好消息：我将使用语义发布的频道和预发布来生成我的应用的版本号 Capgo 频道。
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 is the Capgo channel to which we want to deploy (eg
alpha) - CHANNEL 是我们要部署的 __CAPGO_KEEP_0__ 频道（例如
1.0.0-alpha.1) - CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
- CAPGO_APIKEY 由 Capgo 提供，用于唯一标识您的 CI/CD pipeline 登录（例如
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_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"，semantic release将生成的版本号将是x.y.z-development.n- 部署到
alpha和alpha-nocapgo分支将同时部署应用到alpha频道，但版本号中使用不同的预发布名称 - 部署到开发分支
dev-rupert或dev-paul将会同时部署到__CAPGO_KEEP_0__频道，所有版本号都带有相同的预发布关键字development在Capgo频道上，所有版本号都带有相同的预发布关键字development在版本号中使用预发布关键字
verifyConditions:在语义发布的第一阶段，它检查是否有正确的访问权限Github。我希望在Capgo CLI这里添加一个身份验证检查@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:将以下文件作为更新的文件提交package.json,CHANGELOG.md并且ios/App/App.xcodeproj/project.pbxproj不支持Android@semantic-release/github:将文件附加到__CAPGO_KEEP_0__发布作为一个资产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（是的，这是一个手动重复）然后，如果我想要的话，我可以部署一个不同的 AppStore 应用程序，用于每个自定义客户端应用程序，从自定义发布分支部署。releaserc.json使用 XCode Cloud 构建应用程序二进制文件，使用__CAPGO_KEEP_0__渠道
使用 XCode Cloud 在 Capgo 通道上构建应用程序二进制文件
7. 结论
总之，我非常高兴能够在 14 天试用期内快速将 Capgo CapacitorUpdater интег理到我的标准语义发布管道中，并且结果如下：
- 语义发布自动为 Capgo 服务器生成的捆绑包版本号
- 语义发布自动部署 Capgo 应用程序捆绑包，同样利用 Capgo 通道
- 这与 XCode Cloud 构建应用程序二进制文件的方式非常匹配
下一步
我目前正在开发这个应用程序。很快，我将通过 TestFlight (用于 iOS) 将其提供给测试者。考虑到 Capgo 的力量，我将肯定地将应用程序的免费版本部署到 AppStore 进行测试，并且将在测试期间定期更新 Capgo。然后，我将在 AppStore 上部署另一个 (付费) 应用程序版本，并且也将定期更新 Capgo。
我希望将 Capgo 的更好的预构建验证条件添加到我的语义发布配置中。 bundle upload 现在，我有一个干净、简单、可复制的语义发布管道，用于将来开发的 Ionic + Angular + __CAPGO_KEEP_0__ 移动应用程序。
I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.
下一步
I有超过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 (正在开发中)
继续阅读How Rapido Cloud管理Semantic Release with Capgo CapacitorUpdater
如果您正在使用 How Capgo Cloud manage Semantic Release with Capgo CapacitorUpdater to plan live update delivery, connect it with Capgo Live Updates for the product workflow in Capgo Live Updates 概览 for the implementation detail in 概览 功能 for the implementation detail in 功能 更新行为 for the implementation detail in 更新行为 更新类型 for the implementation detail in 更新类型
