Rapido Cloud如何使用Capgo CapacitorUpdater管理Semantic Release

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交付过程。

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.

我对学习曲线感到担忧，但我很容易就将应用推送到Apple TestFlight。然后，我就可以使用Capacitor CapacitorUpdater来快速部署我的更新。

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 !

__CAPGO_KEEP_0__ CapacitorUpdater帮助我在手机上更新应用，实时，保存新功能或修复后仅需1分钟：这太放心了，太灵活了，太容易设置了！

3. 我的分支和发布模型，以及semantic-release如何融入其中。现在我已经将应用部署到Capgo 服务器上工作正常了，我需要自动化这个过程并将其融入我的CI/CD管道中。

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

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

• 开发 在 feature/... 分支 main，并将它们合并到 main 这是大多数开发分支的参考，除了维护和特定功能的定制交付（关于此的更多信息，请参见下文）
• 部署 从发布分支 可能是： production预发布分支（alpha, beta, nightly等）以及客户定制或上下文定制的分支用于定制交付
• 部署由 pull 请求触发。它被合并到部署分支中。 我不使用标签触发的部署，因为 semantic release 管理标签和其他所有内容。

基本上，这是 Gitlab 流程 :

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

关于 semantic-release 的一则小贴士 :

在部署分支中，当 semantic-release 被触发时，它将自动计算新版本号，在此分支上，依赖于此分支上之前标签的版本号和修复或功能的交付。修复将创建一个新补丁版本，而功能将创建一个新次要版本。它还自动包含预发布 alpha, beta在版本号中。

Semantic release 根据您的提交生成 changelog，按照 conventional commits（见 https://www.conventionalcommits.org/en/about)和在 semantic release 中配置的方式，将修复和功能分组。

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_1__ 发布中，它将附加源 __CAPGO_KEEP_2__、二进制文件（如果需要）等。

4.语义发布中的分支、发布/预发布、通道以及在 Capgo 中

所以，我希望语义发布在 Capgo 部署中执行以下操作。

我希望语义发布生成版本号

Capgo 已经开发并文档化了他们自己的“规范提交” 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能够在不同渠道上生成应用程序部署 semantic-release 如上所述，我需要从分支如

等处部署预发布版本，但也需要从分支如

等处部署客户专属版本 alpha, beta, nightly production-customer-jones, production-customer-doe

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

语义发布在预发布版本中生成的 Semver 版本号看起来像 1.0.0-alpha.1此 branch 上的连续构建将将构建号增加到 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 是我们要部署的 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 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 环境，然后调用语义发布。

对于每个在 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 将两者都部署到 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 :提交以下文件，它们已被Ionic应用程序的构建和语义发布工作更新（package.json, CHANGELOG.md 和 ios/App/App.xcodeproj/project.pbxproj -我还没有为Android构建)
• @semantic-release/github :将 CHANGELOG.md 文件附加到Github发布作为一个资产
• @semantic-release/exec: 使用这两个命令来准备应用程序的构建 (prepareCmd) 然后将应用程序包有效地部署到 Capgo 服务器 (publishCmd)

您会注意到，我们不需要解释如何计算和递增版本号、如何生成更改日志、Github 标签或发布等内容：所有这些都由 semantic release 默认处理，配置极为简单。

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

将所有这些与 XCode Cloud 集成，构建应用程序二进制文件的新版本是简单的（我尚未在 Google Play 上部署，但该构建应该类似）：

• 我设置了一个 XCode Cloud 过程，用于在我希望使用的分支上构建（例如 production)
• 在这个分支上，我设置 XCode Cloud 只在 CHANGELOG.md 文件更新时构建。这是在每次由 semantic release 生成的版本之后更新的。
• 我可以在不同的分支上触发构建，以模拟针对不同渠道的部署。在每个 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.

使用 __CAPGO_KEEP_0__ 通道构建应用二进制文件的 XCode Cloud

我拥有超过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 （正在开发中）