耐えられる?gusuku Deploit無き世界

公開日:

更新日:

こんにちは!カスタマインの剣とデプロイットの盾を売る武器屋のすずきです。

エブリサイトは弓かな・・・?

さて、今言ったように弊社は、kintone関連のサービスとして、ノーコードで機能を強化するgusuku Customine(以下カスタマインと呼称)と、アプリのバージョン管理や配布(設定のコピー)ができるgusuku Deploit(以下デプロイットと呼称)を提供しております。

いろんな機能をアプリに付与できて夢の広がるカスタマインの方が目立ちますが、デプロイットも無いと困るんですよね。

普段私はkintoneアプリを作るとき、基本的にカスタマインとデプロイットが両方ある環境で開発することが多いですが、時々デプロイットが無い環境で開発しないといけないこともあります。そんな時にこそ気付くデプロイットの良さについてお話ししたいと思います。

デプロイットってどんなツール?

デプロイットの一番いいところは、アプリ間の設定のコピーが簡単にできることです。これの何がいいかというと、開発用のアプリと本番用のアプリを分けられる、ということです。同じアプリを2つ作っておいて、一方を開発用、一方を本番用とし、開発用アプリで機能をテストした上で、設定を本番用アプリにコピーするという体制が作れます。(厳密にはデプロイットが無くてもその体制は作れますが、手動で設定をコピーするのは大変手間ですし、正確性を保証できないですよね)

また、バージョン管理の機能もあり、アプリを以前の設定にすぐに戻すことができます。

では、デプロイットがなく、開発用アプリと本番用アプリに分かれていなかったら、どう困るのでしょうか?

デプロイットがないとき・・・

大きく影響が出るのは、アプリを作っている最中よりも、アプリの運用が開始してから、修正や機能追加をしようとしたときです。kintoneは基本的にノーコードで、設定を変更しやすいことから、作成したアプリを使ってみて、使い勝手がよくない部分を改善していくことが多いです。

ですが、その際本番運用中のアプリを直接変更する場合、次のようなリスクがあります。

動作が確認されてない設定が本番用アプリにいきなり反映されてしまう

これはカスタマインやJavaScriptで新しく機能を追加する場合だけの話だけでなく、権限やプロセス管理の設定を変えた時も起こることです。動作を確認できていないので、ユーザーが使っている途中で急にエラーが出る、編集したいフィールドが閲覧すらできない、たどりつけないステータスが存在するといったことが急に発生したりします。怖いですね〜。

開発を止められない

また、機能の開発には新しくフィールドを作成した上で、そのフィールドを使った機能の開発をする場合もあります。ですが、機能が完成しないと、中途半端にフィールドだけである状態が続いてしまい、使用者が混乱してしまいます。だから早く機能を完成させないと!と焦ると今度は設定ミスにつながります。

不具合があってもすぐには設定を元に戻せない

本番用アプリの設定を変更していくうえで、原因不明の不具合が出ることもあります。そうなるととりあえず業務が止まらないように、アプリやカスタマイズの設定を、エラーが出る前の状態に戻したくなります。ですが、いろいろ変更した後だと、ここまで何をしたっけ?いつからエラーが出てるんだっけ?どこまで戻せばいいんだっけ?と、戻すのも難しい状況になります。また、戻せたとして、不具合が出なくなったのはいいものの、今度は不具合の原因の調査が困難になります。

デプロイット無しでも何とか安全に開発できない?

一番いいのは開発・修正中のアプリは触らないようにしてもらうことです。でももしアプリを触らないと業務が止まるからそれは出来ないとなった場合は、誰もアプリを触らない休日や深夜の作業になってしまいます。しんどいですね・・・。

デプロイットがあるとき!

つまり、デプロイットがあると・・・

  • 開発用アプリと本番用アプリを分けて作っておき、開発用アプリでテスト済みの設定をまとめて本番用アプリに反映でき、安全に開発を進められる
  • 本番用アプリへの反映は一瞬なので、長い間アプリの使用を停止してもらう必要が無い
  • 不具合があればすぐに以前の設定に戻すことができる

ということですね。あってよかったなぁ・・・。

まだ助かる!

ないとき・・・の話で「分かりみが深い・・・😢」と思ったそこのあなた!今からでもデプロイットを入れられます!

(ただし、カスタマイン以外のJavaScriptによるカスタマイズが入っている場合は、開発用アプリでも本番用アプリでも動くものかどうかはわからないので個別に検討が必要です。)

本番運用済みのアプリをデプロイットに乗せて、開発用アプリと本番用アプリに分ける方法をご紹介します!

1.開発用アプリを作成

運用中の本番用アプリをコピーして作成します。ルックアップや関連レコード一覧で参照しているアプリもまとめてコピーしたほうがいいので、アプリテンプレートスペーステンプレートを使ってコピーするのがいいでしょう。

開発用アプリは本番用アプリと区別できるように、本番用アプリとは別のスペースにおいておくのがおすすめです。アプリ名も、先頭に「(開発)」などとつけて、区別しやすくしておきましょう。

2.デプロイットに登録

デプロイット内で開発環境と本番環境を作成し、開発用アプリと本番用アプリを登録します。

デプロイット実践編1「色々なパターンのプロジェクトや環境の作成方法」の記事に詳しく書かれていますので、そちらもご覧ください。

カスタマインの入っていないアプリの場合はここで作業完了です。

カスタマインの入っているアプリの場合は以下の作業も必要です。

3.開発用アプリでカスタマイズを再設定し、本番用アプリに配布

カスタマインが作成したカスタマイズファイルは、そのアプリでしか動作しないようになっているため、他のアプリに同じカスタマイズファイルを適用しても実行できません。ですので、このままだと開発用アプリではカスタマインによる機能が動かずテストができません。

ですが、デプロイットと紐づけた状態でカスタマイズを作成すると、複数の環境のアプリを同じアプリとして扱い、各環境のアプリに対して有効なカスタマイズファイルになります。

その状態にするために、カスタマインの設定を取り出して再度入れなおすという作業が必要になります。

詳しくは「元カスタマイズ対象アプリと異なるアプリで実行させることは出来ません」というエラーを回避する方法の記事に詳しく書かれていますので、そちらもご覧ください。

まとめ

デプロイットがあれば本番運用中のアプリに対しても安全に開発・修正ができます。また、レコードのバックアップ機能もあるので、設定変更によりレコードのデータが書き換わってしまっても安心です。

後からデプロイットに乗せる方法もご紹介しましたが、実際乗せる作業は少々面倒で、アプリ数が多くなればなるほど、作業が多くなります。

そうなる前に早めのデプロイット!

投稿者プロフィール

アバター画像
すずき
kintoneがメインのエンジニアです。空き時間の半分を合気道に使います。