はじめに
株式会社ユーザベース スピーダ事業 Product Teamの阿久津です。
私が開発に関わっているスピーダ 経済情報リサーチは多くのマイクロサービスによって様々な機能が提供されています。
そして、その多くのマイクロサービスはモノレポで管理されています。
今回新しくマイクロサービスを作ることになったのでその際に試したことを書き残そうと思います。
試したこと
今回試したことは単純に一つのマイクロサービスに関わる登場人物を一つのディレクトリにまとめるです。
所謂コロケーション *1というやつです。
実際どのように変えたのかですが、
既存のマイクロサービスに関わる主な登場人物の配置は基本的に下記のようになっています。
sugoi-monorepo
├── e2e
│ ├── sugoi-api-e2e
│ └── sugoi-web-e2e
├── environments
│ ├── pipeline
│ │ ├── sugoi-api-pipeline
│ │ └── sugoi-web-pipeline
│ ├── sugoi-api
│ └── sugoi-web
├── sugoi-api
│ └── src
└── sugoi-web
└── src
それを下記のようにしました。
sugoi-monorepo
├── sugoi-api
│ ├── app
│ │ └── src
│ ├── e2e
│ ├── environments
│ └── pipeline
└── sugoi-web
├── app
│ └── src
├── e2e
├── environments
└── pipeline
モチベーション
きっかけはいくつかあるのですが、最終的なモチベーションとしては大きく２つかなと思っています。
1. 必要に応じていくつかのディレクトリをエディタで開くことが煩わしかった
2. 既存のディレクトリに配置する恩恵が感じられなかった
1については、
私達はKotlinでe2eテストを書いているのでintelliJでe2eディレクトリを開きます。
そのときに依存するAPIが増えるとenvironments下の必要なディレクトリをvscodeで開くなどをします。
さらにアプリケーションに手を加えるためにvscodeまたはintelliJを別に開いたりします。
そして私達は基本開発するときは常にペアプロをしているため、オフラインで一つのマシンにキーボードをつないでいればさほど問題ではない場合もありますが、
オンラインでのペアプロとなるとLive ShareやCode With Me などで共同編集できる状態を作るのでそのたびにセッションをつなぎ直すということはコストがかかります。
それぐらいいいじゃないかと言われればそうかもしれませんが、私はそれがなんとなく嫌だなと思ったわけです。
（なんとなく嫌というのを深掘ると私はブラウザのタブを開きっぱなしにするのも嫌で用が済んだら極力閉じたいのでその延長なのかもなと思っています。）
2に関しては、開発する中での経験やいろんな人と話してみての推測からですが、
e2eやenvironmentsの下には他のプロジェクトが参照するユーティリティプロジェクトやツールが存在しているので近くにある方が都合がよい構造でしたが
今は色々と改善されていてそのツール群に依存するプロジェクトは少ないのであまり恩恵はなさそうだなと思ったわけです。
上記を踏まえて最悪mvして既存の配置に戻せばよいのでやってみるかということで新しいプロジェクトで試してみました。
試してみた感想
実際に試して得られたものとしては下記がありました。
よかったこと
- ほとんどの場合intelliJだけ共有できれば開発ができる。多くてもintelliJとvscodeをそれぞれshareすれば開発に必要なものが揃う
- 初期段階で色々と準備が必要なときにエディタやIDEを開き直したりしなくてもいいのはストレスがないので良い
- 仮にリプレイスの対象になったときに最終的に完全にリプレイスが完了したときに掃除が楽
- sparse checkoutを有効活用すれば、pipelineの高速化などにつながる可能性が多少ある
のびしろ
- 既存の配置に慣れているメンバーからすると混乱することがある
- 絶対にやったほうがいいと強く推すメリットはこれといって特にない
さいごに
個人的には開発するときに関係するものは極力近くにあってほしいなと思っているので、
チームメンバーから反対意見がでなければ導入してもう少し色々検証していきたいなと思いました。
最後まで読んでいただきありがとうございました。
