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

1. はじめに

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

モバイル アプリケーションを、広く使用されているコンポーネントとツールを使用した、現代的な「標準」プラットフォームで開発しました。Ionic 8、Angular 18、TypeScript、Capacitor、そして今では Capgo CapacitorUpdater などが含まれます。これらのツールは、Salesforce プラットフォームの特定の部分を管理しないクライアントにとって扱いやすく、また、Ionic + Angular モバイル アプリケーションの開発者とメンテナンス者を募集しやすく、維持も安価です。

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.

Capgo CapacitorUpdater は、Apple AppStore/Google PlayStore での標準的な配布プロセスよりも、モバイル アプリケーションの配布をより簡単、より迅速、より柔軟に実現することを約束したため、Capgo を魅了しました。 これは、私が過去に開発したウェブ アプリケーションに比べて、初めてのモバイル アプリケーションです。

2. なぜ Capgo を使用するのですか? なぜセマンティック リリースを使用するのですか?

Iはこの成功のための学習曲線に少し怖かったが、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 !

Capgo CapacitorUpdaterは、1分以内に保存した新機能または修正をソース code に保存した後、実際のモバイルでアプリケーションを更新するのに役立った。とてもリラックスでき、柔軟で、簡単に設定できた。

3. 分岐とリリースモデル、そしてシーマティックリリースの位置づけ

Capgo サーバーへの配信を正しく実行できたので、CI/CD パイプラインに自動化して組み込む必要がある。

このように分岐とリリースモデルを組織する

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

• 開発は Branchesから feature/... 、そして mainにマージされる main は、ほとんどの開発Branchの基準となる。メンテナンスやカスタムデリバリ用の特定の機能の外では
• デプロイメントはトリガーされます。 リリースブランチからトリガーされます。 リリースブランチは以下のいずれかになります。 production, プレリリースブランチ (alpha, beta, nightly, など) およびカスタマー固有のまたはコンテキスト固有のブランチもカスタムデリバリ用に使用できます。
• デプロイメントはプルリクエストのマージ時にトリガーされます。タグトリガーを使用しません。なぜなら、セマンティックリリースはタグを管理し、すべての残りのものも自分で管理するからです。 基本的には、このGitLabフローです。

GitLabフロー

https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022 セマンティックリリースの動作についての補足

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

In __CAPGO_KEEP_0__ branchで、セマンティックリリースがトリガーされたとき、セマンティックリリースはこのbranchの新しいバージョン番号を自動的に計算します。これは、branch上の前のタグのバージョン番号と、提供された修正または機能に依存します。修正は新しいパッチバージョンを生成し、機能は新しいマイナーバージョンを生成します。セマンティックリリースは自動的にprereleaseも含めます。 alpha, betaetc.を含むバージョン番号。

セマンティックリリースは、コミットからchangelogを生成し、修正と機能を定義されたconventional commits (https://www.conventionalcommits.org/en/about参照)に従ってグループ化します。また、セマンティックリリースの設定に従ってグループ化します。 セマンティックリリースは、__CAPGO_KEEP_0__でマージされたpull requestと関連するissueを更新し、コメントでタグとリリースにリンクします。最後に、この__CAPGO_KEEP_1__リリースでは、ソースコード__CAPGO_KEEP_2__、バイナリなど必要なアセットを添付します。4. セマンティックリリースと__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.mdセマンティックリリースがバージョン番号を生成するようにしたい。

4. Branches, releases/prereleases, channels in semantic release and in Capgo

So what I want semantic release to do for Capgo deployments is the following.

CapacitorUpdater

Capgo have developed and documented their own version of the “Conventional Commits” standard-version Capgo 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 広く使用されています。

また、セマンティック リリースが異なるチャンネルでアプリのデプロイを生成したいと考えています。

上記のように述べたように、プリリリース版のデプロイは、ブランチとして以下のようなものから行う必要があります。 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を使用してアプリケーションをリリースするにはどうすればよいですか?

アプリケーションバンドルのCapgoへのデプロイを自動化するには、Capgo CLIコマンドを使用する必要があります。 bundle uploadコマンドを入力してください npx @capgo/cli@latest bundle upload --help Capgoを使用してSemantic Releaseを管理する方法

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)
• CHANNELは、Capgoを使用してデプロイしたいチャンネル名です(例えば) 1.0.0-alpha.1)
• CAPGO_APIKEY is provided by Capgo to uniquely identify your CI/CD pipeline login
• CAPGO_APIKEYは、Capgoから提供されるAPIキーです。CI/CDパイプラインのログインに使用します。 com.mystartup.mysuperapp)

Capgo_APPIDは、__CAPGO_KEEP_1__から提供されるアプリケーションIDです。アプリケーションを一意に識別します(例えば)

6. Semantic ReleaseとCapacitorUpdaterのセットアップ

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 }}

Semantic Releaseの美しさは、デプロイの自動化が、__CAPGO_KEEP_0__ Actionsのワークフローとして非常に簡単です。これは他のCI/CDプラットフォームでも同様です。

For every branch on a listed in branches, semantic release will trigger a deployment. CAPGO_APIKEY Set in your repository’s secrets. CAPGO_APPID Update your here.

Page/area: Capgo marketing website. Role: Website copy sentence. Seen in: component pricing/Faq.astro. Message key `here` (Here). .releaserc.json The behavior of semantic release is set in its configuration file.

// .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 Here are my settings, explained below :name), mapped to the Capgo channel (channel), mapped to the __CAPGO_KEEP_0__ channel (prerelease) and how the prerelease version number will be called ( branch.prerelease = "development"). For example, if x.y.z-development.n
  • , the version number generated by semantic release will be deployments to the alphaと alpha-nocapgo ブランチは両方とも__CAPGO_KEEP_0__にアプリケーションをデプロイしますが、バージョン番号のプレリリース名が異なります。 alpha開発ブランチへのデプロイ
  • もしくは dev-rupert両方のブランチは__CAPGO_KEEP_0__にアプリケーションをデプロイしますが、バージョン番号のプレリリース名が異なります。 dev-paul 両方のブランチは__CAPGO_KEEP_0__にアプリケーションをデプロイしますが、バージョン番号のプレリリース名が異なります。 developmentCapgoにアクセスできることを確認します。後で__CAPGO_KEEP_1____CAPGO_KEEP_2__の認証チェックを追加したいと思います。 development:最初の段階では、__CAPGO_KEEP_0__にアクセスできることを確認します。後で__CAPGO_KEEP_1____CAPGO_KEEP_2__の認証チェックを追加したいと思います。
• 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 __CAPGO_KEEP_0__のドキュメントを参照してください。 CHANGELOG.md
• @semantic-release/git : このファイルを、Ionic ビルドとセマンティック リリースの作業によって更新されたアプリケーションのファイルをコミットします (package.json, CHANGELOG.md そして ios/App/App.xcodeproj/project.pbxproj : Android にビルドしない
• @semantic-release/github : このファイルを __CAPGO_KEEP_0__ リリースにアタッチします CHANGELOG.md : この 2 つのコマンドを使用して、アプリのビルドを準備し、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 をビルドするように設定します

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

Building app binaries on XCode Cloud with Capgo channels

7. 結論

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 :

• bundle version numbers are generated automatically by semantic release and compatible with the Capgo servers
• semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
• これは、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を使用してきました。13年間、フランスの成功したSalesforce SIパートナーであるAltius ServicesのCOOおよびCTOを共同設立および共同運営し、Salesforce solopreneurとしての新たな冒険を始めています。 Rapido Cloud LinkedInで私を見つけてください。

https://linkedin.com/in/rbarrow Salesforceの提供物をご覧ください。.

https://www.rapido-companion.app https://www.rapido-companion.app と https://www.rapido.cloud (開発中)

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

CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater CapacitorUpdaterを使用してセマンティックリリースを管理する方法から続けて Capgo Live Updates for the product workflow in Capgo Live Updates, CapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法 アップデートの動作 CapacitorUpdaterのアップデートの動作の実装詳細について アップデートの種類 CapacitorUpdaterのアップデートの種類の実装詳細について