モノレポとマルチレポ　#421

先日AWS SAAを受験して何とか合格することができました！最近AWS関係のアウトプットに集中していましたが、その成果が出て良かったです。

今日は少し概念的な話をまとめてみたいと思います。
リポジトリ管理における、モノレポとマルチレポに関してです。

というのも、最近チームで今後の開発方針を議論する機会があり、これが重要な論点になったため色々と調べました。

モノレポの概要と利点

概要

モノレポは複数のプロジェクトやコンポーネントを一つのリポジトリで管理する開発手法です。共通のライブラリやコードベースを多くのプロジェクトで使用している場合や、各エンジニアの担当範囲が広くフルスタックに開発している場合などにメリットがあります。

利点

全てのコードが一つの場所に収められるため、コードの共有と再利用が容易になります。また、コードの一貫性を維持しやすく、依存関係の管理が簡素化されます。

マルチレポの概要と利点

概要

複数のリポジトリを使用してプロジェクトを管理するアプローチを指します。プロジェクトごとに個別のリポジトリを持ち、それぞれを独立して管理します。プロジェクトが異なるスタックやチームで管理されている場合などにメリットがあります。

SPAなどでフロントエンドとバックエンドが別アプリケーションになっていて、フロントとバックでチームが分かれている場合などもマルチレポが導入されていたりします。

利点

各プロジェクトを独立してバージョン管理し、開発できます。プロジェクトごとに異なるスタックを用いることができますし、モノレポと比べてプロジェクトが身軽になるため日々のデプロイがやりやすくなったりします。

チームでどのような議論になったか

私が所属するチームでは元々モノレポが採用されていました。しかしアプリケーションの機能が増えていくなかで、ソースコードがファットになっていき、マルチレポな管理に変更するべきではないかという意見が出てきました。

そこでモノレポで管理しているプロジェクトを、機能ないしフロントエンドとバックエンドでマルチレポに変更するメリットデメリットを整理することになりました。

以下のようになりました。

メリット

• 各機能を単独でデプロイでき、修正と調整のフローが簡略化される

• 特に新機能はユーザーからのフィードバックを取り込む機会も多く、単独でデプロイできることの恩恵を受けやすい

• 新技術やバージョンアップを導入しやすい

• エンジニアのモチベーションアップに繋がる

デメリット

• フロントエンドとバックエンドを分けた場合、GitHubのブランチが複数に分かれることになり、両方を同時修正する場合のレビュー作業が煩雑になる

• 開発初期の工数がかかる（ユーザー管理や機能間の連携、開発環境構築、CICDの設定などを新たに実装する必要がある）

• 共通するコンポーネントやライブラリの管理が煩雑になる

結論

議論の結果、我々のチームでは引き続きモノレポで管理することになりました。

理由として大きかったのは、1つ目のデメリットで挙げた「レビュー作業が煩雑になる」点です。我々は小さなチームなので担当者がフロントエンドもバックエンドも開発することが多く、分離すると逆に運用コストがアップしてしまう可能性がありました。

また、「各機能単独でのデプロイがしやすい」というマルチレポのメリットも、ブランチ戦略を上手くやれば、小さいチームだからこそモノレポでも再現できそうだ、という話になったことも大きかったです。

検討にあたってモノレポやマルチレポに関するブログ記事をたくさん拝見しましたが、どちらの体制もメリットとデメリットがあり、月並みですが「ケースバイケース（チームの体制やプロダクトの状況による）」ということみたいです。

ここまでお読みいただきありがとうございました！