kintoen のカスタマイズを受託して仕事していると、最終的には開発環境で構築したものを本番環境(お客様の環境)へ移行する必要があると思います。
この時、作っているものが複数アプリから成るものだったりすると、 REST API とかで別アプリのレコードを読み書きすることも多くあると思います。そうすると、 API 呼び出し時の アプリ ID をどうするか?というのが必ず問題になると思います。
webpack を導入していないのなら、本番環境にアップロードした個々のカスタマイズファイル中のアプリIDを JSEdit for kintone プラグインとかを使って書き換えるということで対応できると思います。が、webpackで一つのファイルにバンドルされていると、IDの書き換えもなかなか難しそうです。
ということで、いい方法はないものか調べてみると、先人が考えてくれていたようで、いい方法が見つかりました。
とうことで、この方法を自分でも試してみます。
アプリ ID を1ファイルにまとめる
webpack を使うことを前提してるので、まずは、下記を参考にして、アプリ ID を1ファイルにまとめて定義します。
目指せ!JavaScript カスタマイズ中級者(1)〜webpack 編〜 - cybozu developer network
アプリ ID を使う側では、 import して利用します。
ドメインおよびスペースに応じて、アプリIDを取得できるようにする
さきほどの記事の通り、開発ドメインとお客様ドメインをキーにしたオブジェクトを定義します。
AppIds.js
/** * アプリケーションID を定義するモジュール */ // 開発環境 const APP_ID_DEV = { app1: 1, app2: 2, ・・・ }; // ステージング環境 const APP_ID_STAGE = { app1: 11, app2: 12, ・・・ }; // 本番環境 const APP_ID_PROD = { app1: 101, app2: 102, ・・・ }; /** * 複数環境におけるアプリ ID のオブジェクト */ export const environments = { "開発環境のドメイン.cybozu.com": [APP_ID_DEV], "お客様環境のドメイン.cybozu.com": [APP_ID_STAGE, APP_ID_PROD], }; /** * あるドメインのスペース毎におけるアプリ ID 群 */ const spaces = environments[location.hostname]; /** * アプリ ID * * ドメインおよびスペースに対応したアプリ ID のオブジェクトを返す */ export const APP_ID = spaces.find((elm) => Object.values(elm).some((appId) => appId === kintone.app.getId()));
使う側では、
import {KintoneRestAPIClient} from "@kintone/rest-api-client"; import * as AppIDs from "./AppIDs.js"; import * as AppConst from "./AppConst.js"; export class SampleManager { #APP_ID = AppIDs.APP_ID.app1; #appId; #limit; #client; // Kintone REST API Client constructor() { this.#appId = this.#APP_ID; this.#limit = 100; this.#client = new KintoneRestAPIClient(); } ・・・
のような感じで使えます。これは便利ですね。
初回リリース時はどうする?
この方法を使えば、開発環境も本番環境も同じカスタマイズファイルをアップロードしてやるだけで、ちゃんと動くことになります。
でも、一番最初のリリースの時はどうするのがいいんでしょうか?特に、カスタマイズファイル以外のアプリ自体(フォームなど)の定義はどうすればいいんでしょうかね?
改めて調べるとちゃんと解決策がいくつかありました。以下で紹介しておきます。
アプリテンプレートおよびスペーステンプレート
kintone には、既存のアプリを元にテンプレートを作成して、それをひな型として別のアプリを作成するという『アプリテンプレート』機能があります。このテンプレートは、別の環境(別のドメインも可)へ持っていくこともできます。
ということで、これを使えば、別ドメインにアプリをコピーすることもできます。
同様のことが、アプリ単位ではなく、スペース単位でもできるとのことです(スペーステンプレート)。これを使えば、スペース内に作成した複数のアプリを一括して、移行することができます。いいですねー。
ただ、アプリテンプレートもスペーステンプレートも、新たにアプリを作るので、アプリ ID が新たに割り振られることになります。
なので、実際には、
- 開発完了
- スペーステンプレート(アプリテンプレート)を作成
- お客様ドメインで、テンプレートによりアプリを作成
- アプリ ID 定義ファイルを修正
- お客さんのドメインの環境に、カスタマイズファイルをアップロード
という流れになります。
まあ、お客様ドメインにアプリ(群)を作成する最初の一回のみですが、ちょっと面倒ですね。
デプロイツールを使う
別の方法もあります。
業務になると、 アプリ数が多いときもあるので、 gusuku deploit というサービスを利用して、デプロイ作業を簡単にする方法もとれます。
この場合の流れは、
- 開発完了
- お客様ドメインで、受け皿になるアプリを作成(テンプレートを利用してもOK)
- アプリ ID 定義ファイルを修正
- 開発環境に、カスタマイズファイルをアップロード
- gusuku deploit により開発環境をお客様ドメイン内の環境にコピー
となります。お客様ドメインで受け皿になるアプリは、アプリが存在していて、アプリ ID がわかればいいだけなので、中身は空っぽでも OK です(gusuku deploit でコピーすることで中身が変更されます)。
結構便利だった gusuku deploit なんですが、 2023 年 6 月からプランが改訂されて、フリープランの次のプランの値段が大幅に上がってしまいました。
引用元 アールスリー、kintoneアプリのバージョン管理・配布を行うgusuku Deploitのプランおよび価格を改定 |アールスリーインスティテュート
上記表からわかるように、以前は、フリープランの次が、スタンダードプランで、バックアップオプションを入れなければ年額1万円超で使えたのですが、これに該当するプランが廃止になってしまいました。そのため、フリープランの次が、プラン200(旧、プロフェッショナルプラン)になり、年額20万円になってしまいました。
このため、私のような個人開発者が気軽に使うには、なかなかハードルが高いサービスになってしまいました。
幸い、プラン改訂前から利用していたユーザーはそのまま使えそうなので、しばらくはこちらを利用するにしても、案件が増えてきたら、どうするか悩ましいところです。
REST API
もう一つの方法も考えることができます。
こちらは実際には試してないのですが、下記を参考にして kintone の REST API を駆使すれば、自前でデプロイツールを作ることもできそうです。
- デプロイ API を使ってコマンドラインでアプリをコピーしてみよう - cybozu developer network
- アプリの作成と設定変更の流れ - cybozu developer network
- kintone のアプリをまとめてコピーする
さすがに、簡単には手が出せませんが、gusuku deploit がアプリ数の制限に達しそうになった場合に備えて、ぼちぼちと検討してみようかなと思います。
まとめ
kintone って開発は楽しいんですが、デプロイとかで手作業が多くなる印象があります。まあ、 kintone の主なターゲットはライトなカスタマイズを狙っていそうなので、そもそも致し方ないとは思うんですがね。
ちなみに、直近であったやつについては、 gusuku deploit +スペーステンプレート、を使って乗り切りました。 ご参考までに。