ディプロイAPIの深淵なる世界

この記事はkintone Advent Calendarの14日目として寄稿しています。

gusuku知ってますよね？

kintoneでのシステム開発に欠かせないgusuku知ってますよね？
ご存じないという方は、https://gusuku.io/をご覧ください。

gusukuのことは知っていただいたとして・・・

gusukuの中心機能であるアプリケーション配布機能

gusukuの重要な基本機能である「アプリケーション配布機能」ですが、これは、kintone上で作ったあるアプリの設計を、他のアプリに反映する機能です。

これを使うことで、開発用のアプリで行った変更を、本番用アプリに反映することができます。

「あぁ、ディプロイAPIで設計情報取ってきて、配布先に送ってるんだね」

そう思ったあなた！
正解ですが、それではまだ不足しているのです。
ディプロイAPIにそのまま渡すだけでは困るケースがあります。

ルックアップや関連レコードがある場合

開発用アプリが発展してこうのようにルックアップを含む形になったとします。

そのままディプロイAPIで配布するとこうなります。

これじゃまずいですよね？

gusukuではこのような問題を解決するために、「アプリケーションバンドル」と呼ぶ仕組みを用意しています。
要は、環境間でのアプリの対応関係を管理するものです。

上のようなケースでは、本番用スペースに先に空のアプリBとアプリCを作成しておいて、gusukuにそのアプリを登録して開発用スペースのアプリB、アプリCとひもつけます。

その状態でgusukuで配布すると！

配布処理の中でちゃんとルックアップ先のアプリを本番用のものに切り替えて配布してくれます。

フィールドコードはユニーク？

kintoneの各フィールドには、フィールドコードというものがあります。
フィールドコードは「ユニーク」なものとして定義されています。
ただ、ここでの「ユニーク」の定義に問題があります。
ここでの「ユニーク」は、あくまでも「１つのアプリの一連のフォーム設計情報の中で」という前提がつきます。
gusukuはアプリのバージョン管理ができます。バージョンをまたがってフィールドコードを見たとき、

バージョン間ではフィールドコードはユニークではない

のです。フィールドコードがいつでも変更できてしまうことからわかりますよね？
ある時点でのフィールドコード「name」を持つフィールドが次のバージョンでも同じフィールドである保証がありません。
（内部的にはidを持っているようなのでこれをAPIが返してくれるといいんですけど・・・）
以下のように「prefecture」というフィールドコードを持つ「都道府県」というフィールドがあったとします。

「やっぱ都道府県はプルダウンで選びたい」ということで、これを「ドロップダウン」に変更することになりました。
アプリはこう変わります。

変更前も変更後も、フィールドコードは「prefecture」になっています。

これをgusukuで配布するとエラーになります。
kintoneはフィールドのタイプ変更に対応していないためです。
ただこうしたいケースはよくあるためgusukuの将来のバージョンで対応する予定にしています。

このようにフィールドコードは、バージョンをまたいだ場合、ユニークなキーとして機能しないという問題があるため、gusukuでは様々なロジックを用いてフィールドの同一性を推論してアプリケーションの配布を行っています。

現在はgusukuで対応できていないパターンもすでにいくつか見えてきているため、今後どんどんgusukuに盛り込んで行く予定です。

ディプロイAPIは深淵なる世界なので、自分でスクリプト書いてお手軽にディプロイしようとするとドハマリするので、gusukuをうまく使いたいですね。