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

1. はじめに

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

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

この記事では、Capgoと__CAPGO_KEEP_1__ CapacitorUpdaterを使用した設計、選択、実装について説明します。これは、Capgo Actionsを使用して、すべての展開を自動的に管理するための、非常に成功し、頭を悩まされることなく実行できるものです。この設計、選択、実装は、__CAPGO_KEEP_1__ CapacitorUpdaterの14日間の無料試用期間中に設計、テスト、ドキュメント化されました。 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を使用する理由

Capgo CapacitorUpdater は、標準的なApple AppStore/Google PlayStore配信プロセスを通さずに、モバイルアプリの配信をより簡単、迅速、柔軟に行うことができることを約束しているので、私はそれに惹かれました。これは、私が過去にWebアプリに集中していたため、初めてモバイルアプリをストアに送信することになります。

私がこの成功を達成するための学習曲線に恐れを感じていましたが、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は、ソースcodeの新機能または修正を保存した1分後にも、実際のモバイルで私のアプリケーションを更新することができました。これは、非常にリラックスし、柔軟で、設定が簡単です。

3. 分枝とリリースモデル、そしてsemantic-releaseの位置付け

今、Capgoサーバーへの配信が正しく動作しているので、CI/CDパイプラインに自動化し、統合する必要があります。

このようにブランチングとリリースモデルを整理しています

モバイル、ウェブ、またはSalesforceのすべてのアプリケーションに対して:

開発は feature/... ブランチ mainから行われ main そして、メンテナンスやカスタムデリバリ用の特定の機能の外で、ほとんどの開発ブランチの基準となる
リリースブランチから デプロイがトリガーされ リリースブランチは production、プレリリースブランチalpha, beta, nightly、など
プルリクエストによってデプロイメントがトリガーされる マージされるデプロイメントブランチでは、タグトリガーによるデプロイメントは使用していません。シーケンスリリースはタグとその他すべてを管理するからです。

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

GitLabフロー

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

シーケンスリリースの動作についての補足

デプロイメントブランチで、シーケンスリリースがトリガーされたとき、シーケンスリリースは自動的にこのブランチ上の新しいバージョン番号を計算します。前のタグのバージョン番号とこのブランチに導入された修正や機能に基づいています。修正はパッチバージョンを新しく作成し、機能はマイナーバージョンを新しく作成します。プレビューも自動的にバージョン番号に含まれます。 alpha, betaシーケンスリリースは、コミットから変更ログを生成します。修正と機能を定義されたコンベンショナルコミット (https://www.conventionalcommits.org/en/about) に基づいてグループ化し、シーケンスリリースで設定されています。

シーケンスリリースは、コミットの変更を自動的に検出して、修正と機能を区別します。シーケンスリリースは、コミットの変更を自動的に検出して、修正と機能を区別します。シーケンスリリースは、コミットの変更を自動的に検出して、修正と機能を区別します。

Git (Github, 私の場合は) を含むすべてのマージされた Pull Request と関連する Issue を更新し、タグとリリースにリンクするコメントを付与します。最後に、この Github リリースでは、ソース code、バイナリが必要な場合など、必要なアセットを付与します。 CHANGELOG.md4. semantic release のブランチ、リリース/プレリリース、チャネル、および __CAPGO_KEEP_0__

Capgo のデプロイ用に、semantic release が行うことを望むことは何か。

Capgo のバージョン番号を生成するように semantic release に求める。

__CAPGO_KEEP_0__ は、Conventional Commits の「標準」バージョンを開発し、ドキュメント化しました。

https://Capgo.com/Cap-go/standard-version standard-version https://__CAPGO_KEEP_0__.com/Cap-go/__CAPGO_KEEP_1__-standard-version standard-version (https://github.com/Cap-go/__CAPGO_KEEP_1__-plugin-standard-versionIt will also update all your git (__CAPGO_KEEP_0__, in my case) merged pull requests and related issues with comments linking them to the tag and release. Finally, in this __CAPGO_KEEP_1__ release, it will attach assets such as source __CAPGO_KEEP_2__, binaries if necessary, etc. capacitor-standard-version (https://github.com/Cap-go/capacitor-standard-versionSo what I want semantic release to do for __CAPGO_KEEP_0__ deployments is the following. capacitor-plugin-standard-version (https://github.com/Cap-go/capacitor-plugin-standard-versionCapgoのリポジトリは、Capgoのデプロイメントにおけるバージョン管理の仕組みについて、ブログで詳細に説明しています。https://capgo.app/blog/how-version-work-in-capgo/JavaScriptバンドルは、標準的なsemver "Semantic Versioning" (https://semver.org)を採用しています。これも当然ながら、 semantic-release これはとても素晴らしいことであり、自分自身が広く使用しているため、心配する必要はありません。

また、semantic releaseは、異なるチャンネルでアプリのデプロイを自動化したいと考えています。 semantic-release 上記で述べたように、プレビュー版のバージョンをブランチなどからデプロイしたいと考えていますが、

また、顧客ごとのバージョンをブランチなどからデプロイしたいと考えています。

など alpha, beta, nightly など production-customer-jones, production-customer-doeなど

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

シナティックリリースによって生成されるprereleasesのsemverバージョン番号は 1.0.0-alpha.1このブランチ上の連続したビルドでは、ビルド番号を 1.0.0-alpha.2、などと増分されます。シナティックリリースによって生成されるprereleasesのsemverバージョン番号は、Capgoによってサポートされていることがわかっています。これは私にとって大きなニュースです：私はシナティックリリースのチャンネルとprereleaseを使用して、Capgoチャンネルで私のアプリのバージョンをCapgoで生成することになります。

5. Capgoを使用してアプリケーションをリリースする方法はありますか。

アプリケーションバンドルをCapgoに自動的にデプロイするには、Capgo CLIコマンドを使用する必要があります。 bundle uploadタイプ 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は、シナティックリリースによって生成されたバージョン番号です(例えば 1.0.0-alpha.1)
CAPGO_APIKEYは、Capgoによって提供されるCI/CDパイプラインのログインを一意に識別するためのAPIキーです。
CAPGO_APPIDは、Capgoによって提供されるアプリケーションを一意に識別するためのIDです(例えば com.mystartup.mysuperapp)

6. マイナのリリース + Capgo CapacitorUpdate 設定

最後に、これはすべてどうやってつながっているのですか?

Github Actions を使用したシナティックリリースとともに作成されたアプリバンドルバージョン

Github Actions を使用したシナティックリリースとともに作成されたアプリバンドルバージョン

Github Actions を使用したシナティックリリースの自動化

シナティックリリースの美しさは、Github Action ワークフローとして表現されるデプロイメントの自動化が非常に簡単であることです。これは他の 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、すると、semantic release によって生成されるバージョン番号は branch.prerelease = "development"にデプロイされる x.y.z-development.n
- と alphaブランチは両方とも alpha-nocapgo チャネルにアプリをデプロイしますが、バージョン番号のプレリリース名が異なります。 alpha開発者ブランチにデプロイされる
- dev-rupert dev-paul 両方のチャネルに__CAPGO_KEEP_0__にリリースされます。 developmentCapgoのチャネルにすべてのCapgoのバージョン番号に同じCapgoのキーワードが含まれています。 development: __CAPGO_KEEP_0__の初期段階のセマンティックリリースでは、__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 : __CAPGO_KEEP_0__の変更履歴ファイルを生成します。 CHANGELOG.md
@semantic-release/git : __CAPGO_KEEP_0__のリリースに__CAPGO_KEEP_0__のファイルをアタッチします。package.json, CHANGELOG.md : __CAPGO_KEEP_0__のアプリケーションをビルドしたファイルとセマンティックリリースによって更新されたファイルをコミットします。 ios/App/App.xcodeproj/project.pbxproj そして
@semantic-release/github - Android用にビルドしていません。 CHANGELOG.md : Githubのファイルをリリースにアタッチします。
@semantic-release/exec: この 2 つのコマンドを使用してアプリのビルドを準備します (prepareCmd) そして、Capgo サーバーにアプリバンドルを有効にビルドおよび展開します (publishCmd)

バージョン番号の計算とインクリメント方法、変更ログの生成、Github タグまたはリリースの生成方法については、説明する必要がありません。semantic release がデフォルトで管理し、最小限の設定で済みます。

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

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

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

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

XCode CloudでアプリバイナリをCapgoチャンネルでビルドしています。

7. 結論

Capgo CapacitorUpdaterを標準的なシーマティックリリースパイプラインに組み込むことができ、14日間の試用期間の遅延なしで迅速に実行でき、結果は以下のようになりました。

シーマティックリリースは自動的にCapgoサーバーと互換性のあるバンドルバージョン番号を生成し、__CAPGO_KEEP_1__チャンネルも使用します。
シーマティックリリースは自動的にCapgoアプリケーションバンドルをデプロイし、Capgoチャンネルも使用します。
これは、XCode Cloudでアプリバイナリのビルドにぴったりです。

次のステップ

このアプリの開発中です。テスト用にTestFlight (iOS)ですぐに公開する予定です。Capgoの力に感銘を受けたので、AppStoreに無料版のアプリを公開し、Capgoで定期的に更新する予定です。その後、AppStoreに別の(有料)版のアプリを公開し、Capgoで定期的に更新する予定です。

Capgoの前ビルド検証を改善することを望んでいます。 bundle upload シーマティックリリースの構成にprerequisitesを追加することを望んでいます。

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

著者 - Rupert Barrow

22年以上の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.cloud 開発中です。作成者ルパート・バロウ