gusuku Customineを使って作成したカスタマイズを、別の環境に持っていく方法はいくつかあります。


1つのアプリで完結しているカスタマイズを移行する一番お手軽なのは「カスタマイズのファイルへの書き出し・読み込み方法」でご紹介している、ファイルを使っての移行方法です。


ここではもう少し複雑な状況で、どのようにカスタマイズを配布すればよいか?という方法をご紹介します。 例えば以下のような状況の際にご利用ください。

  • 例えば「開発環境」「本番環境」という環境がある
  • それぞれの環境に複数アプリが存在し、そのアプリ間でレコードを読み書きするようなカスタマイズがある


レコードの読み書きとは、例えばマスタアプリから「全レコードを取得する」を使って「レコードからプルダウンを作成する」を使ってプルダウンを作成していたり、「テーブル行を別アプリのレコードへ書き出す」であるアプリのテーブルを別アプリに書き出したりするカスタマイズが該当します。


このような複数のアプリが関係するカスタマイズの場合、アプリの参照先が環境によって異なるため、カスタマイズのファイルへの書き出し・読み込みだけではなかなか手間がかかりますので、こちらの方法をお試しください。


事前準備 : gusuku Deploitの利用について

Customineでカスタマイズを作成するより先に、まず gusuku Deploit で環境を構築する必要があります。


Customineからgusukuシリーズに触れた方はご存じないかもしれませんが、Deploitはkintoneアプリの配布に特化したサービスで、Customineと連携して動作させることが可能です。Deploitに不慣れなかたは、こちらのチュートリアルを一読しておいてください。


gusuku Customineのアカウントをお持ちのかたは、既にgusukuアカウントをお持ちですので、gusuku Deploitも同じアカウント・組織構成で利用可能です(ちなみにサインイン時には、両サービスに同時にサインインしています)。


Customineと同じく、Deploitにもフリープランがありますので、すぐに利用可能です。ただし、サービスプランを区切る上でのカウントする値が両者若干異なることにご注意ください。

  • Deploitの場合:管理されるアプリ数
  • Customineの場合:カスタマイズを作成した時に利用するアプリスロット数

Deploit側から見た場合、Customineは管理出来るアプリ数が無制限の1プロジェクト、という扱いになります。


事前準備 : Deploitによるプロジェクト・環境の作成

Deploit の画面を開くと、先ほど説明したCustomineプロジェクト(標準で作られたプロジェクト)が見えているかと思います。


「プロジェクト一覧」画面で「新規プロジェクト追加」より新たにプロジェクトを作成し、その中に「開発環境」「本番環境」をそれぞれ作成します。このとき、一番左に頻繁に触ることになる環境(例えば開発環境)、右に行くに従ってあまり触らない環境(例えば本番環境)と言うように作成しておくと便利です。


この理由は2点ありまして、最も大きな理由はCustomineでフィールドを選択する際、暗黙に一番左の環境のアプリを参照するためです。これは、開発環境が一番進んだ環境であろう、という意味でこのような挙動になっています。現時点でこの仕様を変更する手段はありません。 もう一つの理由は、後ほどご説明します。


この後、まず開発環境に雛形となるアプリを作成し(中身は空で構いません)、そのアプリを一旦Deploitに取り込み、それぞれの環境に配布しておきます。

この「雛形を予め配布しておく」ということが重要になります。この操作に関する詳細はこちらの 「kintoneアプリへ登録」する時に警告ダイアログが出る時があります」 にて内容をご確認ください。


カスタマイズの作成

ここまで準備が出来たら、カスタマイズの作成が可能です。


Deploitで管理しているアプリに対してCustomineでカスタマイズを行いたい を参考に、Deploitプロジェクトに登録されている各アプリを選択して、カスタマイズを作成・配布することが出来ます。


このとき、各環境のアプリIDが並んでいることが確認できると思います。同じように、やること「全レコードを取得する」の選択先アプリの選択ダイアログなどでも、環境毎にアプリIDが表示されているのが確認できるかと思います。 先程紹介した「警告ダイアログが出るときがあります」のページで解説していますとおり、このダイアログでアプリIDが歯抜けになっている状態のものは、 環境を移した際に上手く環境毎に動作しませんのでご注意ください。



また、最下段には「アプリIDで直接指定」という行があり、ここでは各環境のアプリIDを直接指定することも出来ます。ここでは、プロジェクトに含まれていないアプリIDなどを直接指定することが出来ます。


これにより、複数のプロジェクトで参照されるマスタアプリ群を別プロジェクトで管理しているようなケースでも、正しくアプリIDを入力することでシームレスにDeploitで配布することが可能になります。


環境の選択 : カスタマイズをkintoneアプリへ登録するとき

先程のDeploitで管理しているアプリに対してCustomineでカスタマイズを行いたい にも記述があるのですが、Deploitプロジェクトに対してカスタマイズを登録する際には、必ず環境を選択するダイアログが表示されるようになります。この部分も通常のカスタマイズ画面等は少し違うところです。


この際、一番上の環境(Deploitでいうと一番左にある環境)がデフォルトで選択されています。これがさきほどご説明した、「一番左に頻繁に触ることになる環境があったほうが良い」もう1つの理由になります。「kintoneアプリへ登録」は頻繁に押すボタンになりますので、出来る限りストレス無く実行できるように、環境の順序に気をつけていただければと思います。


環境が選択できるということは、直接本番環境などへカスタマイズを登録できるということを意味しています。この機能については、実際の運用手順やを考慮に入れて、状況に応じて利用してください。


Deploitで配布する場合には、「開発環境への登録」→「アプリ取り込み」→「配布」と手間が増えるのですが、その分バージョン管理などの恩恵を受けることが出来ます。Customineで直接各環境に配布してしまうと、問題が合った時にロールバックも簡単ではなくなるので、ご注意ください。


スロット数のカウントについて

この手順に沿って、Customineで作成したカスタマイズ入りのアプリを、複数環境に配布した場合のアプリスロット数の消費は、1アプリごと常に1になります(マトリックスの1行で1アプリスロット消費されるイメージです)。 Deploitでは、複数環境に配布されるアプリは1つの同一アプリとみなされるためです。


これは、全く同じアプリを複数環境に配布する際には、アプリスロット数の消費を削減できる大きなメリットになります。


まとめ

こちらの手順にしたがって、上手く環境を分けたカスタマイズの配布をご利用いただければと思います。


もし何かご質問などありましたら、お気軽にチャットサポートまでお問い合わせいただければ幸いです!