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

1. はじめに

Rapido Cloud (www.rapido.cloudSalesforce クライアント向けのモバイル アプリケーションを簡単に開発し、Salesforce Mobile SDK または Salesforce Mobile Publisher を使用せずにブランド化されたモバイル アプリケーションを展開できるようにするために、Rapido Cloud (

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.

私は、Ionic 8、Angular 18、TypeScript、Capgo、そして今 __CAPGO_KEEP_1__ CapacitorUpdater を使用して、このモバイル アプリケーションを開発しました。これらのコンポーネントとツールは、Lightning Web Components を管理する必要がなく、クライアントにとって扱いやすく、また私にとって開発者とメンテナンス者を募集しやすく、維持も安くて簡単です。 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.

自動的にすべての展開を管理する Capgo Actions を使用することの利点について説明します。この設計、選択、実装はすべて、__CAPGO_KEEP_1__ CapacitorUpdater の 14 日間の無料試用期間中に設計、テスト、ドキュメント化されました。

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

I was rather afraid of the learning curve to make this successful but I got my app onto Apple TestFlight quite easily. I was then in position to use Capgo CapacitorUpdater to deploy my updates much faster.

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.

分岐とリリースモデルはどのように構成されているか

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

• 開発は ブランチが feature/... そして、 mainにマージされる main は、ほとんどの開発ブランチの基準となる
• __CAPGO_KEEP_0__はリリースブランチからトリガーされます。 __CAPGO_KEEP_0__は、以下のブランチなどが含まれます： __CAPGO_KEEP_0__ブランチ（など）と、カスタマー固有のブランチやコンテキスト固有のブランチも含まれます。 production__CAPGO_KEEP_0__はプルリクエストによってトリガーされます。alpha, beta, nightly__CAPGO_KEEP_0__がデプロイブランチにマージされるのを待っています。タグによってトリガーされるデプロイは使用していません。semantic-releaseはタグを管理し、他のすべてのものも管理してくれるからです。
• 基本的には、このGitLabフローです。 GitLabフロー

GitLabフロー - ソース

semantic-releaseの動作についての補足です。 __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

In __CAPGO_KEEP_0__ branchにおける、semantic-releaseがトリガーされたとき、自動的にこのbranchにおける前のタグのバージョン番号と修正されたバグや機能によって新しいバージョン番号を計算します。修正はpatchバージョンを新しく作成し、機能はminorバージョンを新しく作成します。さらに、prerelease alpha, betaなどを含むバージョン番号も自動的に含まれます。

semantic releaseは、conventional commits (https://www.conventionalcommits.org/en/about)に従って、fixesとfeaturesをグループ化し、__CAPGO_KEEP_0__で定義されたコミットから変更ログを自動生成します。 さらに、__CAPGO_KEEP_0__のマージされたpull requestと関連するissueにタグとリリースへのリンクを含むコメントを自動的に更新します。最後に、この__CAPGO_KEEP_1__リリースでは、ソース__CAPGO_KEEP_2__、バイナリなど必要なアセットを付属させます。4. semantic releaseと__CAPGO_KEEP_0__におけるbranch、release/prerelease、channel

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の「tool」の独自のバージョンを開発し、ドキュメント化しています。

Capgoは、Conventional Commitsの「tool」の独自のバージョンを開発し、ドキュメント化しています。

https://www.conventionalcommits.org/en/about

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-versionCapgoの標準バージョン capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-version) また capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-version) repos. They have documented on their blog the version scheme used by Capgo in their deployemnts (https://capgo.app/blog/how-version-work-in-capgo/）リポジトリもあります。Capgoの利用者は、Capgoのデプロイメントで使用されているバージョン管理スキームについて、ブログで詳細に説明しています (https://__CAPGO_KEEP_0__.app/blog/how-version-work-in-__CAPGO_KEEP_1__/ semantic-release ).

JavaScriptのバンドルは、セマンティックバージョニング（Semantic Versioning）「標準」セマンティックバージョニングを採用しています (「https://semver.org」)。これはもちろんのことです。なぜなら、Capgoもセマンティックバージョニングを採用しているからです。 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を使用してアプリケーションをリリースする方法はありますか。

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 Capgoのアップロードオプションを取得するには、以下のオプションを使用します :

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

6. My semantic release + Capgo CapacitorUpdate setup

Capgoのアップロードオプションを取得するには、以下のオプションを使用します :

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のアップロードオプションを取得するには、以下のオプションを使用します :

すべてのブランチリスト内のマージごとに、 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 ブランチは両方とも、バージョン番号のプレリリース名が異なるままアプリを alphaチャンネルにデプロイします。
  • 開発者用ブランチへの dev-rupertデプロイは両方ともチャンネルにデプロイします。 dev-paul チャンネルにデプロイします。 developmentCapgoで同じプレリリースキーワードが含まれるバージョン番号のままです。 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://github.com/semantic-release/semantic-release?tab=readme-ov-file#commit-message-format)
• @semantic-release/release-notes-generator 変更ログファイルを生成します。 CHANGELOG.md
• @semantic-release/git : __CAPGO_KEEP_0__アプリケーションのIonicビルドとセマンティックリリースの作業によって更新されたファイルをコミットするpackage.json, CHANGELOG.md : __CAPGO_KEEP_0__リリースにアセットとしてファイルを付与する ios/App/App.xcodeproj/project.pbxproj : 以下の2つのコマンドを使用してアプリのビルドを準備し、__CAPGO_KEEP_0__サーバーにアプリのバンドルをデプロイする
• @semantic-release/github ) CHANGELOG.md : Githubサーバーにアプリのバンドルをデプロイする
• @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がビルドするように設定しました

• I don’t build for Android, yet production)
• and CHANGELOG.md ファイルは更新されます。この更新は、セマンティック リリースによって生成される各バージョンごとに実行されます。
• 異なるブランチでビルドをトリガーして、異なるチャンネルでデプロイをシミュレートできます。各XCode Cloudの構成で、異なるブランチでビルドを実行し、環境変数を手動で設定します。 branch.channel 設定されている値 releaserc.json (はい、これは手動の複製です)。そして、必要に応じて、カスタムリリースブランチからカスタムクライアントアプリケーションをデプロイするために、各カスタムクライアントアプリケーション用に異なるAppStoreアプリケーションをデプロイすることもできます。

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

7. 結論

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

• bundleバージョン番号はセマンティックリリースによって自動的に生成され、Capgoサーバーと互換性があります。
• セマンティックリリースは、Capgoチャンネルを使用して、Capgoアプリケーションバンドルを自動的にデプロイします。
• これは、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のクライアントとして、Salesforceのパートナーとして、Salesforceの統合者として、Salesforceの設計者として、Salesforceの開発者として、Salesforceのビジネスアナリストとして、Salesforceのコンサルタントとして、13年間、Altius ServicesのCOOおよびCTOとして、成功したSalesforceのSIパートナーであるフランスのAltius Servicesを共同設立および共同運営し、Salesforceのソロプレネュアとして、Rapido Cloudの製品を提供することから始めました。 LinkedInで私を見つけてください。 https://linkedin.com/in/rbarrow

Rapido CloudのSalesforceの製品をご覧ください。 https://www.rapido-companion.app.

Rapido Cloudの製品をご覧ください。 https://www.rapido-companion.app and https://www.rapido.cloud (under development).

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

CapacitorUpdaterを使用している場合 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater ライブアップデートの配信計画を実施するには、CapacitorUpdaterを Capgo Live Updates for the product workflow in Capgo Live Updates, 概要 概要の実装詳細を確認する 機能 __CAPGO_KEEP_0__ の実装詳細については、 Update Behavior __CAPGO_KEEP_0__ の実装詳細については、Update Behavior、 Update Types __CAPGO_KEEP_0__ の実装詳細については、Update Types。