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

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

1. 简介在Rapido Cloud（www.rapido.cloud）中，我正在开发一个移动应用程序，用于Salesforce客户轻松部署自己的品牌移动应用程序，而无需通过Salesforce Mobile __CAPGO_KEEP_0__或Salesforce Mobile Publisher的困难循环。2. SDK CapacitorUpdater的设置

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

本文将解释我设计、选择和实现的方法，使得 Capgo 成为管理所有部署的自动化工具。 semantic-release 本文将解释我设计、选择和实现的方法，使得 Github 成为管理所有部署的自动化工具。所有这些都在 Capgo CapacitorUpdater 的免费试用期内设计、测试和文档化。

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.

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.

This is how I organize my branching and release model

For every application, whether mobile, web or Salesforce :

开发是在 feature/... 分支 main,并且它们被合并到 main 这是大多数开发 branch 的参考，除了维护和特定功能的定制交付（关于此事的更多信息请参见下文）
部署是触发的 从发布分支 可能是： production, 预发布分支（alpha, beta, nightly, 等）以及客户或上下文特定分支用于自定义交付
部署由 pull 请求触发 当 pull 请求被合并到部署分支时

我不使用标签触发的部署，因为 semantic release 为我管理标签和其他所有内容

基本上，这是 Gitlab 流程：

Gitlab 流程 Gitlab 流程 - 源

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

关于 semantic-release 的一则小贴士： alpha, beta等等在版本号中。

语义发布从您的提交生成更改日志，按照约定的提交（见“https://www.conventionalcommits.org/en/about”）并在语义发布中配置。它还将更新所有您的git（在我的情况下是__CAPGO_KEEP_0__）合并的pull请求和相关问题，通过评论将它们链接到标签和发布中。最后，在本__CAPGO_KEEP_1__发布中，它将附加资产，如源__CAPGO_KEEP_2__、二进制文件等。4. 语义发布和__CAPGO_KEEP_0__中的branch、release/prerelease、channel

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已经开发并文档化了他们自己的“约定提交”版本

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

https://__CAPGO_KEEP_0__.com/Cap-go/standard-version

Capgo standard-version __CAPGO_KEEP_1__ 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 也遵循（显然！)

因此，这很好，给我带来了很大的放心，因为我使用 semantic-release 它的功能非常广泛。

I also want semantic release to generate app deployments on different channels

如上所述，我需要从以下分支部署预发布版本 alpha, beta, nightly 例如， production-customer-jones, production-customer-doe例如，

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

语义发布在预发布版本上生成的Semver版本号类似于 1.0.0-alpha.1成功的构建在此分支上将会将构建号递增到 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 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"和 x.y.z-development.n
- context alphacontext alpha-nocapgo branches 将同时在 __CAPGO_KEEP_0__ 上发布应用 alphachannel 上的分支将发布应用，但版本号中有不同的预发布名称
- 将发布到开发者分支 dev-rupert或 dev-paul 将同时发布到 __CAPGO_KEEP_0__ 上，但版本号中有相同的预发布关键字 development: 在语义发布的第一阶段，它检查它是否有正确的访问权限到 Capgo。我希望在这里添加一个认证检查 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 : 将以下文件提交，文件由 Ionic 构建和语义发布工作更新 CHANGELOG.md
@semantic-release/git 将同时发布到 __CAPGO_KEEP_0__ 上，但版本号中有相同的预发布关键字package.json, CHANGELOG.md 和 ios/App/App.xcodeproj/project.pbxproj - 我并没有为 Android 构建)
@semantic-release/github : 将文件附加到 __CAPGO_KEEP_0__ 发布作为资产 CHANGELOG.md file to the Github release as an asset
@semantic-release/exec)并将应用程序包装部署到 __CAPGO_KEEP_0__ 服务器（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.

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

我设置了一个 XCode Cloud 过程，以便在我希望使用的分支上发生变化时构建（例如

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

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

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

7. 结论

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

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

下一步

我目前正在开发这个应用程序。很快，我将通过 TestFlight (用于 iOS)将其提供给测试者。考虑到 Capgo 的力量，我将肯定地部署一个免费的应用程序版本到 AppStore 进行测试，并且将其定期更新为 Capgo。然后，我将部署另一个 (付费) 应用程序版本到 AppStore，另一个记录，并且也将其定期更新为 Capgo。

I hope to add better pre-build verification of Capgo bundle upload I now have a clean, simple and reproducible semantic release pipeline for future mobile apps developed with 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 have over 22 years’ experience of Salesforce, as a client and user, as a partner and integrator, architect, developer, business analyst and consultant.

I co-founded and co-managed Altius Services as COO and CTO for 13 years, a successful Salesforce SI partner in France, before setting off on a new adventure as a Salesforce solopreneur with my Rapido Cloud You can find me on LinkedIn at

https://linkedin.com/in/rbarrow You can take a look at our Salesforce offerings at.

https://www.rapido-companion.app 和 Page/area: Capgo marketing website. Role: Short UI label or navigation item. Seen in: page trust.astro. Message key `and` (And). https://www.rapido.cloud (正在开发中).

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

如果您正在使用 如何Rapido Cloud管理Semantic Release with Capgo CapacitorUpdater 计划实时更新的交付,连接它到 Capgo Live Updates for the product workflow in Capgo Live Updates, 在__CAPGO_KEEP_0__ Live Updates中, 概览在概览中, 功能更新行为对于更新行为的实现细节，以及更新类型对于更新类型的实现细节。

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