如何Rapido Cloud使用Capgo CapacitorUpdater管理语义发布

1. 简介

在 Rapido 云 (www.rapido.cloud) 中，我正在开发一个 Salesforce 客户的移动应用程序，使他们能够轻松部署自己的品牌移动应用程序，而无需通过使用 Salesforce Mobile SDK 或 Salesforce Mobile Publisher 的困难环节

I在使用现代且“标准”的平台开发了这个移动应用，平台上有广泛的组件和工具，包括Ionic 8、Angular 18、TypeScript、Capacitor 和现在是 Capgo CapacitorUpdater。这些对于不想管理Salesforce平台具体细节的客户来说更简单，例如Lightning Web Components；而且，对于我来说更容易招募Ionic + Angular移动应用的开发者和维护者。

This篇文章解释了我的设计、我的选择和实现，使得 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来快速部署我的更新。

Capgo CapacitorUpdater的吸引力在于它承诺使移动应用部署更加简单、更加快速和更加灵活，远远超过标准的Apple AppStore/Google PlayStore交付过程。

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 在其中的作用

现在我已经将我的交付到 Capgo 服务器正确设置，我需要自动化并将其整合到我的 CI/CD pipeline 中

这是我如何组织我的分支和发布模型

对于每个应用程序，无论是移动、web 还是 Salesforce :

开发在 feature/... 分支 main并且它们合并到 main 这是大多数开发分支的参考，除了维护和特定功能的定制交付（更多信息请参见下文）
部署触发 from release branches which may be : production, prerelease branches (alpha, beta, nightly, etc.) and also customer-specific or context-specific branches for custom deliveries
deployments are triggered by a pull request being merged into a deployment branch. I don’t use tag-triggered deployments because semantic release manages tags and all the rest for me.

Basically, this is the Gitlab Flow :

Gitlab Flow

Gitlab Flow - source https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

A side-note on how semantic-release works :

In a deployment branch, when semantic-release is triggered, it will automatically calculate the new version number on this branch, depending on the version number of the previous tag on the branch and the delivered fixes or features. Fixes will create a new patch version, whereas features will create a new minor version. It also automatically includes the prerelease alpha, beta, 等等版本号。

Semantic release 根据您的提交生成 changelog，按照 conventional commits（见 https://www.conventionalcommits.org/en/about) 和 semantic release 的配置方式进行分组。它还将更新所有您的 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因此，我希望 semantic release 为 __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 tool, with their forked repo 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 包文件遵循“标准”的语义版本“Semantic Versioning”（https://semver.org)，也遵循（显然！） semantic-release 因此，这很好，给我带来了很大的放心，因为我使用

非常广泛。 semantic-release https://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version

我还想让semantic release在不同频道上生成应用程序部署

如上所述，我需要从名为的分支部署预发布版本 alpha, beta, nightly 等等，但我也需要为客户专属版本在名为的分支上部署 production-customer-jones, production-customer-doe等等

Capgo提供了“频道”功能，这正是semantic release也支持的功能，所以我很高兴能让它们一起工作。这些也与XCode Cloud管理的不同分支构建相吻合（请参见下文）

semantic release在预发布版本上生成的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支持的，这对我来说是好消息：我将使用semantic release的频道和预发布来生成我的应用程序的版本号

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 是由 semantic release 生成的（例如 1.0.0-alpha.1)
CAPGO_APIKEY 由 Capgo 提供，用于唯一标识您的 CI/CD pipeline 登录
CAPGO_APPID 由 Capgo 提供，用于唯一标识您的应用程序（例如 com.mystartup.mysuperapp)

6. 我的 semantic release + Capgo CapacitorUpdate 配置

最后，这些都如何结合起来？

使用 semantic release 和 Github Actions 构建的应用程序包版本

使用 semantic release 和 Github Actions 构建的应用程序包版本

使用 Github Actions 的 semantic release 自动化

semantic release 的美妙之处在于，部署自动化，形如 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 环境，然后调用 semantic release。

对于列表在 __CAPGO_KEEP_0__ 中的每个 branch 上的 mzerge branchessemantic release 将触发部署。 CAPGO_APIKEY 在您的仓库的密钥中设置。 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 将同时发布到 developmentchannel on Capgo, all with the same development预发布关键字
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 https:// CHANGELOG.md
@semantic-release/git .com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formatpackage.json, CHANGELOG.md 和- 我不建造 Android，然而) ios/App/App.xcodeproj/project.pbxproj : 将文件附加到 __CAPGO_KEEP_0__ 发布版本中作为资产
@semantic-release/github : 使用这两个命令来准备应用程序的构建（ CHANGELOG.md )，然后有效地将应用程序包装部署到 Github 服务器（
@semantic-release/exec您会注意到没有任何解释我们如何计算和递增版本号，如何生成更改日志，__CAPGO_KEEP_0__ 标签或发布等：所有这些都由语义发布处理，配置最小化。prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (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 过程，用于在我希望使用的分支上构建（例如

在此分支上，我将 XCode Cloud 设置为仅在

文件更新时构建。这是在每次由语义发布生成的版本之后更新的。 production)
在此分支上，我将 XCode Cloud 设置为仅在 CHANGELOG.md 文件更新时构建。这是在每次由语义发布生成的版本之后更新的。
我可以在不同分支上触发构建，以模拟不同渠道的部署。在每个XCode Cloud构建的配置中，我手动设置一个环境变量，其值为 branch.channel 在 releaserc.json （是的，这是一个手动重复）然后，如果我想要的话，我可以部署每个自定义客户端应用程序的不同AppStore应用程序，正如之前提到的那样。

在XCode Cloud上使用Capgo渠道构建应用程序二进制文件

在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.

我有超过22年的Salesforce经验，作为客户和用户，作为合作伙伴和整合者，架构师，开发人员，业务分析师和顾问。我共同创立并共同管理Altius Services作为COO和CTO13年，法国成功的Salesforce SI合作伙伴，之后开始了作为Salesforce独家创业者的新冒险，我的

Rapido Cloud 产品提供 您可以在LinkedIn上找到我

https://linkedin.com/in/rbarrow 您可以查看我们的Salesforce产品提供.

https://www.rapido-companion.app and and https://www.rapido.cloud 正在开发中。

Rapido 云如何使用 Capgo CapacitorUpdater 进行语义发布