How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater

CapacitorUpdaterを使用するアプリケーションのリリースを管理する方法

1. イントロダクションRapido Cloud (www.rapido.cloud) で、Salesforce クライアント向けのモバイル アプリケーションを開発しています。このアプリケーションを使用すると、Salesforce Mobile __CAPGO_KEEP_0__ または Salesforce Mobile Publisher を使用する難しいループを回避して、自社ブランドのモバイル アプリケーションを簡単に展開できます。), 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.

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

この記事では、Capgoの設計、選択、実装について説明します。 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. なぜCapgoを使用するのか？なぜセマンティックリリースを使用するのか？

Capgo CapacitorUpdaterは、モバイルアプリの配布をより簡単、迅速、柔軟に行うことができることを約束したため、興味を持つようになりました。 これは、私が過去に開発したWebアプリケーションとは異なり、初めてモバイルアプリケーションをストアに配布することになりました。

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. ブランチングとリリースモデル、そして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 デプロイはトリガーされます
• targetLanguage Capgoを使用したCapacitorUpdaterとセマンティックリリースの管理方法 リリースブランチ production以下の可能性がありますalpha, beta, nightly、プレリリースブランチ（
• 、など）およびカスタマー固有のまたはコンテキスト固有のブランチもカスタムデリバリ用に使用できます デプロイメントはプルリクエストのマージ時にトリガーされます

デプロイメントブランチへのマージ時にデプロイメントがトリガーされるため、タグトリガーによるデプロイメントは使用していません。セマンティックリリースはタグとその他すべてのものを管理するからです。

GitLabフロー GitLabフロー - ソース

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

セマンティックリリースの動作についての補足的なメモ alpha, betaバージョン番号の等号など。

セマンティック リリースは、コミットから changelog を生成し、修正と機能を定義されたコミットの規則 (https://www.conventionalcommits.org/en/about) に従ってグループ化し、セマンティック リリースで構成します。 https://www.conventionalcommits.org/en/aboutセマンティック リリースは、Git (__CAPGO_KEEP_0__, 私の場合は) にマージされた pull requests と関連する issue を更新し、タグとリリースにリンクするコメントを付与します。最後に、この __CAPGO_KEEP_1__ リリースでは、ソースコード (__CAPGO_KEEP_2__)、バイナリなど必要なものを添付します。

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.md4. セマンティック リリースと __CAPGO_KEEP_0__ のブランチ、リリース/プレリリース、チャネル

したがって、私は Capgo のデプロイメントでセマンティック リリースが行うことを以下のようにしたい。

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

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

Capgo のフォークされたリポジトリ standard-version https://__CAPGO_KEEP_0__.com/Cap-go/standard-version standard-version (github）とその独自の 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 は、セマンティック リリースによって生成されます (例 1.0.0-alpha.1)
• CAPGO_APIKEY は、Capgo から提供されるCI/CD パイプライン ログインのユニークな識別子として提供されます
• CAPGO_APPID は、Capgo から提供されるアプリケーションのユニークな識別子として提供されます (例 com.mystartup.mysuperapp)

6. セマンティック リリースと Capgo CapacitorUpdate のセットアップ

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

セマンティック リリースと 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), mapped to the Capgo channel (channelセマンティック リリースの設定ファイルの設定は、以下のようになっています。 以下の設定をご覧ください。prereleaseセマンティック リリースの設定ファイルの設定は、以下のようになっています。 以下の設定をご覧ください。 branch.prerelease = "development"セマンティック リリースの設定ファイルの設定は、以下のようになっています。 以下の設定をご覧ください。 x.y.z-development.n
  • セマンティック リリースの設定ファイルの設定は、以下のようになっています。 以下の設定をご覧ください。 alphaセマンティック リリースの設定ファイルの設定は、以下のようになっています。 以下の設定をご覧ください。 alpha-nocapgo ブランチは両方とも__CAPGO_KEEP_0__にアプリをデプロイします。 alphaチャンネルにデプロイしますが、バージョン番号のプレリリース名が異なります。
  • 開発者ブランチにデプロイします。 dev-rupertまたは dev-paul チャンネルにデプロイします。 developmentチャンネルにデプロイしますが、Capgoのバージョン番号に異なるプレリリース名が含まれます。 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__にデプロイします。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__ タグまたはリリースの生成方法については、説明する必要がありません。 : semantic releaseは、最小限の設定でデフォルトですべてを処理します。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がビルドするように設定しました。この設定は、semantic releaseによって生成された各バージョン後に更新されます

• ブランチでファイルが更新されたときに production)
• XCode Cloudがビルドするように設定しました CHANGELOG.md この設定は、semantic releaseによって生成された各バージョン後に更新されます
• Capgoを使用してCapacitorUpdaterと組み合わせてセマンティックリリースを管理する方法について branch.channel セマンティックリリースの標準パイプラインにCapacitorUpdaterを組み込むことができ、14日間の試用期間内に迅速に実行できました。 releaserc.json セマンティックリリースは自動的に__CAPGO_KEEP_0__アプリケーションバンドルをデプロイし、__CAPGO_KEEP_1__チャンネルも使用します。

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 :

• セマンティックリリースは自動的にCapgoアプリケーションバンドルをデプロイし、__CAPGO_KEEP_1__チャンネルも使用します。
• semantic release automatically deploys Capgo application bundles, also making use of Capgo channels
• アプリケーションビニヤーをXCode Cloudでビルドする

アプリケーションビニヤーを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を追加するように私のsemantican release設定に

I now have a clean, simple an reproducible semantic release pipeline for future mobile apps developed with Ionic + Angular + Capacitor.

著者 - Rupert Barrow

Salesforceの22年以上の経験があります。クライアントとユーザー、パートナーと統合者、設計者、開発者、ビジネスアナリスト、コンサルタントとして。13年間、フランスの成功したSalesforce SIパートナーであるAltius ServicesのCOOおよびCTOを共同設立および共同運営し、Salesforce solopreneurとしての新しい冒険を始めています。 Rapido Cloud LinkedInで私を見つけてください

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

https://www.rapido-companion.app そして context:Capgoマーケティングウェブサイト。役割:短いUIラベルまたはナビゲーションアイテム。見つかった場所:ページtrust.astro。メッセージキー`and` (And). https://www.rapido.cloud (開発中)

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

CapacitorUpdaterを使用している場合 How Rapido Cloud manage Semantic Release with Capgo CapacitorUpdater CapacitorUpdaterを使用してライブアップデートの配信計画を立てるには、CapacitorUpdaterを Capgo Live Updates for the product workflow in Capgo Live Updates, 概要 ライブアップデートの実装詳細 機能 ライブアップデートの実装詳細 アップデート動作 アップデート動作の実装詳細について アップデートの種類 アップデートの種類の実装詳細について