ラピドクラウドがCapgo CapacitorUpdaterを使用してセマンティックリリースを管理する方法

1. はじめに

Rapido Cloud (www.rapido.cloud), I am developing a mobile application for Salesforce clients to easily deploy their own branded mobile application without having to go through the difficult loops of using the Salesforce Mobile SDK or the Salesforce Mobile Publisher.

I have developed this mobile app on a modern and “standard” platform with widespread components and tools including Ionic 8, Angular 18, TypeScript, Capacitor and now Capgo CapacitorUpdater. These are more simple to handle for clients who do not want to manage Salesforce platform specifics such as Lightning Web Components; and its easier and cheaper for me to recruit developers and maintainers of Ionic + Angular mobile applications.

This article explains my design, my choices and implementation which make Capgo and semantic-release a very successful no-brainer for managing all deployments automatically via Github Actions. All this was designed, tested and documented during the nice 14-day free trial period of Capgo CapacitorUpdater.

2. Why use Capgo ? Why use semantic-release ?

Capgo

Iはこの成功を実現するための学習曲線に少し怖かったが、Apple TestFlightにアプリを簡単にアップロードできた。 Capgo CapacitorUpdaterを使用して、更新をより速くデプロイすることができた。

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 !

Capgo CapacitorUpdaterは、保存した新機能または修正を1分以内にソースcodeに保存した後、実際のモバイルでアプリケーションを更新するのに役立った。これは、非常にリラックスでき、柔軟で、設定が簡単なものだった。

3. 分岐とリリースモデル、そしてセマンティックリリースの位置づけ

Capgoサーバーへの配信が正常に動作するようになったので、CI/CDパイプラインに自動化して統合する必要がある。

分岐とリリースモデルをどのように組織するか

すべてのアプリケーション、モバイル、Web、Salesforceを問わず、

開発は ブランチから feature/... 、そしてマージされる mainは、ほとんどの開発ブランチの基準となる。ただし、メンテナンスやカスタムデリバリ用の特定の機能の場合、異なるブランチを使用する。 main 開発ブランチは、__CAPGO_KEEP_0__サーバーにデプロイされる。これは、CI/CDパイプラインに統合する必要がある。
CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法 リリースブランチから リリースブランチ、プレリリースブランチ、など productionまた、カスタマー固有のブランチやコンテキスト固有のブランチもあります。alpha, beta, nightlyプルリクエストがデプロイブランチにマージされることでデプロイメントがトリガーされます。
私はタグトリガーによるデプロイメントを使用していません。セマンティックリリースはタグを管理し、他のすべてのものを管理してくれます。 基本的にはGitLabフローです。

GitLabフロー

GitLabフロー - ソース

https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 セマンティックリリースの動作についての補足

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

In __CAPGO_KEEP_0__ のデプロイブランチで、セマンティックリリースがトリガーされたとき、セマンティックリリースはこのブランチで自動的に新しいバージョン番号を計算します。このブランチの前のタグのバージョン番号と、提供された修正または機能に基づいて。 alpha, beta, などが含まれるバージョン番号。

セマンティックリリースは、コミットから changelog を生成し、修正と機能を定義されたコミットの規則 (https://www.conventionalcommits.org/en/about) に従ってグループ化し、セマンティックリリースで構成されます。セマンティックリリースは、タグとリリースに関連付けられたコメントを付与することで、すべての __CAPGO_KEEP_0__ のマージされた pull request と関連する issue を更新します。最後に、この __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したがって、 __CAPGO_KEEP_0__ のデプロイメントでセマンティックリリースが実行されるようにしたいことは、以下のようになります。

セマンティックリリースが Capgo のバージョン番号を生成するようにしたい。

Capgo は、Conventional Commits の “Conventional Commits” のバージョンを開発し、ドキュメント化しました。

__CAPGO_KEEP_0__ のフォークされたリポジトリ

Capgo have developed and documented their own version of the “Conventional Commits” standard-version https://www.conventionalcommits.org/en/about 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バンドルは、"標準"のsemver "Semantic Versioning" (https://semver.org)を採用している。 semantic-release も同様に採用している。

So、それはすばらしいことであり、自分が使用しているため、私にとっては大きなリリーフとなる。 semantic-release 広く使用されています。

また、セマンティックリリースが異なるチャンネルでアプリのデプロイを生成したいと思っています。

上記のように述べたように、プレビュー版のバージョンをブランチなどからデプロイする必要があります。 alpha, beta, nightly など、顧客固有のバージョンをブランチなどからデプロイする必要があります。 production-customer-jones, production-customer-doe、など。

Capgoは「チャンネル」機能を提供しており、これはセマンティックリリースもサポートしているので、共に機能させることができて嬉しいです。これは、XCode Cloudが管理する異なるブランチのビルドと一致しています (詳細は下記を参照してください)。

セマンティックリリースが生成したセマンティックバージョン番号は、プレビュー版の場合、以下のようになります。 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 CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法

npx @capgo/cli bundle upload --channel $CHANNEL --apikey $CAPGO_APIKEY --bundle $VERSION --bundle-url $CAPGO_APPID

CHANNEL is the Capgo channel to which we want to deploy (eg alpha)
CHANNELは、Capgoで使用する__CAPGO_KEEP_0__チャンネルです。 1.0.0-alpha.1)
CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
CAPGO_APIKEYは、Capgoから提供されるAPIキーです。 com.mystartup.mysuperapp)

Capgo_APPIDは、__CAPGO_KEEP_1__から提供されるアプリケーションIDです。

6. セマンティックリリースとCapacitorUpdateのセットアップ

App bundle versions built with semantic release and Github Actions

App bundle versions built with semantic release and Github Actions

Semantic release automation with Github Actions

The beauty of semantic release is that the deployment automation, in the form of a Github Action workflow, is very simple. This will look very similar on other CI/CD platforms .

# ./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 }}

セマンティックリリースの美しさは、CapgoのActionワークフローとしてのデプロイ自動化が非常に簡単です。これは他のCI/CDプラットフォームでも同様です。

For every branch on a 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 behavior 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 channel ( x.y.z-development.n
- ) and how the prerelease version number will be called ( alphaと alpha-nocapgo ブランチは両方とも __CAPGO_KEEP_0__ へのアプリのデプロイを行いますが、バージョン番号のプレリリース名が異なります。 alpha開発ブランチへのデプロイでは
- もしくは dev-rupert両方とも __CAPGO_KEEP_0__ にデプロイされますが、バージョン番号のプレリリース名が異なります。 dev-paul 開発ブランチへのデプロイでは developmentchannel on Capgo, all with the same development両方とも __CAPGO_KEEP_0__ にデプロイされますが、バージョン番号のプレリリース名が異なります。
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 もしくは両方とも github にデプロイされますが、バージョン番号のプレリリース名が異なります。)
@semantic-release/release-notes-generator 最初のセマンティックリリースの段階では、__CAPGO_KEEP_0__ に対する正しいアクセス権を持っていることを確認します。 __CAPGO_KEEP_1__ __CAPGO_KEEP_2__ への認証チェックを追加することを望んでいます。 CHANGELOG.md
@semantic-release/git : __CAPGO_KEEP_0__ にアップデートされたファイルを含むアプリケーションの Ionic ビルドとセマンティックリリースのファイルをコミットする (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)
on this branch, I set XCode Cloud to build only when the CHANGELOG.md ファイルは更新されます。このファイルは、セマンティックリリースによって生成される各バージョンごとに更新されます。
私は、異なるブランチでビルドをトリガーして、異なるチャンネルでデプロイをシミュレートすることができます。XCode Cloudの各構成で異なるブランチでビルドする場合、環境変数を手動で設定し、値を設定します。 branch.channel 設定します。 releaserc.json (はい、これは手動の複製です)。そして、必要に応じて、カスタムリリースブランチからカスタムクライアントアプリケーションをデプロイするために、異なるAppStoreアプリケーションをデプロイすることもできます。

Building app binaries on XCode Cloud with Capgo channels

Building app binaries on XCode Cloud with Capgo channels

7. 結論

In conclusion, I am very happy to have been able to integrate Capgo CapacitorUpdater into my standard semantic release pipeline, rapidly within the delay of the 14-day trial period, and the result is the following :

bundle version numbers are generated automatically by semantic release and compatible with the Capgo servers
semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
これは、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.

I hope to add better pre-build verification of Capgo bundle upload prerequisites into my semantic release configuration.

I now have a clean, simple and reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.

Author - Rupert Barrow

22年以上のSalesforce経験があります。クライアントやユーザー、パートナー、統合者、設計者、開発者、ビジネスアナリスト、コンサルタントとして、Salesforceを使用してきました。13年間、フランスの成功したSalesforce SIパートナーであるAltius ServicesのCOOおよびCTOを務め、Salesforce solopreneurとしての新たな冒険を始めました。 Rapido Cloud LinkedInで私を見つけてください。

https://linkedin.com/in/rbarrow Salesforceの提供物をご覧ください。.

https://www.rapido-companion.app https://www.rapido-companion.app と https://www.rapido.cloud (開発中)

Keep going from How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

If you are using How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater Capgo CapacitorUpdaterを使用して Capgo Live Updates for the product workflow in Capgo Live Updates, Capgo Live Updatesの製品ワークフロー概要 Capgo Live Updatesの実装詳細については概要を参照してください。 CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法アップデートの動作アップデートの動作の実装詳細についてはアップデートの種類本稿のクレジット

Rapido CloudがCapgo CapacitorUpdaterを使用してセマンティックリリースを管理する方法