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を使用しました。これらは、SalesforceプラットフォームのLightning Web Componentsなどの特定の管理を避けたいクライアントにとって扱いやすく、またIonic + Angularモバイルアプリの開発者やメンテナを募集しやすく、維持も安くて簡単なので、私にとっては便利です。

この記事では、Capgoの設計、選択、実装について説明し、 semantic-release Github Actionsを使用して、すべてのデプロイを自動的に管理することができる非常に成功し、頭の痛みが少ない方法です。すべてのデプロイは、Capgo CapacitorUpdaterの14日間の無料試用期間中に設計、テスト、ドキュメント化されました。

2. なぜCapgoを使用するのか？なぜsemantic-releaseを使用するのか？

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

私がこのアプリを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. My branching and release model, and how semantic-release fits in

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の役割

So now I have my delivery to __CAPGO_KEEP_0__ servers working correctly, I need to automate this and fit it into my CI/CD pipeline.

• CapacitorUpdaterは私がモバイル上で、保存した新機能や修正を1分以内に更新するのに役立ちました。 This is how I organize my branching and release model feature/... CapacitorUpdaterは私がモバイル上で、保存した新機能や修正を1分以内に更新するのに役立ちました。 mainFor every application, whether mobile, web or Salesforce : main 開発は
• は分岐し、そしてそれらはマージされる、そしてそれは開発のほとんどの分岐のための基準となる、メンテナンスやカスタムデリバリー用の特定の機能の外側にあります (詳細は下記)。 リリースブランチから 例えば、 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がトリガーされたとき、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 (forked repo) を参照

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

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 つまり、

これは素晴らしいことであり、自分自身にとっては大きなリリーフとなります。なぜなら、私は 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が管理する異なるブランチのビルドと一致しています。

セマンティックリリースが生成するプレビュー版のバージョン番号は 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__チャンネルで私のアプリのバージョンを生成することになります。

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はsemantic releaseによって生成されます(例えば 1.0.0-alpha.1)
• CAPGO_APIKEYはCapgoから提供されるCI/CDパイプラインログインを一意に識別するために使用されます
• CAPGO_APPIDはCapgoから提供されるアプリケーションを一意に識別するために使用されます(例えば com.mystartup.mysuperapp)

6. semantic release + Capgo CapacitorUpdateのセットアップ

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

Github Actionsを使用してsemantic releaseで作成されたアプリケーションバンドルバージョン

Github Actionsを使用したsemantic releaseの自動化

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環境をインストールし、semantic releaseを呼び出すだけです。

ブランチリストに記載されているすべてのマージに対して branches, semantic release はデプロイをトリガーします。 Set CAPGO_APIKEY のシークレットに設定してください。 CAPGO_APPID の更新をしてください。

ここです。 .releaserc.json semantic release の動作は、その

// .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の場合、semantic release によって生成されるバージョン番号は「」になります。 デプロイは、 alpha-nocapgo branchは両方とも__CAPGO_KEEP_0__にアプリケーションをデプロイしますが、バージョン番号のプレリリース名が異なります。 alphachannelにデプロイされる開発ブランチ
  • または dev-rupert両方とも__CAPGO_KEEP_0__にデプロイされますが、同じプレリリースキーワードがバージョン番号に含まれます。 dev-paul : セマンティック リリースの最初のステージでは、__CAPGO_KEEP_0__に正しいアクセス権を持っていることを確認します。後で、__CAPGO_KEEP_1__ __CAPGO_KEEP_2__の認証チェックを追加することを願っています。 developmentchannel on Capgo, all with the same developmenthttps://__CAPGO_KEEP_0__.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format
• 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ビルドとセマンティックリリースの作業によって更新されたファイルをコミットします。github)
• @semantic-release/release-notes-generator __CAPGO_KEEP_1__ CHANGELOG.md
• @semantic-release/git __CAPGO_KEEP_2__package.json, CHANGELOG.md そして、- Android にビルドすることはまだしていません) ios/App/App.xcodeproj/project.pbxproj : __CAPGO_KEEP_0__ リリースにアセットとしてファイルを付与する
• @semantic-release/github : アプリのビルド用にこれらの 2 つのコマンドを使用して準備し、次に __CAPGO_KEEP_0__ サーバーにアプリ バンドルを有効にビルドして配布する CHANGELOG.md file to the Github release as an asset
• @semantic-release/execバージョン番号の計算方法やインクリメント方法、変更ログの生成、__CAPGO_KEEP_0__ タグまたはリリースの生成など、説明する必要のない細かい設定はすべて、シナティック リリースによって自動的に処理され、最小限の設定で済みます。prepareCmd) and then to effectively build deploy the app bundle to the Capgo servers (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 がビルドするように設定しました。このファイルは、シナティック リリースによって生成される各バージョン後に更新されます。

• and production)
• - Android にビルドすることはまだしていません) CHANGELOG.md : __CAPGO_KEEP_0__ リリースにアセットとしてファイルを付与する
• 異なるブランチでビルドをトリガーすることで、異なるチャンネルで展開するシミュレーションを実行できます。 branch.channel XCode Cloudの各構成で異なるブランチでビルドする場合、手動で環境変数を設定し、値を releaserc.json に設定します。

Building app binaries on XCode Cloud with Capgo channels

XCode Cloud上でアプリビニヤーをビルドする

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 :

• 結論として、14日間の試用期間内に標準的なシーケンスリリースパイプラインにCapgo CapacitorUpdaterを統合することができ、結果は以下のようになりました。
• semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
• シーケンスリリースは、__CAPGO_KEEP_1__チャンネルを使用して__CAPGO_KEEP_0__アプリケーションバンドルを自動的に展開します。

これは、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.

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

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

著者 - Rupert Barrow

Salesforceについて22年以上の経験があります。クライアントとユーザー、パートナーと統合者、設計者、開発者、ビジネスアナリスト、コンサルタントとして。13年間、フランスの成功したSalesforce SIパートナーであるAltius ServicesのCOOとCTOを共同設立し、共同運営しました。 Rapido Cloudの製品を提供するSalesforceのソロプレネュラーとしての新たな冒険を始めました。 LinkedInで私を見つけることができます。

https://linkedin.com/in/rbarrow Rapido CompanionのSalesforceオファリングをご覧ください。.

https://www.rapido-companion.app ']} ]} and https://www.rapido.cloud メイコトを不中に安了。