Rapido Cloudが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 CapacitorUpdaterは、標準的なApple AppStore/Google PlayStoreの配信プロセスを通過することなく、モバイルアプリのデプロイをより簡単、迅速、柔軟に行うことができるという約束に惹かれました。これは、私が過去にウェブアプリに集中していたため、初めてモバイルアプリをストアに送信することになりました。

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パイプラインに自動化し、統合する必要があります。

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

すべてのアプリケーション、モバイル、Web、Salesforceに関係なく

開発は feature/... ブランチ mainから行われ main そして
は にマージされ は productionリリースブランチalpha, beta, nightlyからトリガーされ
CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法 プルリクエストのマージ時にデプロイメントがトリガーされる

タグトリガーによるデプロイメントは使用していない。セマンティックリリースはタグとその他すべてのものを管理するからだ。

基本的にはGitLabフローである。

GitLabフロー GitLabフロー - ソース

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

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

修正はパッチバージョンを生成し、機能はマイナーバージョンを生成する。プリアリリースも自動的に含まれる。セマンティックリリースは、コミットから変更ログを生成し、修正と機能を定義されたコミットの規則 (https://www.conventionalcommits.org/en/about) に従ってグループ化し、セマンティックリリースで構成される。https://www.conventionalcommits.org/en/about

Capgoにより、CapacitorUpdaterはGit (Githubの場合、私の場合は)にマージされたpull requestと関連するissueを更新し、タグとリリースにリンクするコメントを付与します。最後に、このGithubリリースでは、ソースコード(code)、バイナリファイルなど必要に応じてアセットを付与します。 CHANGELOG.md, など。

4. semantic releaseとCapgoで使用されるブランチ、リリース/プレリリース、チャンネル

Capgoにより、Capgoのデプロイメントのためにsemantic releaseが実行することを望むことは以下のようになります。

__CAPGO_KEEP_0__のバージョン番号を生成するようにsemantic releaseに指示します。

Capgoは、Conventional Commitsの「標準バージョン」を開発し、ドキュメント化しました。 standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (githubは、__CAPGO_KEEP_1__-standard-versionを開発し、ドキュメント化しました。https://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version capacitor-standard-version (また、github.com/Cap-go/capacitor-plugin-standard-versionもあります。https://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-plugin-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 も当然です。)

これはとても素晴らしいことであり、自分が __CAPGO_KEEP_1__ を広く使用しているため、自分にとっては大きなリリーフとなります。 semantic-release また、セマンティックリリースが、異なるチャンネルでアプリのデプロイを生成したいこともあります。

上記で述べたように、ブランチなどからプレリリースバージョンをデプロイしたいですが、また、ブランチなどからカスタマー固有のバージョンをデプロイしたいこともあります。

etc. alpha, beta, nightly etc. production-customer-jones, production-customer-doeetc.

Capgoは「チャンネル」機能を提供しており、これはセマンティックリリースもサポートしているので、共に機能させることができてうれしいです。これらは、XCode Cloudによって管理される異なるブランチビルドと組み合わせることができます。

セマンティックリリースによって生成されるprereleasesのセマンティックバージョン番号は 1.0.0-alpha.1次のビルドはこのブランチ上で行われるため、ビルド番号は 1.0.0-alpha.2、などになります。明示的にドキュメント化されていませんが、これらのバージョン番号はCapgoによってサポートされており、これは私にとって素晴らしいニュースです: 私はセマンティックリリースのチャンネルとprereleaseを使用して、CapgoチャンネルでアプリケーションのバージョンをCapgoで生成することができます。

5. Capgoを使用してアプリケーションをリリースするにはどうすればよいですか?

To automate deployment of your app bundles to Capgo, you need to use the Capgo CLI command bundle uploadを実行して、多数のアップロードオプションを取得します。ここでは、以下のオプションを使用します。 npx @capgo/cli@latest bundle upload --help CHANNELは__CAPGO_KEEP_0__に展開したいチャンネル名です(例えば

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)
__CAPGO_KEEP_0___APIKEYは__CAPGO_KEEP_1__によって提供されるCI/CDパイプラインログインのユニークIDです。 1.0.0-alpha.1)
CAPGO_APPIDはCapgoによって提供されるアプリケーションのユニークIDです(例えば
CAPGO_APPID is provided by Capgo to uniquely identify your application (eg com.mystartup.mysuperapp)

6. マイセマンティックリリース + Capgo CapacitorUpdate 設定

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

セマンティックリリースと Github Actions を使用して作成されたアプリバンドルバージョン

セマンティックリリースと Github Actions を使用して作成されたアプリバンドルバージョン

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

セマンティックリリースの美しさは、デプロイメントの自動化、つまり Github アクションワークフローとしての形が非常に単純です。これは他の 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
- デプロイメントは alpha、 alpha-nocapgo ブランチは両方とも alphaチャンネルにアプリをデプロイしますが、バージョン番号のプレリリース名が異なります。
- デプロイメントは dev-rupert開発ブランチにアプリをデプロイします。 dev-paul 両方とも、__CAPGO_KEEP_0__チャンネルにデプロイされます。 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 https://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-formathttps://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
@semantic-release/release-notes-generator : 以下のファイルを更新したアプリケーションとセマンティックリリースの作業によって変更されたファイルをコミットします。 CHANGELOG.md
@semantic-release/git 、package.json, CHANGELOG.md Android向けのビルドは行っていません。 ios/App/App.xcodeproj/project.pbxproj : リリースに__CAPGO_KEEP_0__ファイルをアセットとして付与します。
@semantic-release/github __CAPGO_KEEP_1__ CHANGELOG.md file to the Github release as an asset
@semantic-release/exec: __CAPGO_KEEP_0__ のビルド用の 2 つのコマンドを使用して、アプリのビルドを準備します (prepareCmd) そして、 Capgo サーバーにアプリバンドルを有効にビルドして展開します (publishCmd)

semantic release がデフォルトで、最小限の設定で、バージョン番号の計算と増分、変更ログの生成、 Github タグまたはリリースの生成など、すべての設定を管理する必要がなくなりました :

XCode Cloud で新しいバイナリをビルドする

XCode Cloud と統合することで、XCode Cloud でアプリケーションバイナリの新しいバージョンを簡単にビルドできます (Google Play にデプロイすることはまだしていませんが、そのビルドは似たものです) :

XCode Cloud プロセスを設定して、指定したブランチで変更が発生したときにビルドするようにしました (例えば production)
このブランチでは、XCode Cloud にビルドを実行するように設定しましたが、ファイルが更新されたときにのみ実行するようにしました。このファイルは、semantic release によって生成される各バージョン後に更新されます。 CHANGELOG.md 異なるチャンネルで展開するために、異なるブランチでビルドをトリガーできます。各 XCode Cloud のビルド設定で、異なるブランチで、 __CAPGO_KEEP_0__ の値を環境変数に設定します (はい、これは手動の複製です)。そして、カスタムクライアントアプリケーション用にカスタムリリースブランチから展開するために、異なる AppStore アプリケーションを展開することもできます。
XCode Cloud で __CAPGO_KEEP_0__ チャンネルでアプリバイナリをビルドする branch.channel protectedTokens releaserc.json pagePath

Building app binaries on XCode Cloud with Capgo channels

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

7. 結論

結論として、14日間の試用期間内に標準的なシーケンスリリースパイプラインにCapgo CapacitorUpdaterを統合できて、非常に嬉しいです。結果は以下のようになっています。

シーケンスリリースによって自動的に生成されるバンドルバージョン番号は、Capgoサーバーと互換性があります。
semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
次のステップ

現在、このアプリの開発中です。テスト用にテストフライトを使用して、iOS用にアプリを迅速に提供する予定です。__CAPGO_KEEP_0の力に感銘を受け、テスト用に無料版のアプリをAppStoreにデプロイし、CAPGO_KEEP_1で定期的に更新する予定です。その後、AppStoreに別の有料版のアプリをデプロイし、CAPGO_KEEP_2__で定期的に更新する予定です。

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.

今後、Ionic + Angular + Capgoで開発されるモバイルアプリ用に、シーケンスリリースパイプラインを簡潔かつ再現性の高いものにしました。 bundle upload 著者 - Rupert Barrow

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

bundle version numbers are generated automatically by semantic release and compatible with the __CAPGO_KEEP_0__ servers

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 product offering.

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 and https://www.rapido.cloud (under development).

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 to plan live update delivery, connect it with Capgo Live Updates for the product workflow in Capgo Live Updates, Overview for the implementation detail in Overview Features for the implementation detail in Features Update Behavior for the implementation detail in Update Behavior, and Update Types for the implementation detail in Update Types

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