モノレポが流行っているらしい

Monorepo(モノレポ)とは、アプリケーションやマイクロサービスの全コードを単一のリポジトリ (普通は Git) に保存するパターン

• マイクロサービスアーキテクチャの普及につれて、コードを多数のリポジトリに分割する (ポリレポ) チームが増えてきた
• 各マイクロサービスの開発チームはそれぞれ独立しており、それぞれの課題に合ったツールとプログラミング言語を使用する
• チームが 1 つだけでありその規模が小さければ、マイクロサービスを迅速に実装し、担当者が別々にデプロイを行なうことで、ソフトウェア開発のスピードを大きく高められる
• マイクロサービスの開発では、ポリレポが当然の選択肢に思える
• しかし、本当にそうだろうか？モノレポにはメリットが多い

• モノレポには次のようなメリットがある
  • 見やすい: 全てのマイクロサービスのコードを閲覧可能。バグ発生時も正確な原因箇所を特定できる。
  • コードを共有できる: ポリレポだとコードが重複する。 リポジトリを単一化し、共通モデル、共有ライブラリ、ヘルパーコードをすべてまとめておけば、マイクロサービスが多くてもこれらを使いまわせる。
  • コラボレーションがしやすい: モノレポなら、チーム間に障壁やサイロが生じることがないので、連携性の高いマイクロサービスを設計、メンテナンスしやすくなる。
  • 標準化が容易: モノレポは、ポリレポに比べてチーム間でのコードやツールの標準化が簡単。
  • 状況を把握しやすい: モノレポでは、コード全体をひと目で把握できる。 ポリレポに比べて、リポジトリ全体の状態の確認、全ブランチの調査、変更の追跡が大幅に簡単になる。
  • リリースを管理しやすい: モノレポなら、システム全体をデプロイする方法がわからなくなることはない。 ビルドとデプロイのパイプラインを自動化すれば、一部のチームだけがデプロイ方法を知っているという状況も避けられる。
  • リファクタリングが容易: モノレポでは、すべてのマイクロサービスに直接アクセスできるため、コードをリファクタリングしやすい。

• モノレポには次のようなデメリットがある
  • 共通のコードを変更すると、数多くのアプリケーションコンポーネントに影響が及ぶ
  • ソースの競合によりマージしにくい場合がある
  • デプロイプロセスが複雑化する可能性があり、ソース管理システムのスケーリングも必要
• とはいえ、状況さえ整っていれば、こうしたデメリットよりもモノレポを導入するメリットが上回る

• マイクロサービスのコンテナ化
• 自動化したCI/CD パイプラインの導入

によってモノレポのデメリットを解消できる

やけにCICDに対する信頼感が高い記事だなと思ったら、CIツールの会社の記事だった…

• ポリレポには以下のデメリットがあった
  • 多くの開発者が存在すら知らないリポジトリが多数発生
  • リポジトリ単位で環境構築や修正、PRやリポジトリ横断での結合テストなどに対する運用コスト
  • ナレッジの分散による組織全体の開発速度や柔軟性が低下
  • オーナーシップやメンテナンスも曖昧
  • 一部のメンバーに負荷が偏ったり、会社として担保したい統制が取れない状態が発生

• 単一のリポジトリにまとまっているからといって、ビルドやデプロイなどが毎回実行されるわけではありません。
• 通常はソースコード変更や、その変更に依存するソースコードやテストのみを実行するため、リポジトリが単一になっているからといって必ず遅くなるものでも無いです。

うちのプロジェクト毎回ビルドしているような…その変更に依存するソースコードやテストのみを実行するってどうやるんだろ