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 semantic-release 自動デプロイをすべて Github Actions により管理するのは、非常に簡単で無駄な作業です。すべてのものは、Capgo CapacitorUpdater の 14 日間の無料試用期間中に設計、テスト、ドキュメント化されました。
2. なぜ Capgo を使用する必要があるのですか? なぜ semantic-release を使用する必要があるのですか?
Capgo CapacitorUpdater は、標準の Apple AppStore/Google PlayStore での配布プロセスよりも、モバイルアプリのデプロイをより簡単、迅速、柔軟にすることを約束したことが私の興味を引いた。 これは、私が過去にウェブアプリケーションに集中していたため、初めてモバイルアプリケーションをストアに送信することになりました。 私は、モバイルアプリのデプロイに成功するには、学習曲線が高くて怖かったのですが、Apple TestFlight にアプリを簡単にアップロードできました。 その後、私は Capgo CapacitorUpdater を使用して、更新をより速くデプロイすることができました。
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.
2. なぜ Capacitor を使用する必要があるのですか? なぜ semantic-release を使用する必要があるのですか?
So Capgo CapacitorUpdaterは私がモバイル上でアプリケーションをリアルタイムに更新するのに役立ちました。新しい機能や修正をソースcodeに保存した1分後、1分以内に更新されました。とてもリラックスでき、柔軟で、設定も簡単です。
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.
以下に示すように、ブランチングとリリースモデルをどのように組織しているか
Capgoのすべてのアプリケーション、モバイル、Web、Salesforceを含む
- 開発は ブランチが
feature/...、そしてマージされるmainこれは、メンテナンスやカスタムデリバリー用の特定の機能の外で、ほとんどの開発ブランチの基準となるmainリリースブランチから - デプロイがトリガーされる デプロイは which may be :
production, プルリクエスト (alpha,beta,nightly, など) およびカスタマー固有のまたはコンテキスト固有のブランチ ( - , deployments are triggered by a pull request
being merged into a deployment branch. I don’t use tag-triggered deployments because semantic release manages tags and all the rest for me.
GitLab Flow GitLab Flow - source
https://faun.dev/c/stories/manuelherrera/git-branching-strategies-in-2022
A side-note on how semantic-release works : alpha, betaIn a deployment branch, when semantic-release is triggered, it will automatically calculate the new version number on this branch, depending on the version number of the previous tag on the branch and the delivered fixes or features. Fixes will create a new patch version, whereas features will create a new minor version. It also automatically includes the prerelease
Semantic release は、コミットから changelog を生成し、修正と機能を定義されたコミット (https://www.conventionalcommits.org/en/about) に基づいてグループ化し、semantic release で構成されます。 また、Git (__CAPGO_KEEP_0__, 私の場合は) にマージされた pull requests と関連する issue にコメントを付けて、タグとリリースにリンクすることも行います。最後に、この __CAPGO_KEEP_1__ リリースでは、ソース __CAPGO_KEEP_2__、バイナリなど必要なものを含むアセットを付属させます。4. semantic release と __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.mdsemantic release がバージョン番号を生成するようにしたい。
Capgo は、Conventional Commits の「標準版」を独自に開発し、ドキュメント化しています (https://Capgo.com/Cap-go/standard-version)。
So what I want semantic release to do for Capgo deployments is the following.
https://__CAPGO_KEEP_0__.com/Cap-go/standard-version
Capgo have developed and documented their own version of the “Conventional Commits” standard-version Capgo 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) のリポジトリがあります。彼らは、Capgoのデプロイメントで使用されるバージョン管理スキームについて、ブログで詳細に説明しています (https://capgo.app/blog/how-version-work-in-capgo/)。JavaScript バンドルは、"標準"のsemver "Semantic Versioning" (https://semver.org) に従っています。 semantic-release これも当然のことです。
これは素晴らしいことであり、自分が使用しているため、私にとっては大きなリリーフとなります。 semantic-release 私はこれを広く使用しています。
また、シナリオ リリースを使用して、異なるチャンネルでのアプリケーションのデプロイメントを自動化したいです。
上記のように述べたように、ブランチ名などを含む未リリース版をデプロイする必要があります。 alpha, beta, nightly etc.、また、ブランチとしてのカスタマー固有のバージョンなど production-customer-jones, production-customer-doe、など
Capgoは「チャンネル」機能を提供しており、これはシーマティックリリースもサポートしている機能なので、両方を組み合わせることができるのを楽しみにしています。これらはまた、XCode Cloudが管理する異なるブランチのビルドに適合しています。
semantic releaseがプレビュー版で生成するSemverバージョン番号は 1.0.0-alpha.1.__CAPGO_KEEP_0__.のこのブランチでの連続したビルドは、ビルド番号を増分します。 1.0.0-alpha.2、etc。明示的にドキュメント化されていないが、これらのバージョン番号は Capgo によってサポートされています。これは私にとって素晴らしいニュースです：私は Capgo チャンネルを使用して、セマンティック リリース チャンネルと プリリリースを使用して、自分のアプリのバージョンを生成します。
5. Capgo を使用してアプリケーションをリリースする方法はありますか。
アプリケーションバンドルの自動デプロイを実現するには、Capgo へのデプロイを Capgo で CLI コマンドを使用する必要があります。 bundle upload. Type 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) - バージョンはsemantic release (例
1.0.0-alpha.1) - CAPGO_APIKEYはCapgoからCI/CDパイプラインログインに一意の識別子として提供されます。
- CAPGO_APPIDはCapgoからアプリケーションに一意の識別子として提供されます (例
com.mystartup.mysuperapp)
6. semantic release + Capgo CapacitorUpdate設定
最後に、これはどのようにすべてがつながっているのかを教えてください。
semantic releaseとGithub Actionsで構築されたアプリケーションバンドルのバージョン
Github Actionsを使用したsemantic releaseの自動化
semantic releaseの美しさは、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環境をインストールし、semantic releaseを呼び出すだけです。
ブランチのリストに記載されているすべてのマージごとに、semantic releaseはデプロイをトリガーします。
設定 branches, semantic release will trigger a deployment.
Set CAPGO_APIKEY リポジトリのシークレットに記載してください。
Capgoの設定を更新してください。 CAPGO_APPID ここ。
semantic releaseの動作は、その .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) を設定します。たとえば、branch.prerelease = "development"の場合、semantic releaseによって生成されるバージョン番号はx.y.z-development.n- となります。
alphaCloudflareにデプロイするalpha-nocapgoGitHub Pagesにデプロイするalphaチャンネルですが、バージョン番号のプレリリース名が異なります。 - 開発者ブランチへのデプロイ
dev-rupertまたはdev-paul両方とも、__CAPGO_KEEP_0__チャンネルにデプロイされます。バージョン番号のプレリリースキーワードは同じです。development: セマンティックリリースの最初のステージでは、Capgoに正しいアクセス権を持っていることを確認します。後で、__CAPGO_KEEP_1__ __CAPGO_KEEP_2__の認証チェックを追加したいと思います。development: セマンティックリリースの標準的なもの - そのドキュメントを参照してください (
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: commit the following files which have been updated by the Ionic build of the applicatioon and by the semantic release work (package.json,CHANGELOG.mdandios/App/App.xcodeproj/project.pbxproj- Android にビルドすることはありません、)@semantic-release/github: __CAPGO_KEEP_0__ リリースにアセットとしてファイルを付与するCHANGELOG.md: アプリのビルド用にこれらの 2 つのコマンドを使用して準備し、次に Github サーバーにアプリ バンドルを有効にビルドして配布する (@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 と統合することで、XCode Cloud で新しいアプリケーション バイナリのバージョンを簡単にビルドできます (Google Play にデプロイすることはまだしていませんが、そのビルドは似たものです) :
XCode Cloud プロセスを設定して、指定したブランチで変更が発生したときにビルドするようにしました (
- このブランチで、XCode Cloud をファイルが更新されたときにのみビルドするように設定しました。このファイルは、セマンティック リリースによって生成される各バージョン後に更新されます。
production) - 異なるチャンネルでデプロイをシミュレートするために、異なるブランチでビルドをトリガーできます。各 XCode Cloud のビルド設定で、異なるブランチで、環境変数を手動で設定して値を設定します。
CHANGELOG.md__CAPGO_KEEP_0__ - __CAPGO_KEEP_0__
branch.channelset inreleaserc.json(yes, this is a manual duplication) and then, if I wanted to, I could deploy a different AppStore application for each custom customer application deployed from a custom release branch, as mentioned earlier.
XCode Cloud上でCapgoチャンネルでアプリバイナリをビルドする
7. 結論
結論として、14日間の試用期間内に標準的なシーケンスリリースパイプラインにCapgo CapacitorUpdaterを統合できて、非常に嬉しいです。結果は以下のようになっています。
- bundleバージョン番号は、シーケンスリリースによって自動的に生成され、Capgoサーバーと互換性があります
- シーケンスリリースは、Capgoチャンネルを使用してCapgoアプリケーションバンドルを自動的にデプロイします。
- これは、XCode Cloudでアプリバイナリのビルドに適合しています。
次のステップ
このアプリの開発段階にあります。テスト用にTestFlight (iOS)を使用して、すぐにテスターに提供する予定です。Capgoの力に感銘を受け、テスト用に無料版のアプリをAppStoreにデプロイし、Capgoで定期的に更新する予定です。次に、AppStoreに別のレコードで有料版のアプリをデプロイし、Capgoで定期的に更新する予定です。
Capgoの前ビルド検証をより良く追加したいと思います。 bundle upload __CAPGO_KEEP_0__
Ionic + Angular + Capacitor
著者 - Rupert Barrow
22年以上のSalesforceの経験があります。クライアントとユーザー、パートナーと統合者、設計者、開発者、ビジネスアナリスト、コンサルタントとしての経験があります。13年間、フランスのSalesforce SIパートナーであるAltius ServicesのCOOおよびCTOを共同設立および共同運営し、成功したSalesforce SIパートナーを設立しました。Salesforceのソロプレネュアとしての新しい冒険を始める前に、 Rapido Cloud LinkedInで私を見つけることができます。
https://linkedin.com/in/rbarrow Salesforceの提供物をご覧ください。.
https://www.rapido-companion.app および https://www.rapido.cloud 必要な前提条件を私のsemantic release構成に追加しました。 (開発中)
Rapido Cloudがセマンティック リリースを管理する方法から Capgo CapacitorUpdaterに進みましょう。
CapacitorUpdaterを使用している場合 Rapido Cloudがセマンティック リリースを管理する方法から Capgo CapacitorUpdaterに進みましょう。 ライブ アップデートの配信計画を行う場合、__CAPGO_KEEP_0__ Live Updatesに接続してください。 Capgo Live Updatesの製品ワークフローで for the product workflow in Capgo Live Updates, __CAPGO_KEEP_0__ Live Updatesの実装詳細について 機能 __CAPGO_KEEP_0__ Live Updatesの実装詳細について 更新動作 ライブ アップデートの配信計画を行う場合、__CAPGO_KEEP_0__ Live Updatesに接続してください。 実装詳細についてのUpdate Behavior、 Update Types 実装詳細についてのUpdate Types。
