ひとつのリポジトリですべてのプロジェクトを管理する

ソフトウェアエンジニアリングの世界では、ここ数年明らかに「分散」ブームが来ている。巨大システムを小さく分割して柔軟にする「マイクロサービス」の方法論や、膨大なビッグデータをクラスタに分散させて効率的に集計する「hadoop」が完全に認知された。そして、いままさに、分散台帳技術（ブロックチェーン）に乗ったビットコインが世間を賑わせまくっている。

「分散」の逆は「中央集権」になるわけだが、きょうび、中央集権的なアーキテクチャは古臭いものと見られがちな風潮すらある。しかし、GoogleやFacebook、Twitter、いくつかの著名OSSはソースコードの管理に中央集権的なアプローチを明確な理由をもって採用している。そのワケを紹介してみる。

ソースコード管理の設計思想

ソースコードの管理を担うシステムはバージョン管理システム(VCS）と呼ばれる。現在、ポピュラーなVCSは分散的な設計のgitで、gitのレポジトリをホストするgithubはソフトウェア開発者の標準サイトになっている。

注) VCSとは？
VCSはソースコード自体や変更点などの履歴を保持する。ソースを特定時点に戻したり差分を確認したりが簡単に行える。また、チームでの作業時では各人がファイルを作ったり既存のファイルを更新/削除するので競合を頻繁におこすのだが、これを効率的に解決する仕組みを提供する。

で、サービスを作るときは用途ごとにgitのリポジトリを作るのが一般的だ。例えば、プロダクトのweb版、iOS版、Android版、特定機能だけ切り出したモジュールa,b,c,d...... 機械学習、解析、テスト用ツール、など際限なく増えていき、気づいたらリポジトリが数十数百に増えている事も珍しくない。が、用途ごとに場所を分けるのは直感的でスモールスタートがしやすく、自然な発想であり、現時点で主流の管理法だ。

集中管理が合理的なケース

GoogleやFacebookなどの超巨大で複雑なコードベースを持つ組織では、大量のリポジトリを作るより、ひとつの巨大リポジトリに集約して集中管理した方がうまくいくと判断し、実際にそうしている。

たとえば、あるAPIの仕様を変更したいと思ったら、そのAPIに依存しているリポジトリを正確に洗い出して一つ一つリポジトリを更新していかないといけない。そのリポジトリの数が数個でもげんなりだが、Googleクラスだとシャレにならない数になり膨大な作業が発生する。集中管理した場合まとめて一気に変更できる。

BabelやReact、Emberのような広く使われるOSSでも大量のパッケージをひとつのレポジトリで管理する集中管理的なアプローチを取っている。コードの統一性や書き方を検査するツールやテストツールを統合的に扱えたり、パッケージをまたがる変更を簡単に出来たり、バグ報告を一つの場所で行えたりといったメリットがある。（Babel公式の説明）

とはいえ、今日広く使われているVCSは基本的に超巨大レポジトリは想定しておらずパフォーマンス問題にぶつかることになる。プロジェクトに応じて専用ツールを作ったりVCSにパッチを当てたりして応急処置をする必要がある。集中管理的レポジトリを扱いやすくするOSSはちょろちょろ出始めており、今後盛り上がっていく可能性があると感じている。

そんなわけで、中央集権型の管理の方がうまくいくこともおおいにあるのだ。

詳しくは以下の解説が詳しいのでチェックして見て欲しい。

Monorepos in the Wild
https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9

Why Google stores billions of lines of code in a single repository
https://dl.acm.org/citation.cfm?id=2854146

Scaling Mercurial at Facebook
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/