マルチレポからモノレポへの移行を経験して感じたこと
プロダクト開発初期においては、いわゆるマルチレポ構成で、API と Web、API ドキュメント等で、レポジトリを分割していました。
しかし、様々な問題を感じ、マルチレポからモノレポへの移行作業を行いました。
マルチレポの選定理由
権限の分離
GitHub Teams を活用していたため、それぞれの権限を分ける目的でした。
例えば、Web 担当のエンジニアにとって、API は対象外なので、Web に Write 権限、API に Read 権限を与えるという運用でした。
これは、実際に開発を担当するのが、業務委託のエンジニアだったこともありました。
インハウスのエンジニアであれば、むしろ Web 担当であっても API に関心を持ってほしいので、モノレポの方が良かったです。
無駄な merge の発生を防ぐ
常に PR を最新に保つには、main ブランチから PR のブランチにマージする必要がありました。
その時、関係の無い API 側の変更が main に取り込まれたタイミングで、Web 関係の PR を更新することに違和感を感じていました。
マルチレポの限界
同一の各種設定やファイルがシェアできない問題
GitHub Actions では、actionlint 等は内容も全く同じですが、それぞれのレポジトリに作成する必要がありました。
また、Branch Protection Rules も変更がある度に適宜両方を更新する必要があり、Required Status checks を逐一確認して追加していくのも大変でした。
PR Templates 等も内容は同じでも、状況に応じて変更が適宜発生するため、同じ変更をそれぞれのレポジトリを移動して適用していく必要がありました。
これらは、モノレポであれば解決できていたなと感じていた問題点でした。
お互いの進捗把握
デイリースクラムで確認はしていても、どうしても自分の担当しているレポジトリしか頻繁に確認しないため、リアルタイムでの状況把握ができていない状態でした。
API の実装がどれくらい進んでいるのか、一旦モックで進めなければいけないのか、等の確認が必要でした。
モノレポであれば、PR 欄は逐次確認するため、状況の共有がスムーズに行えていました。
モノレポへの移行
開発が行われていない、土日をフルに使って全てのレポジトリを移行しました。
その時、コミット履歴が消えてしまうのは悲しいので、以下の記事を参考にしながら、消えてしまわないように細心の注意を払いながら移行作業をしました。
ただ単に移行はできないので、共通のファイルは削除したり、ディレクトリ階層が 1 つ落ちるため、全ての GitHub Actions に対して working-directory を付ける作業をしました。
Production へのデプロイを行う Actions もあったので、ミスしていないか何度もチェックしました。
移行完了後は、マルチレポで感じていた問題点を全て解決できました。
モノレポで感じた問題点
Environments の異常発生
Web の Production や、API ドキュメント、管理画面に、etc. と、モノレポにした影響で Environments が大量発生しました。
元々マルチレポでは、Environments 欄を見て管理をしていましたが、そこには最大 3 つしか表示されないため、諦めて commit 一覧ページから CI のステータスを確認するしかなくなりました。
GitHub Actions の異常発生
ls .github/workflows | wc -l
32
なるべく纏めようとはしたのですが、やっぱりどうしても異常発生しました。
対象が同じでも、発火条件が違うとファイルを分ける必要があるのが、ファイル数を増やした一因だと思います。
変更がある場合は、ひたすら見逃しが無いか何度もチェックすることで解決していました。
GitHub Actions の無駄な実行
移行初期は、バックエンドのみの変更に対して、フロントエンドの Cypress テストが走るというカオスな状態でした。
以下の記事の方法で解決はしましたが、上記のファイル数に適用していくのは大変でした。
最後に
今回のプロダクトでは使用していませんでしたが、モノレポであれば、各種定義を同一言語の実装間で共有できる点も良いと思っていました。
あまりやりすぎると良くないですが、マイクロサービスの共通部分切り出しもモノレポであればスムーズにできます。
そういった将来性を鑑みると、色々と問題点はありましたが、やっぱり同一プロジェクトのものはモノレポにする方が見通しが良く、移行して良かったと思っています。
逆に ESLint 設定のように、会社全体として統一して、プロジェクトを跨ぐものやプロジェクトに依存しないものは、別のレポジトリとして管理する方が綺麗かと思います。
会社での運用の好みが色々とあると思うので、最終的には自分達に合った運用方法を選択することをおすすめします。
こちらの記事が参考になれば幸いです。
Discussion