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 といった、広く普及したコンポーネントとツールを備えたモダンで「標準的」なプラットフォームで開発しました。Lightning Web Components のような Salesforce 特有の事情を管理したくないクライアントにとって扱いやすく、私にとっても Ionic + Angular モバイルアプリの開発者やメンテナーを採用して維持するのが簡単でコストも安く済みます。

この記事では、Capgo と semantic-release を、Github Actions ですべてのデプロイを自動管理できる、非常にうまくいった「迷わず選べる」組み合わせにした、私の設計・選択・実装について説明します。これらはすべて、Capgo CapacitorUpdater の14日間の無料トライアル期間中に設計・テスト・ドキュメント化しました。

2. なぜ Capgo を使うのか？なぜ semantic-release を使うのか？

Capgo CapacitorUpdater に惹かれたのは、モバイルアプリのデプロイを、標準的な Apple AppStore / Google PlayStore の配信プロセスを経るよりも、はるかにシンプルかつ迅速で柔軟にできるという約束でした。これまでは主に Salesforce Experience Cloud 上で開発する Web アプリに注力してきたので、ストアに公開するモバイルアプリはこれが初めてです。

成功させるための学習の壁をやや不安に感じていましたが、アプリを Apple TestFlight に載せるのは割と簡単にできました。その後は Capgo CapacitorUpdater を使って、アップデートをはるかに速くデプロイできるようになりました。

最初の要件とテストケースは、Ionic が推奨する Nexus モバイルブラウザ経由のシミュレーターやモバイルエミュレーターでテストするのではなく、自分のスマートフォン上で本物のモバイルアプリとしてデプロイして自分でテストすることでした。というのも、私のアプリは Geolocation やフォトギャラリー、カメラへのアクセスといったネイティブ機能を使っているからです。Capacitor のモバイルアプリをテストした経験がなかったので、すべてが正しく動作するか不安でした。実際のアプリを、実際の条件でテストするのが一番です！

そこで Capgo CapacitorUpdater が、ソース code に新機能や修正を保存してからわずか1分後に、モバイル上のアプリをライブでアップデートするのを助けてくれました。本当に安心でき、柔軟で、セットアップも簡単でした！

3. ブランチとリリースモデル、semantic-release の組み込み方

Capgo サーバーへのデリバリーが正常に動作するようになったので、次はこれを自動化し、CI/CD パイプラインに組み込む必要があります。

私が採用しているブランチとリリースモデルは次のとおりです

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

開発は以下で行われます feature/... から分岐し main、それらは以下にマージされます main これは、メンテナンスやカスタムデリバリー向けの特定機能を除き、ほとんどの開発ブランチの基準となるブランチです（詳細は後述）
デプロイがトリガーされます リリースブランチから 以下のようなものがあります： production、プレリリースブランチ（alpha, beta, nightlyなど）、およびカスタムデリバリー用の顧客別またはコンテキスト別ブランチ
pull request によってデプロイがトリガーされます デプロイブランチにマージされたときです。タグトリガーのデプロイは使っていません。タグもその他すべて semantic-release が管理してくれるからです。

基本的に、これは Gitlab Flow です：

GitLab Flow

Gitlab Flow - 出典 https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

semantic-release の仕組みについての補足：

デプロイブランチで semantic-release がトリガーされると、そのブランチの前回のタグのバージョンと、取り込まれた fix や feature に基づいて新しいバージョン番号が自動計算されます。fix はパッチバージョン、feature はマイナーバージョンを新たに作成します。プレリリースも自動的に含まれます alpha, beta、などがバージョン番号に含まれます。

Semantic releaseはcommitからchangelogを生成し、conventional commitsで定義されたとおりにfixとfeatureをグループ化します（参照： https://www.conventionalcommits.org/en/about）、semantic releaseで設定します。

また、gitのすべてのマージ済みプルリクエスト（私の場合は Github）や関連するissueに対し、タグやリリースへのリンクを含むコメントを自動で追加します。最後に、この Github リリースにおいて、ソース code や、必要に応じてバイナリなどのアセットを添付します。 CHANGELOG.md、など。

4. semantic releaseと Capgo におけるブランチ、リリース/プリリリース、チャンネル

そこで、Capgo のデプロイにおいて、semantic releaseに実現させたいことは以下の通りです。

semantic releaseにバージョン番号を生成させたいと考えています。

Capgo は独自の「Conventional Commits」 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 バンドルは、「standard」な semver「Semantic Versioning」に従います (https://semver.org )、これは semantic-release 当然ながら、それにも従っています（！）

それは素晴らしいことで、私にとっては安心です。なぜなら、私はこれを semantic-release 多用しているからです。

また、semantic release で異なるチャンネルへのアプリデプロイを生成したいとも考えています。

前述のとおり、次のようなブランチからプリリリース版をデプロイする必要があります alpha, beta, nightly さらに、次のようなブランチから顧客固有のバージョンもデプロイします production-customer-jones, production-customer-doe、など。

Capgo には semantic release がサポートしているものと全く同じ「channels」機能があるため、これらを連携させるのが楽しみです。これらは XCode Cloud で管理される異なるブランチビルドとも相性が良いです（詳細は後述）。

semantic release がプリリリース時に生成する Semver バージョン番号は次のようになります 1.0.0-alpha.1このブランチでビルドを重ねると、ビルド番号は次の値にインクリメントされます 1.0.0-alpha.2など。明示的にドキュメント化されていませんが、これらのバージョン番号は Capgo でサポートされています。これは私にとって朗報です。semantic release の channels と prerelease を使って、Capgo のチャンネルでアプリのバージョンを生成します。

5. Capgo を使ってアプリをリリースするには？

アプリの bundle を Capgo へ自動デプロイするには、Capgo CLI コマンドを使います bundle upload次を入力します npx @capgo/cli@latest bundle upload --help これで多数の upload オプションが表示されます。その中から、以下を使います：

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 パイプラインのログインを一意に識別するために使われます
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 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 環境をインストールし、semantic release を呼び出すだけです。

リストに指定されたブランチへのすべてのマージについて branches、semantic release がデプロイをトリガーします。設定 CAPGO_APIKEY リポジトリの secrets に。更新する CAPGO_APPID こちら

semantic release の動作は、その .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 はどちらもデプロイ先が developmentCapgo のチャンネルで、いずれも developmentバージョン番号に同じ prerelease キーワードが含まれます
verifyConditions ：semantic release の最初のステージで、Github への正しいアクセス権があるか確認します。後でここに Capgo CLI の認証チェックも追加する予定です
@semantic-release/commit-analyzer ：標準的な semantic release の処理です - ドキュメントを参照してください（https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
@semantic-release/release-notes-generator ：changelog ファイルを次のように生成します CHANGELOG.md
@semantic-release/git ：アプリの Ionic ビルドと semantic release の処理で更新された以下のファイルをコミットします（package.json, CHANGELOG.md と ios/App/App.xcodeproj/project.pbxproj - Android 向けはまだビルドしていません）
@semantic-release/github ：そのファイルを CHANGELOG.md Github リリースのアセットとして添付します
@semantic-release/exec：これら2つのコマンドでアプリのビルドを準備します（prepareCmd）その後、アプリのバンドルを Capgo サーバーに実際にビルドしてデプロイします（publishCmd)

バージョン番号の計算やインクリメント方法、変更履歴の生成、Github タグやリリースの作成など、設定をいじる必要がないことに気づくでしょう。semantic release がデフォルトですべてを処理するため、最小限の設定で済みます。

XCode Cloud を使用した新しいバイナリのビルド

Xcode Cloud でアプリケーションバイナリの新しいバージョンをビルドするこの統合は簡単です（まだ Google Play にはデプロイしていませんが、そのビルドも同様のものになるはずです）：

この用途に使用するブランチ（例： production)
このブランチでは、 CHANGELOG.md ファイルが更新された場合のみ Xcode Cloud でビルドするように設定しています。semantic release によって各バージョンが生成された後に、このファイルは更新されます。
異なるブランチでビルドをトリガーして、チャンネルごとのデプロイをシミュレートできます。ブランチごとのXCode Cloudビルドの各設定で、環境変数に次の値を手動で設定しています： branch.channel に設定された releaserc.json (はい、これは手動での重複作業です) そして必要であれば、前述したように、カスタムリリースブランチからデプロイする顧客ごとのカスタムアプリに対して、それぞれ別のAppStoreアプリケーションをデプロイできます。

XCode CloudでCapgoチャンネルのアプリバイナリをビルドする

XCode CloudでCapgoチャンネルのアプリバイナリをビルドする

7. まとめ

結論として、Capgo CapacitorUpdaterを標準のsemantic releaseパイプラインに、14日間のトライアル期間内という短い間に統合できたことをとても嬉しく思っています。結果は以下の通りです：

bundleのバージョン番号はsemantic releaseによって自動生成され、Capgoのサーバーと互換性がある
semantic releaseがCapgoのアプリケーションbundleを自動デプロイし、Capgoチャンネルも活用する
アプリケーションバイナリのXCode Cloudビルドとスムーズに連携できる

次のステップ

現在、このアプリは開発フェーズにあります。近いうちにTestFlight（iOS用）を通じてテスターに公開する予定です。Capgoの強力な機能を考慮すると、テスト用にアプリの無料版をAppStoreにデプロイし、テスト期間中はCapgoで定期的にアップデートするつもりです。その後、別のレコードとしてアプリの有料版をAppStoreにデプロイし、こちらもCapgoで定期的にアップデートしていきます。

ビルド前のCapgoの検証をより強化できるようにしたいと考えています。 bundle upload semantic releaseの設定にprerequisitesを追加します。

これにより、Ionic + Angular + Capacitorで開発する将来のモバイルアプリ向けに、クリーンでシンプルかつ再現性のあるsemantic release pipelineが整いました。

著者 - Rupert Barrow

Salesforce をクライアントやユーザーとして、またパートナーやインテグレーター、アーキテクト、開発者、ビジネスアナリスト、コンサルタントとして22年以上の経験があります。フランスで成功を収めたSalesforce SIパートナーであるAltius Servicesを共同設立し、13年間COO兼CTOとして共同経営に携わった後、Salesforceソロプレナーとして新たな挑戦を始めました。私の Rapido Cloud プロダクトを携えて。

LinkedInはこちら： https://linkedin.com/in/rbarrow.

Salesforceの提供サービスはこちら： https://www.rapido-companion.app と https://www.rapido.cloud （開発中）。

続きを読む：Rapido CloudがCapgo CapacitorUpdaterでSemantic Releaseを管理する方法

使用している場合 Rapido Cloud が Capgo CapacitorUpdater で Semantic Release を管理する方法 live update の配信を計画するには、以下と連携させます： Capgo Live Update Capgo Live Updates のプロダクトワークフロー向けに、概要実装の詳細は Overview を機能実装の詳細は Features をアップデートの動作実装の詳細はアップデートの動作を、およびアップデートの種類実装の詳細はアップデートの種類を。