アールスリーがkintone SIGNPOSTを勝手に解説していくシリーズ！
本文は、kintone SIGNPOSTを読んでいただくとして、kintone SIGNPOSTの各項目についてアールスリーが感じていることや、遭遇したケースなどを紹介します。
STEP.3 3-32「開発環境の用意」
このパターンに書かれているように、本番運用がスタートしているアプリにいきなり手を入れるのはリスクがあります。
- フィールドを消してしまって必要なデータが消えた
- プロセス管理の変更を周知できていなかったので業務が流れなくなった
- フィールドが変わったので操作が変わり現場が混乱した
とくに弊社のようにお客様の依頼に基づいてアプリを開発しているようなSIerの場合、本番アプリにいきなり手を入れてトラブルが起きた場合は笑い事では済まないので慎重を期す必要があります。
こういう場合は、パターンにも書かれているように
- 開発用スペースと本番用スペースをわける
- 開発用ドメインと本番用ドメインをわける
のどちらかになります。いずれにせよ新しい変更は開発用の方で試してOKだよねってなると本番用のアプリに反映するということになります。
アールスリーではkintoneでの開発をはじめた当初からこの方法を取っていたのですが、この方法はめちゃくちゃめんどくさいんです。
開発用アプリで、フィールド10個追加し、アクセス権をもろもろ設定し、プロセス管理もいじったとします。よし、じゃぁこれを本番にも入れようってなると、方法は2つです。
- 本番用アプリに開発用アプリでやった変更と同じ変更を行う
- 開発用アプリをアプリテンプレート化して、本番環境にいれて旧アプリからデータ移行する
後者の方法は、プロセス管理を使っていたら添付ファイルがあったりするとだいぶ面倒です。
弊社が提供しているgusuku Deploitはこの「本番用アプリに開発用アプリでやった変更と同じ変更を行う」を自動的にやってくれるツールです。
gusuku Deploitを使うと、開発用アプリに入れた変更をボタン1つで本番用アプリに反映できます。アールスリーではgusuku Deploitを活用することで開発の安全性と効率が大幅にアップしています。
スペースでわけている場合、ドメインをわけている場合どちらでも対応できますのでぜひ試してみてください。
kintoneでの業務改善・システム開発で困った場合は、弊社で実施している「kintoneよろず相談会」でご相談いただけますので参加してみてください。
