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在学习曲线方面感到有些害怕，但我还是成功地将应用程序推送到了Apple TestFlight。然后，我就可以使用CapgoCapacitorUpdater轻松地部署更新。

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 !

CapgoCapacitorUpdater帮助我在手机上实时更新应用程序，仅仅1分钟后就可以保存新功能或修复源码code：这真是太方便了，太灵活了，设置起来也很容易。

3. 我的分支和发布模型，以及semantic-release如何融入其中

现在我已经将应用程序的交付到Capgo服务器上工作正常了，我需要自动化这个过程并将其融入CI/CD管道中。

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

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

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

Gitlab Flow

Gitlab Flow - 源

https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 关于semantic-release如何工作的一点附注：

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

In 部署分支中，当 semantic-release 被触发时，它将自动计算此分支上的新版本号，依赖于此分支上之前标签的版本号和交付的修复或功能。修复将创建一个新的小版本号，而功能将创建一个新的小版本号。它还将自动包含预发布版本号等信息。 alpha, betasemantic-release 根据您的提交生成 changelog，按照 conventional commits（见 https://www.conventionalcommits.org/en/about）和 semantic-release 配置的方式，将修复和功能分组。

它还将更新所有您的 git（在我的情况下是 __CAPGO_KEEP_0__）合并的拉取请求和相关问题，添加评论并将它们链接到标签和发布。最后，在此 __CAPGO_KEEP_1__ 发布中，它将附加源代码（__CAPGO_KEEP_2__）、二进制文件等。 4. semantic-release 和 __CAPGO_KEEP_0__ 中的分支、发布/预发布、通道。因此，我希望 semantic-release 为 __CAPGO_KEEP_0__ 部署做的事情是以下几点。

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__ 已经开发并文档化了他们自己的“Conventional Commits”工具，使用他们的分叉仓库。

Capgo

So what I want semantic release to do for Capgo deployments is the following.

__CAPGO_KEEP_1__

Capgo standard-version __CAPGO_KEEP_0__ 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遵循“标准”的语义版本“Semantic Versioning”（https://semver.org），这也遵循（显然！） semantic-release 所以这很好，给我带来了 relief，因为我使用

translations semantic-release 广泛地。

我还希望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 To get the numerous upload options. Among those, we will use the following :

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 Actions 工作流，非常简单。这将在其他 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。

对于每个 branch 列表中的每个 mzerge branches, semantic release 将触发部署。 CAPGO_APIKEY 在您的仓库的 secrets 中设置 CAPGO_APPID 在您的仓库的 secrets 中设置

在这里。 .releaserc.json semantic release 的行为由其

// .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), mapped to the Capgo channel (channel设置 branch 的配置（prerelease),映射到 __CAPGO_KEEP_0__ 频道（ branch.prerelease = "development")，以及如何调用预发布版本号（ x.y.z-development.n
- )。例如，如果 alpha或分支将同时部署到 alpha-nocapgo channel，但版本号中有不同的预发布名称 alpha开发者分支的
- 或 dev-rupert将同时部署到 dev-paul channel，所有版本号中都有相同的 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 :生成更改日志文件 CHANGELOG.md
@semantic-release/git : 将以下由 Ionic 构建和语义发布更新的文件提交（package.json, CHANGELOG.md 和 ios/App/App.xcodeproj/project.pbxproj - 我还没有为 Android 构建过)
@semantic-release/github : 将 CHANGELOG.md 文件附加到 Github 发布作为资产
@semantic-release/exec: 使用以下 2 个命令来准备应用程序的构建（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.

您会注意到，不需要解释如何计算和递增版本号、生成更改日志、__CAPGO_KEEP_0__ 标签或发布等：语义发布会自动处理所有这些，配置非常简单。

使用 XCode Cloud 构建新二进制文件

将所有这些与 XCode Cloud 集成，使用 XCode Cloud 构建应用程序的新版本非常简单（我还没有在 Google Play 上发布，但该构建应该类似）： production)
我设置了一个 XCode Cloud 过程，仅在我希望使用的分支上有变化时构建（例如， CHANGELOG.md 文件已更新。这是在每个版本由语义发布生成后更新的。
我可以在不同分支上触发构建，以模拟不同渠道的部署。在每个XCode Cloud构建的配置中，我手动设置一个环境变量，其值为 branch.channel 设置在 releaserc.json (是的，这是一个手动重复)然后，如果我想的话，我可以为每个自定义客户端应用程序从自定义发布分支部署不同的AppStore应用程序，正如之前提到的。

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

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

7. 结论

总之，我非常高兴能够在14天试用期内快速地将Capgo CapacitorUpdater集成到我的标准语义发布管道中，结果如下：

语义发布自动为Capgo服务器生成的bundle版本号
语义发布自动部署Capgo应用程序包，并且使用Capgo渠道
这与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.

我希望在语义发布配置中添加更好的预构建验证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独自创业者

您可以在LinkedIn上找到我 https://linkedin.com/in/rbarrow 您可以浏览我们的Salesforce产品

https://www.rapido-companion.app 我将在开发阶段完成这个应用。然后我将快速将它提供给测试者通过TestFlight (iOS)。考虑到__CAPGO_KEEP_0__的力量，我将在AppStore上部署一个免费的应用版本进行测试，并且将在测试期间定期更新__CAPGO_KEEP_1__。然后我将在AppStore上部署另一个（付费）应用版本，并且将定期更新__CAPGO_KEEP_2__。.

我希望在语义发布配置中添加更好的预构建验证__CAPGO_KEEP_0__ 我现在有一个清洁、简单、可复制的语义发布管道，用于将来使用Ionic + Angular + __CAPGO_KEEP_0__开发的移动应用和 https://www.rapido.cloud (正在开发中).

从Rapido Cloud如何管理Semantic Release中继续使用Capgo CapacitorUpdater

如果您正在使用 Rapido Cloud如何管理Semantic Release中继续使用Capgo CapacitorUpdater 计划实时更新交付,连接它到 Capgo Live Updates 在Capgo Live Updates中,为产品工作流程概述在概述中,为实现细节功能关于Features的实现细节更新行为关于更新行为的实现细节，以及更新类型关于更新类型的实现细节。

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