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

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. 分岐とリリースモデル、そしてsemantic-releaseの位置づけ

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

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

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

• 開発は ブランチから始まり、 feature/... そして、メンテナンスやカスタムデリバリ用の特定の機能の外では、 mainのブランチにマージされる。 main は、ほとんどの開発ブランチの基準となる。
• CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法 リリースブランチから リリースブランチ production、プレリリースブランチalpha, beta, nightly、など）および、カスタマー固有のまたはコンテキスト固有のブランチをカスタムデリバリー用に
• デプロイメントは、デプロイメントブランチにマージされるプルリクエストによってトリガーされます。 私はタグトリガーによるデプロイメントを使用していません。セマンティックリリースはタグとその他のすべてを管理するからです。

基本的には、このGitLabフローです。

GitLabフロー - ソース https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022

セマンティックリリースの動作についての補足

In __CAPGO_KEEP_0__ のデプロイブランチで、セマンティックリリースがトリガーされたとき、セマンティックリリースはこのブランチで自動的に新しいバージョン番号を計算します。このブランチの前のタグのバージョン番号と修正または機能の提供に基づいて。 alpha, betaIn __CAPGO_KEEP_0__ のバージョン番号に、etc. を含める。

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

Capgo は、Conventional Commits の “Conventional Commits” のバージョンを開発し、ドキュメント化しました。

Capgo の forked repo

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

Capgo have developed and documented their own version of the “Conventional Commits” standard-version __CAPGO_KEEP_0__ 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 も同様に採用している。

So、それはすばらしいことであり、自分が使用しているため、自分に安心感を与えている。 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チャンネルでアプリのバージョンを__CAPGO_KEEP_2__で生成できる。

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

アプリのバンドルをCapgoに自動的にデプロイするには、Capgo CLIコマンドを使用する必要がある。 bundle uploadコマンドを入力してください npx @capgo/cli@latest bundle upload --help CapgoでCapacitorUpdaterを使用してセマンティックリリースを管理する方法

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. セマンティックリリースと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 }}

セマンティックリリースの美しさは、デプロイの自動化が、__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 開発ブランチへのデプロイ 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 __CAPGO_KEEP_0__にデプロイしますが、バージョン番号のプレリリース名が異なります。githubにデプロイしますが、バージョン番号のプレリリース名が異なります。)
• @semantic-release/release-notes-generator __CAPGO_KEEP_0__にデプロイしますが、バージョン番号のプレリリース名が異なります。 CHANGELOG.md
• @semantic-release/git : __CAPGO_KEEP_0__ にアップデートされたファイルを含むアプリケーションの Ionic ビルドとセマンティック リリースのファイルをコミットする (package.json, CHANGELOG.md そして ios/App/App.xcodeproj/project.pbxproj - まだAndroid用にビルドしていない
• @semantic-release/github : __CAPGO_KEEP_0__ リリースにアセットとしてファイルを付与する CHANGELOG.md file to the Github release as an asset
• @semantic-release/exec) そして、__CAPGO_KEEP_0__ サーバーにアプリケーションバンドルを有効にビルドして配布する (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でアプリケーションバイナリの新しいバージョンをビルドするのと、Google Playにデプロイするのと似たようなプロセスです (まだGoogle Playにデプロイしていませんが、ビルドは似ています):

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

• このブランチで変更が発生したときに、XCode Cloudをビルドするように設定しました production)
• 変更が発生したときにのみビルドするように設定しました 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のソロプレネュラーとしての新しい冒険を始めました。 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 CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法から続きます。 Capgo Live Updates for the product workflow in Capgo Live Updates, CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapgoのCapacitorUpdaterを使用してセマンティックリリースを管理する方法 CapgoのCapacitorUpdaterを使用したSemantic Releaseの管理方法 アップデートの動作 CapacitorUpdaterのアップデートの動作の実装詳細 アップデートの種類 CapacitorUpdaterのアップデートの種類の実装詳細