BIダッシュボード開発に開発環境を構築してデプロイも自動化してみた

今日はBIの開発環境の構築とデプロイについて書いていこうと思います。

この記事で述べることのまとめ

1. BIダッシュボード開発だって開発環境でテストしたい。というかする必要ある。
2. hub&spokeモデルを参考に開発環境を構築してみたら快適だった。

なぜ開発環境が必要か

EmbedBIもプロダクトの一部としてユーザーに提供する性質上、プロダクト開発と同じようにSLAの担保や品質保証といった論点にも対応する必要があります。
そういった流れの中で、一般的なSaaSプロダクトと同じような下記のプロセスでEmbedBIダッシュボードの開発ができないか考えました。

1. Lookerの中に開発環境とテスト環境と本番環境を用意する
2. PRのマージと同時に開発環境とテスト環境には自動デプロイする
3. テスト環境でQAを行いテストが通ったチケットだけ本番にデプロイする

hub&spokeモデルとの出会い

当初はLookerのstagingインスタンスの契約を検討しましたが、ユーザー定義ダッシュボード（コード化されていないダッシュボード）のデプロイの難易度が高く、逆にリスクが高まりそうな気配を感じたため導入を渋っていました。
そこでとある2つの記憶を思い出しました。

1. Lookerのユーザー会で、remote_dependencyとconstantの機能の併用で開発環境を作っていると発表されている人がいた気がする。
2. Lookerの導入コンサルの方から hub&spokeモデルという開発方法を教えていただいた記憶がうっすらある。

この2つの記憶を頼りに、下記のような構成ができないかと思いつきました。

実際に構築してみるとけっこう秀逸な作りになっていて、今までテストがしづらかったPDT生成周りのテストができたり、開発環境やテスト環境のデータを用いたQAもかなりやりやすくなりました。

その他苦労話

実はLooker側の仕組みやデプロイフローの構築はさほど大変ではありませんでしたが、本番と同じスキーマのデータをテスト環境や開発環境でBigQueryに整備したり、プロジェクトを跨いだPDTの生成において独自のお作法が必要だったりとクリアするべき課題もたくさんありました。
とはいえEmbedBIを使った分析サービスの開発をここまでシームレスにSaaSプロダクトに接続できている日本企業も弊社だけなのではと少し自慢したい気持ちもあります（笑）

あとがき

LookerをEmbedしてプロダクトを提供する上で、品質管理の部分について行っている工夫についてお話しました。正直書きたいことはまだまだあるのですが、まずは小さくたくさんリリースする方がいいかなと思いいったんここまでとさせていただきます。