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

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 上开发。

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.

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.

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

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

开发在 feature/... 分支 main上进行 main 并将它们合并到主分支上，主分支是大多数开发分支的参考分支，除了维护和特定功能的定制交付外（关于此后面会详细介绍）
部署将被触发 从发布分支 可能是： production，预发布分支（alpha, beta, nightly，等等）以及客户或上下文特定分支用于自定义交付
部署将由一个拉取请求触发 该拉取请求将被合并到部署分支。我不使用标签触发的部署，因为语义发布管理标签和其他所有内容

基本上，这就是 Gitlab 流程：

Gitlab 流程

Gitlab 流程 - 源 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

语义发布的工作原理的一点说明：

In __CAPGO_KEEP_0__ 分支中，当 semantic-release 被触发时，它将自动计算此分支上的新版本号，依赖于此分支上之前标签的版本号和已交付的修复或功能。修复将创建一个新的小版本号，而功能将创建一个新的小版本号。它还将自动包含预发布版本号 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

在 Capgo 中，semantic-release 将根据您的提交生成 changelog，按照 conventional commits（见 https://www.conventionalcommits.org/en/about）和 semantic release 配置的方式，将修复和功能分组。 standard-version semantic-release 将自动计算此分支上的新版本号，依赖于此分支上之前标签的版本号和已交付的修复或功能。修复将创建一个新的小版本号，而功能将创建一个新的小版本号。 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 包遵循“标准”语义版本“语义版本控制”（https://semver.org)，它 semantic-release 也遵循（显然！）

So 这很好，和对我来说是一个放心的，因为我使用 semantic-release 广泛地。

我还希望语义发布生成不同频道的应用部署。

如上所述，我需要从以下分支部署预发布版本： 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 管理的不同分支构建相吻合（请参见下文）。 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 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 环境，然后调用语义发布。

For every mzerge on a branch listed in branches, semantic release will trigger a deployment. CAPGO_APIKEY Set CAPGO_APPID in your repository’s secrets.

Update your .releaserc.json here.

// .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 The behaviour of semantic release is set in itsname), mapped to the Capgo channel (channelHere are my settings, explained below :prereleasesets the configuration of branches ( branch.prerelease = "development"), mapped to the __CAPGO_KEEP_0__ channel ( x.y.z-development.n
- ) and how the prerelease version number will be called ( alpha和 alpha-nocapgo 将会同时在__CAPGO_KEEP_0__上发布应用，但版本号中有不同的预发布名称 alpha将会同时发布到__CAPGO_KEEP_0__上，但版本号中有不同的预发布名称
- 或 dev-rupert将会同时发布到__CAPGO_KEEP_0__上，但版本号中有不同的预发布名称 dev-paul 将会同时发布到__CAPGO_KEEP_0__上，但版本号中有不同的预发布名称 development将会同时发布到Capgo上，但版本号中有相同的预发布关键字 development:在语义发布的第一阶段，它检查它是否有正确的访问__CAPGO_KEEP_0__。我希望在__CAPGO_KEEP_1__ __CAPGO_KEEP_2__这里添加一个身份验证检查
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 构建的应用程序更新的文件和语义发布工作的文件（commit 这些文件：package.json, CHANGELOG.md and 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)
on this branch, I set XCode Cloud to build only when the CHANGELOG.md 文件已更新。每次生成的语义发布版本后都会更新此文件。
我可以在不同分支上触发构建，以模拟不同渠道的部署。在每个 XCode Cloud 构建配置中，我手动设置一个环境变量，其值为 branch.channel 设置为 releaserc.json (是的，这是一个手动重复)。然后，如果我想要的话，我可以部署一个不同的 AppStore 应用程序，用于每个自定义客户端应用程序，从自定义发布分支部署。

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

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

7. 结论

总之，我很高兴能够在语义发布管道中快速地（在 14 天试用期内）集成 Capgo CapacitorUpdater，结果如下：

语义发布生成的包版本号自动兼容 Capgo 服务器
语义发布自动部署 Capgo 应用程序包，同样利用 Capgo 渠道
这与 XCode Cloud 构建应用程序二进制文件的方式非常匹配

下一步骤

I目前正处于该应用的开发阶段。通过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 我将在语义发布配置中添加更好的预构建验证__CAPGO_KEEP_0__ 和 https://www.rapido.cloud (正在开发中)

从如何Rapido Cloud管理Semantic Release with Capgo CapacitorUpdater

如果您正在使用 如何Rapido Cloud管理Semantic Release with Capgo CapacitorUpdater 来规划实时更新的交付,连接它到 Capgo Live Updates 为产品工作流程在Capgo Live Updates中概述概述功能为 CapGo CapacitorUpdater 的功能细节更新行为为更新行为的功能细节, 和更新类型为更新类型的功能细节。

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