パターン実践ガイド

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

はじめに

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

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

想定読者

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

内容

下記 2つの方法におけるメリットや注意点を記載しています。
・同じドメイン内で「開発スペース」を設け、開発アプリ・本番アプリに分けて管理する方法(以下、同ドメイン)
・開発ドメインと本番ドメインに分けて管理する方法(以下、別ドメイン)

同ドメイン

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

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

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

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

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

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

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

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

別ドメイン

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

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

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

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

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

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

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

おわりに

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

まとめ表

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

同ドメイン 別ドメイン
メリット
  • 各種ライセンスの費用が本番ドメインのみとなる。
  • 本番の組織やユーザーを使用して設定・開発が可能。
  • アプリの再利用やスペース間の移動が可能なため、基本機能内で開発した設定をそのままリリースしたり本番アプリに近い環境を作成することが可能。
  • 本番へ導入を検討しているプラグインを先行試用しやすい。
  • 組織やユーザー、ポータル等が本番組織と別のため動作検証の際に本番環境が影響を受けるリスクがない。
  • 別ユーザーでログインし、その人の権限で検証できる。
注意点
  • ポータルの設定やkintone全体カスタマイズの環境分けができないため、これらの動作検証ができない。
  • JavaScirptカスタマイズを適用するには、本番ドメインのkintoneシステム管理権限が必要。
  • 同ドメイン内では同じ(1つの)プラグインIDでプラグインの実装が共通となり、プラグインのバージョンアップ版を開発すると本番アプリに適用されてしまうため、プラグインIDを分ける必要がある。
  • ※既製のプラグインの場合はIDを分けることができないため、同ドメイン内では動作検証できない。
  • ユーザーや組織情報が共通のため、動作検証時に本番のユーザーへ通知や作業者の割り当てが行われるリスクがある。
  • 開発アプリにデータ移行テストなどの目的で大量のデータを取り込む場合、アクセス権設定に関わる変更を行った際にアクセス権の事前評価に時間がかかり、その間同ドメイン内の本番アプリの変更が不可となる。
  • ▼参考:アクセス権の事前評価とアプリの更新時間について
    https://developer.cybozu.io/hc/ja/articles/360025130732
  • 各種ライセンスの費用がかかる。
  • ※本番環境同等の環境を維持する場合は、開発用のドメインを別途契約する必要がある。また、プラグインや連携サービスのライセンスはドメインごとに別の契約となることが多い。
  • アクセス権等の組織やユーザーを用いた設定や動作検証を行う場合、組織やユーザーを本番環境を模して設定する必要がある
想定されるケース(例)
  • 費用をできるだけ抑えたいケース
  • 社内メンバーのみで開発を行なうケース
  • アクセス権やプロセス管理、通知などの設定が複雑で、実運用を想定した動作検証が必要なケース
  • 大量レコード×アクセス権のある開発アプリを作成するケース
  • 開発会社が構築を担当するケース
  • ポータルの設定や全体カスタマイズを行なうケース

選択可能なリリース方法

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

アプリの再利用 所属するスペースの変更 アプリテンプレート 手動設定 デプロイツール
(gusuku Deploitの場合)
選択可否 同ドメイン
※追加変更は不可

※追加変更は不可

※追加変更は不可
別ドメイン × ×
※追加変更は不可
概要
  • 開発アプリを再利用して、本番アプリを作成する方法
  • 開発スペースで作成した開発アプリを、別のスペースに変更し本番運用する方法
  • 開発アプリをテンプレート化してkintoneに登録し、本番運用する方法
  • テンプレートファイルは、ドメインが異なるkintoneでも読み込むことができる
  • アプリの設定を確認しながら、ひとつひとつ手動で設定する方法
  • アプリ開発ソリューションにて開発アプリから本番アプリへ開発内容をリリースする方法
  • アプリのバージョン管理やバージョン間差分の確認が可能
必要な権限
  • アプリの作成権限
  • コピー対象アプリの管理権限
  • アプリの作成権限
  • 移動対象アプリの管理権限
  • 所属スペースの管理者
  • Publicアプリグループの「アプリの作成」権限および「アプリの管理/使用/削除」権限
  • kintone システム管理権限
  • アプリの作成権限
  • テンプレート化対象アプリの管理権限
  • アプリの作成権限
  • アプリの管理権限
  • アプリ作成の作成権限
  • アプリの管理権限
注意点
  • 所属の変更先としてゲストスペースを指定できない
  • 以下のスペースの変更は不可
    自分が参加していない非公開スペース、自分が管理者ではないスペース、「アプリ作成できるユーザーをスペースの管理者に限定する」が有効になっているスペース、ゲストスぺ―ス
  • ▼参考:アプリの所属変更の詳細についてはヘルプを参照してください。
    https://jp.cybozu.help/k/ja/id/040492.html
▼参考:アプリテンプレートの詳細についてはヘルプを参照してください。
https://jp.cybozu.help/k/ja/id/04021.html
  • 手動のためミスが発生するリスクがある
  • 監査ログに一部アプリの設定変更のログが記録されるが、詳細な変更履歴は残らないため、ドキュメント等を用意する必要がある
  • ▼参考:監査ログについてについてはヘルプを参照してください。
    https://jp.cybozu.help/k/ja/admin/other/audit_logs.html
  • 利用するアプリ数によっては費用がかかる
  • ルックアップや関連レコードで相互に連携して いるような構造のアプリの場合は、アプリテンプレート等でアプリを作成しておく必要がある
  • ユーザーや組織に関する設定のリリースは、本番アプリと同一のユーザー・組織・グループが存在することが前提
  • ▼参考:製品に関する詳細な情報は製品ページを参照してください。
    https://deploit.gusuku.io/
引継ぎ可能な
設定について
※詳細は各方法の
ヘルプを参照して
ください。
拡張機能に関する設定
(アプリコード、APIトークン、Webhook、プラグイン設定)
× × - ×
ユーザーや組織、グループに関する設定 ×
※1
-
条件通知 × - ×
アクセス権 × -
プロセス管理 ×
※1
-
アクション ×
※2
- ×
その他設定
(カテゴリー、言語ごとの名称、レコードのタイトル)
- ×

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