株式会社リブセンス アルバイト事業部エンジニアの村山です。これを書いている時、mixi2を触ってはぇ〜ってなってます。
普段はマッハバイトというアルバイト求人サイトの開発に携わっており、開発グループというエンジニア全員が所属するグループのグループリーダー（EM）をやっています。
以下の記事でチームのリリース数を可視化する、という取り組みを紹介させてもらいました。
この記事では上記仕組みの課題やその解決方法について書いていきます。 最後まで読んでもらえたら嬉しいです。
課題
以前構築した仕組みで抱えてていた課題は、シンプルにデータの保持期間があるというものです。
以前の仕組みでは、Datadogにデータを送信し、メトリクスとして管理する手段をとっていました。 Datadogはリブセンス全体で使われているためすでに基盤が整っており、スムーズに仕組みを実現できたのですが データを保持する期間が15ヶ月（デフォルト）に設定されているため、1年ちょっと前のものからデータが消えてしまいます。
利用料金にも関わってくるため、この取り組みのために設定を変えるわけにもいきませんでした。 この課題自体は当初からわかっていたことなのですが、個人的な取り組みであることから隙をみて解決方法の構想や実装していくことにしました。
ちなみに、以下は当時提案された解決策の例です。中には脳筋なものもあって面白いですね。
解決手段
結論としてはCloudflare D1、Pagesを使って対応しました。
やらなければいけないことはシンプルに
- データの永続化
- データの可視化
であるため、実現方法は様々ありそうですが
- 無料でサクッと試せる
- せっかくなら使ったことがない技術を用いたい
という理由から採用しました。
合宿で実装
リブセンスのエンジニア組織では定期的に開発合宿を行なっています。 made.livesense.co.jp made.livesense.co.jp
2回の開発合宿で徐々に実装をしていきました。
- D1にリリースの度に情報が保存される
- D1に保存したデータを整形して表示することができる
ということが実現できれば良いだけなので、保存処理は現状のリリースフローに組み込むのが手っ取り早そうでした。
マッハバイトのサービスはほとんどがECSで動いており、リリース処理はGitHubでPRのマージによってキックされるGitHub Actions上で行われています。 その処理に組み込むため、Cloudflare Pagesで作られたD1にリリース情報を登録するAPIをデプロイ処理の最後にGitHub Actionsで実行することでリリース情報をD1に記録しています。
表示については同じくCloudlare Pagesを使いました。
- D1からクエリを叩いてデータを取得する
- Chart.jsを使ってグラフで表示する といったシンプルな方法で実現しています。
比較的手慣れたSQLクエリで取得する手段が取れるので特に困ることはありませんでした。
実際の画面は以下です。 (無邪気に月単位にしているためギチギチ)
最後に
データの永続化、という課題については対応ができました。 EMという立場上、面接、面談の場面に参加することが多く、リリース頻度について聞かれることも多くあります。 実際のデータを用いて候補者様とお話ができるので自分にとっては一定の便利なツールになってくれました。
これからの課題は明確でリリース数だけに限らず、より多くの情報を指標として活用できる状態を作ることです。 Four KeysやSPACEといったフレームワークに沿ってチームの状態を数値化することで振り返り、改善に繋げられるようにしていきます。
最後まで読んでいただきありがとうございました。
