こんにちは！株式会社ACSHU の kintone 案件を担当している者です。
サイボウズデイズ kintone hack 〜SHOW+CASE Unlimited〜 「kintone で挑んだ大規模システム刷新」で登壇をさせていただきました。
こんな感じで一見 kintone に見えないレベルまでガチガチにカスタマイズをし、基幹システムとして実際に運用している実績を発表したチームです。
本投稿の背景・目的
本イベントに参加する中で、サイボウズ社員の方々や登壇者の方々から「ここまで作り込みをしているところは見たことがない！いったいどうやったのか？」とたくさんの反響をいただきました。
私が本戦に出場した動機としても、ここまで作り込みしている現場はどれくらいあるのだろうか？と思ったのがきっかけです。
しかしながら、サイボウズデイズのイベントでは様々な立場の方が視聴されることを考慮した都合でバックエンド側を語ることができませんでした。
そこで、ここでは本戦で語ることができなかった裏側の部分をすこし共有をさせていただければと思います。
本投稿が、kintoneで業務基幹システムを構築を検討している方々の参考になれば幸いです。😄
そもそも "大規模" ってどれくらい？
当方のプロジェクトではカスタマイズJSのコードだけで約15万ステップ近く書かれており、開発メンバも一時は10名弱の規模で体制をとって開発をしていました。それ以外にも kintone 単体では難しい部分を補うためのAPIを独自に開発しているので、全体としては相応のコード量が稼働しております。
大規模システム開発に向けたビルド・デプロイの仕組みを作る
こうした kintone での大規模開発においても一般的な開発と同様、開発環境、ステージング環境、本番環境といった環境管理を行う必要性が出てきます。
なお、kintone 標準でも「アプリの動作テスト」という機能があります。これはアプリ単体で完結するものであれば問題ありませんが、アプリを横断的に連携する規模になるとこれを採用することできず、独自に仕組みを構築をしていく必要があります。
当方のプロジェクトでは環境管理およびそのデプロイ管理を以下の２つに分けて構築をしています。
- アプリ定義のデプロイ管理
- カスタマイズJSのデプロイ管理
それぞれの構築方法をお伝えします。
今回ご説明する構成のイメージ
アプリ定義のデプロイ管理
アプリ定義の環境管理とは何かというと、同じアプリ定義を開発、ステージング、本番として定義して３面運用することです。
アプリ定義にはフォーム定義や一覧(VIEW)定義がありますが、これを手動で各環境反映して運用するのは当然無理があります。
そこで、ginue という有志のライブラリを利用します。
非常に使いやすく、アプリの環境管理をするうえで当方のプロジェクトでは欠かせないものになっています。これがなくては大規模開発ができなかったと言っても過言ではありません。
こちらを利用することで、コマンドでアプリ定義を環境間で同期することができるようになります。
当方のプロジェクトでは、クラウドにサーバを立ててJenkinsとginueを組み合わせてデプロイの仕組みを構築しています。
JenkinsのJOBイメージ
画像のパラメタの例では、開発環境の定義をステージング環境に同期させる条件をセットしています。
内部では ginue pull や ginue push のコマンドが実行されています。
カスタマイズJSのデプロイ管理
今度はアプリ定義の上で稼働するカスタマイズJSの環境管理についてご説明をします。
前提として、javascriptのパッケージングは webpack を採用しています。
webpack をすることで1つのアプリにつき、1つのJSファイルで運用できるようにします。
パッケージングしたJSファイルについては、以下のように環境ごとにデプロイ方法を分けています。
| 対象環境 | デプロイ方式 |
|---|---|
| 開発環境（ローカル） | VS Code Live Server + webpack |
| ステージング環境 | ginue + customize-uploader + Jenkins |
| 本番環境 | 同上 |
-
ローカル環境ではすぐに動作結果を確認したいため、
--watchを使いながら開発を行っています。詳細はこちらの Live Server & webpack の記事に相当するものとなります。 -
ステージング・本番環境は customize-uploader とginue、Jenkinsを組み合わせて独自のデプロイジョブを構築しています。
具体的には customize-uploader のINPUTとなる manifest.json を以下のように記述しておき、Jenkinsから実行するスクリプトでアプリIDを対象の環境のアプリIDに差し替えるようにしています。
{
"app":"$app_id", # スクリプトで差し替え app_id は .ginuerc.js から判別させる
"scope":"ALL",
"desktop":{
"js":[
"dist/app_customize.js", # webpack で生成されたJSファイルパス
],
"css":[
]
},
"mobile":{
"js":[],
"css":[]
}
}
JenkinsのJOBイメージ
最後に
簡単ではありますが以上となります。大規模開発に挑むためのビルドプロセス基盤の構成をご紹介させていただきました。
実際にはここでは紹介しきれない様々な工夫もして事故やトラブルが少なくなるような運用をしています。
もはやここまでやるなら最初から kintone じゃなくても良いのでは？と思う方もいらっしゃるかと思いますが、それはそのとおりだと思います。（笑）
とはいえ、ここまで kintone が市場で活用されている中で同じような課題や悩みを持たれている方もいらっしゃるのではないでしょうか。そうした方々への後押しになれば幸いです。
株式会社ACSHU では本件に関するコンサルを無償で対応させていただきます。何かあればお問い合わせフォームをご活用ください。