開発環境を用意する場合の設計

当ガイドは、「開発環境の用意」パターンとあわせてご利用ください。

kintone アプリの開発において、簡易なアプリであれば「アプリの動作テスト」機能を使った確認でも問題ありませんが、複雑な設定（プロセス管理やアクセス権設定）が入る場合や、JavaScriptカスタマイズ・プラグイン設定を行う場合は、本番アプリとは別で開発アプリを用意し、そこで開発・テストを行う方が安全に運用できます。
ここでは、開発アプリを用意する場合を想定し、「開発アプリを本番環境と同じドメインに用意する方法」と「開発アプリを本番環境とは別のドメインに用意する方法」の違いについて記載します。

（※この記事は2022年8月1日時点のkintoneをもとに執筆しています。）

想定読者

IT部門・kintone開発者の方向け

内容

下記 ２つの方法におけるメリットや注意点を記載しています。

• 同じドメイン内で「開発スペース」を設け、開発アプリ・本番アプリに分けて管理する方法（以下、同ドメイン）
• 開発ドメインと本番ドメインに分けて管理する方法（以下、別ドメイン）

同ドメイン

本番ドメイン内に開発用のスペースを作成し、スペース内のアプリで開発を行います。

同ドメインに開発アプリを用意する際、公開スペースに作成すると、利用者全員の検索に引っかかってしまったり利用者が本番アプリと間違えてしまったりするリスクがあるため、非公開スペースに作成することを推奨します。

作成したアプリを新規リリースする方法としては、アプリを再利用して本番アプリを作成する方法や、開発アプリのアプリテンプレートを読み込み本番アプリを作成する方法、開発スペースで作成したアプリを公開用スペースに移動する方法などがあります。
各方法によって引き継げる設定が異なるため、「おわりに」に記載のまとめ表「選択可能なリリース方法」をご参照ください。

本番運用中アプリの追加変更を行なう場合は手作業で反映するか、もしくはデプロイツール（gusuku Deploitなど）を利用します。
デプロイツールを利用すると、反映作業を自動化できるだけでなく、バージョン管理やバージョン間差分の確認などが可能になります。
gusuku Deploitの詳細は、製品の紹介ページをご参照ください。
▼参考：gusuku Deploit
https://deploit.gusuku.io/

本番ドメインに作成した開発アプリでは、本番の組織やユーザーを使用するため、本番アプリ同等のアクセス権やプロセス管理、通知等の設定を行うことができます。

注意点としては、ポータルの設定やkintone 全体カスタマイズは環境分けができないため、ポータルの変更や全体カスタマイズを行なう場合は、即時に本番運用となり、事前の動作検証を行うことができないという点があります。

すでに利用しているプラグインのバージョンアップを行う際にも注意が必要です。
各プラグインは一意のプラグイン ID が割り当てられています。
同じプラグイン ID を持つプラグインファイルをアップロードすると、自動的に上書きインストールされ、そのプラグインを利用している全アプリに即時適用されます。
したがって、利用中のプラグインのバージョンアップ版を同ドメインで検証する際にはプラグイン ID を分けて開発する必要があります。
なお、既製のプラグインの場合はプラグインIDを分けることができないため、同ドメイン内では事前の動作検証を行うことができません。

また、データ移行テストなどの目的で大量のデータを開発アプリに取り込んでいる場合、アクセス権設定に関わる変更を行った際に、アクセス権の事前評価に時間がかかり、その間はすべてのアプリの設定変更が不可となります。
同ドメインでは本番アプリの操作に影響が発生するため、操作が少ない時間帯を選んで作業をするなど考慮が必要です。
▼参考：アクセス権の事前評価とアプリの更新時間について
https://cybozu.dev/ja/kintone/tips/development/customize/columns/access-permissions-evaluation-app-update/

別ドメイン

本番ドメインとは別に開発用のドメインを用意し、開発ドメインで開発を行います。

開発ドメインで作成したアプリをリリースする場合は、基本機能内ではアプリテンプレートを利用することができます。
ただし、アプリテンプレートでは引き継げない設定があるため、手動設定が発生します。
本番運用中アプリの追加変更を行なう場合は、同ドメインと同様に手作業もしくはデプロイツールを利用します。

本番と開発でドメインを分けると、データを完全に分離することができます。
そのため、運用中のデータに影響を及ぼしてしまうリスクを避けることができます。

ユーザーや組織も別となるため、各ユーザー権限で実際の動きを想定した動作検証が行いやすくなります。
誤って本番ユーザーに通知や作業の割り当てなどをしてしてしまうリスクもありません。

ポータルの設定や kintone 全体カスタマイズについても、事前の動作検証を行いやすくなります。

なお、kintone API を使った開発を目的に利用できる環境としてkintone 開発者ライセンスを提供していますが、kintone 開発者ライセンスには一部制限があるため、ユーザー数やデータ容量等も含め本番同等の設定で開発環境を構築・維持したい場合は、開発用のドメインを別途契約する必要がある場合があります。
▼参考：kintone 開発者ライセンス
https://cybozu.dev/ja/kintone/developer-license/

また、ライセンスがドメイン単位のプラグインや連携サービスを利用する場合は、本番利用とは別に、開発用にそれらを契約する必要があるため費用がかかります。

おわりに

費用面やセキュリティ面、開発時に必要な動作検証の範囲、各方法での選択可能なリリース方法などの観点から、同ドメインと別ドメイン、どちらに開発アプリを用意するのが適しているか検討しましょう。
いずれの方法でも、リリース後はアクセス権や通知などが想定通り設定されているか確認しましょう。

まとめ表

同ドメイン・別ドメインのメリットおよび注意点

選択可能なリリース方法

ここでは、アプリの新規リリースと、本番運用中アプリの追加変更の際の代表的なリリース方法についてまとめています。
表中の「〇」「×」は推奨ではなく、あくまで可否を示すものです。

※1 一部引継ぎ可能のため、ヘルプをご参照ください。
※2 一部引継ぎ不可のため、ヘルプをご参照ください。

更新履歴

2022/8/23　まとめ表＞■選択可能なリリース方法＞デプロイツール（gusuku Deploitの場合）について、引き継ぎ可能な設定「条件通知」「アクション」の項目を修正しました。