Rapido CloudがCapgo CapacitorUpdaterを使用したSemantic Releaseの管理方法

1. はじめに

Rapido Cloud (www.rapido.cloud)で、Salesforceのクライアント向けに、Salesforce Mobile SDKや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. なぜ Capgo を使うのか？なぜ semantic-release を使うのか？

Capgo CapacitorUpdater が魅力的なのは、標準の Apple AppStore/Google PlayStore での配布プロセスよりも、モバイルアプリの配布が簡単、迅速、柔軟になることです。 これは、過去にWebアプリを中心に開発してきた私にとって初めてのモバイルアプリでした。

私は、モバイルアプリを成功させるには、学習曲線が高くて怖かったのですが、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 !

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.

3. 分岐とリリースモデル、そしてsemantic-releaseの位置づけ

CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。

• CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。 CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。 feature/... CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。 mainCapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。 main CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。
• CapacitorUpdaterは私が新しい機能や修正をソース__CAPGO_KEEP_1__に保存した1分後、実機で私のアプリケーションを更新してくれた。実際にアプリケーションを更新するのはとてもリラックスでき、柔軟で、設定も簡単だった。 リリースブランチから 例えば、 production、また、カスタマー固有のまたはコンテキスト固有のブランチもあります。カスタムデリバリ用alpha, beta, nightlyプルリクエストのマージ時にデプロイメントがトリガーされます。
• タグトリガーによるデプロイメントは使用していません。Semantic Releaseはタグとその他のすべてを管理するからです。 基本的には、GitLab Flowです。

GitLab Flow

https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 Semantic Releaseの動作についての補足

デプロイメントブランチで、Semantic Releaseがトリガーされた場合、自動的に新しいバージョン番号を計算します。このブランチの前のタグのバージョン番号と修正または機能の提供された修正に基づいて。修正はパッチバージョンを新しく作成し、機能はマイナーバージョンを新しく作成します。さらに、自動的にプレリリースを含めます。

__CAPGO_KEEP_0__ alpha, betaバージョン番号、など。

Semantic release は、コミットから changelog を生成し、修正と機能を定義されたコミットの規則 (https://www.conventionalcommits.org/en/about を参照) に従ってグループ化し、semantic release で構成されます。 また、Git (__CAPGO_KEEP_0__, 私の場合は) にマージされた pull request と関連する issue にコメントを付けて、タグとリリースにリンクすることも行います。最後に、この __CAPGO_KEEP_1__ リリースでは、ソース __CAPGO_KEEP_2__、バイナリなど必要な場合のアセットを付属させます。4. 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.mdsemantic release はバージョン番号を生成するようにしたい。

Capgo は、”Conventional Commits” の “標準版” を開発し、ドキュメント化しました。

Capgo.com/Cap-go/standard-version

https://

Capgo have developed and documented their own version of the “Conventional Commits” standard-version https:// 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「意味論的バージョニング」 (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は「チャンネル」機能を提供しており、これは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によってサポートされていることが明示されていませんが、これは私にとって素晴らしいニュースです: これらのバージョン番号を使用して、__CAPGO_KEEP_1__チャンネルとプレビュー機能を使用して、Capgoチャンネルで私のアプリのバージョンを生成することができます。

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 タイプを入力すると、多くのアップロードオプションが表示されます。 そのうち、以下を使用します。

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 から提供されるAPIキーで、CI/CD Pipelines のログインを一意に識別します
• CAPGO_APPID は、Capgo から提供されるアプリケーション ID で、アプリケーションを一意に識別します (例えば com.mystartup.mysuperapp)

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

最後に、これらはどのように組み合わさりますか ?

セマンティック リリースと Github Actions で構築されたアプリケーションバンドルのバージョン

Github Actions を使用したセマンティック リリースの自動化

セマンティック リリースの美しさは、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 環境をインストールし、セマンティック リリースを呼び出します。

__CAPGO_KEEP_0__ で指定されたブランチのリストにある各マージャーに対して 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), mapped to the Capgo channel (channel)、およびプレリリース バージョン番号の呼び出し方法 (prerelease) を設定します。たとえば、 branch.prerelease = "development"、生成されるバージョン番号は x.y.z-development.n
  • デプロイは alphaと alpha-nocapgo branchは両方ともアプリを__CAPGO_KEEP_0__チャンネルにデプロイしますが、バージョン番号のプレリリース名が異なります。 alphadeveloper branchのデプロイは両方とも__CAPGO_KEEP_0__チャンネルにデプロイされます。
  • または dev-rupert両方とも__CAPGO_KEEP_0__チャンネルにデプロイされます。 dev-paul 最初のセマンティック リリースの段階では、__CAPGO_KEEP_0__に正しいアクセス権を持っていることを確認します。 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 : セマンティック リリースの作業によって更新されたアプリケーションのIonicビルドとファイルを生成します。https://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator __CAPGO_KEEP_0__ CHANGELOG.md
• @semantic-release/git __CAPGO_KEEP_1__package.json, CHANGELOG.md そして、 ios/App/App.xcodeproj/project.pbxproj - Android向けのビルドはまだ行っていません)
• @semantic-release/github : __CAPGO_KEEP_0__ リリースにアセットとしてファイルを付与する CHANGELOG.md : アプリのビルド用にこれらの2つのコマンドを使用して準備し、Githubサーバーにアプリのバンドルをデプロイする
• @semantic-release/exec]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と統合することで、XCode Cloudで新しいアプリケーション バイナリのバージョンを作成することは簡単です (Google Playにデプロイすることはまだしていませんが、そのビルドは似たようなものです) :

XCode Cloudプロセスを設定して、特定のブランチで変更が発生したときにビルドするようにしました (例えば、

• このブランチでは、ファイルが更新されたときにのみXCode Cloudがビルドするように設定しました。このファイルは、セマンティック リリースによって生成される各バージョン後に更新されます。 production)
• on this branch, I set XCode Cloud to build only when the CHANGELOG.md file is updated. This is updated after each version generated by semantic release
• 異なるブランチでビルドをトリガーして、異なるチャンネルで展開するシミュレーションを実行できます。XCode Cloudの各構成で異なるブランチでビルドする場合、環境変数を手動で設定し、値を branch.channel set in releaserc.json (はい、これは手動の複製です) として、次に、必要に応じて、カスタムクライアントアプリケーションをカスタムリリースブランチから展開するために、各カスタムアプリケーション用に異なるAppStoreアプリケーションを展開することができます。

XCode CloudでアプリケーションビニヤーをCapgoチャンネルでビルドする

7. 結論

結論として、14日間の試用期間内に標準的なシーマティックリリースパイプラインにCapgo CapacitorUpdaterを迅速に統合できて、結果は以下のようになりました。

• シーマティックリリースによって自動的に生成されるバンドルバージョン番号は、Capgoサーバーと互換性があります。
• シーマティックリリースは、Capgoチャンネルを使用して、自動的にCapgoアプリケーションバンドルを展開します。また、XCode Cloudでアプリケーションビニヤーをビルドすることもできます。
• これは、XCode Cloudでアプリケーションビニヤーをビルドすることとよく合致しています。

次のステップ

このアプリの開発段階にあります。テスト用にTestFlight (iOS) からすぐに利用可能にします。Capgoの力に感銘を受け、テスト用に無料版のアプリをAppStoreに展開し、Capgoで定期的に更新する予定です。次に、AppStoreに別の(有料)アプリを展開し、Capgoで定期的に更新する予定です。

Capgo のより良い前ビルド検証を追加することを願っています。 bundle upload 私のシーマティックリリース構成に必要な前提条件を追加することを願っています。

Ionic + Angular + Capacitor で開発された将来のモバイルアプリ用に、クリーンでシンプルで再現可能なシーマティックリリースパイプラインを持っています。

著者 - ルパート・バロー

私は、Salesforce のクライアントとユーザー、パートナーと統合者、設計者、開発者、ビジネス分析家、コンサルタントとして、22 年以上の経験を持っています。私は、フランスで成功した Salesforce SI パートナーである Altius Services の COO と CTO を 13 年間共同設立および共同運営し、Salesforce solopreneur としての新しい冒険を始める前に、Rapido Cloud の製品オファリングを開始しました。 LinkedIn で私を見つけることができます。 https://linkedin.com/in/rbarrow

私たちの Salesforce オファリングをご覧になることができます。 https://www.rapido-companion.app.

そして https://www.rapido-companion.app and https://www.rapido.cloud (開発中)

Rapido Cloudから始めて、Capgo CapacitorUpdaterを使用してセマンティック リリースを管理する

ライブアップデートの計画と配信を管理する場合に使用しています Rapido Cloudから始めて、Capgo Live Updatesを使用してセマンティック リリースを管理する __CAPGO_KEEP_0__ Live Updatesの製品ワークフロー Capgo Live Updates Capgo Live Updatesの実装詳細 詳細 __CAPGO_KEEP_0__ Featuresの実装詳細 概要 機能 動作の更新 動作の更新の実装詳細について、 更新の種類 更新の種類の実装詳細について、