モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。
会社で分かれるレポジトリ
フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。
そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居なくて、コードの規模も凄く小さいのに。
酷い時にはフロントはバックエンドのコードが読めないとか変更出来ないとか、そんな事態になったりする事もある。 そこまで行かなくてもレポジトリは触らせてくれないくらいは良くある。
ログや履歴が見れないデメリットは説明するまでも無い。 あとはAPIの変更が無駄に難しくなるし、お互いソースが読めないと継ぎ目の所ですぐバグったりするし、バグを追うのが無駄に大変だったり。
しかもレポジトリが分かれていると、手動でコードを持っていってマージするみたいなのをえんえんやる人が発生したりもする。 お前6人しか居ないプロジェクトで一人それかよっ！（この物語はフィクションです）。
レポジトリを一つにしようという意思
この手の開発でレポジトリが分かれるのは、実に些細な理由である事が多い。 ソースコードを見せない理由も実際はほとんど無くて、ちゃんとその辺を話し合って決める人が居なかったので念の為（？）見せない事にしたとか、その程度。 もともと寄せ集めで開発するケースでは、力関係的にプロジェクトを立ち上げる会社がだいたい凄く強いので、ちゃんとその会社が望めばレポジトリは一つでソースコードも全員が見える状態に出来る。 でも、プロジェクトを立ち上げる会社が開発以外の所に強みを持つ会社だと、そうした方針について強い意思を持っていなかったりする。そうすると些細な理由でなんとなくレポジトリが分かれてしまうのを防げない。
分かれる理由が些細であっても分かれた影響はでかい。 レポジトリが一つかどうかとかソースにアクセス出来るとか、開発効率には大きな影響を与える。 少し話し合いを頑張れば劇的に改善出来るのだから、頑張った方がいいのは間違いない。 だけれども些細な障害を乗り越えてレポジトリを一つにする為には確固とした意思を必要とする。 そうした強い意思を持つためにはしっかりとした「あるべき姿」が見えている必要があると思う。 でもフリーランスになってTech企業の外に出てみると、 そうした姿は意外と知られていないと感じた。
自分はどこでそうした「あるべき姿」を学んだのだろう？ 自分の場合を思うと、自分はモノレポ的な経験から学んだ気がする。
自分のモノレポ的な体験
自分の経験は厳密な意味ではモノレポでは無くて、その辺が今回皆さまに見解を聞きたいと思った所でもある。 でもまぁまぁモノレポと言っても良い経験はあるので、その辺の話を。
自分が一番モノレポに近い環境だったのは、MSでOfficeのチームだった時。 OfficeはOffice全体で一つのレポジトリだった。会社にはOfficeの他に（雑にいえば）WindowsとVisualStudioがあって、それらは別のレポジトリだった。厳密な意味ではモノレポでは無い。 （10年くらい前の話で、モノレポという概念もまだ無かったと思うし。） ただ、Officeの中にはWordやExcelなどの他にも、OutlookとかSharePointのようなサーバーサイドなどだいぶ他とは毛色の違う物も混じっていて、 それらが一つのレポジトリで開発されているのは当時それなりに衝撃だった。
ローカルに無い状態で全部syncすると３日くらい掛かるとかいう世界だったので、それなりに巨大なコードベースでもあった。 ローカルにある状態でもsyncはめっちゃ時間掛かるので、家に帰る前にsyncする風習になっていた。syncのコマンドを実行すると最初にネットワークなどのエラーが無い事を確認して、ここからは時間がかかるという所まで行ったら「もう家に帰ってもいいですよ」とビープ音が鳴ったりする。
当時の環境がモノレポ的だと自分が思う事の一つに、独自のツールが充実していた事が挙げられる。 例えばレポジトリの検索ツールがあって、 ローカルにコードが無いプロジェクトも、コマンドラインからローカルにあるかのように一括検索が出来た。 新しいAPIの使い方や言語機能の使い方はとりあえずレポジトリを検索してみて他のプロジェクトを参考にしたりしていた。
また依存が他のチームにまで及ぶ場合、自分が他のチームまで含めて全部を変える事が出来た。 もちろんレビューとかは必要だけれど、皆が同じレポジトリを使っているので、 チームごとの別々のツリーに入れなくてはいけないみたいな作業は無かった。 関係無いチームも全部コードにアクセス出来るのはモノレポ的だと思う所だ。
あれだけのレポジトリのでかさを維持する為には、凄まじいエンジニアリングコストが掛かっていた。 そんな膨大なコストというのはまさにモノレポの欠点でもあるのだけど、 プロジェクトのいろいろな事を決める人たちがそれだけのコストを払ってでも維持するだけのメリットがあると思ってくれていた訳だ。
実際欠点もあるにせよ、当時あの規模の開発を行う為にはレポジトリを一つにするしか無かったと思う。 ツリーが別だったら、あっという間に置いていかれてしまって永遠にマージが終わらないに違いない。 実際ツリーが一つでもcommitは凄い大変だったし。
モノレポってどうなんでしょう？
冒頭に述べたようなプロジェクトだと、 何故か自分がレポジトリやブランチマネージメントの基本的な事をレクチャーしたりする事もあるのだけど、 この手の事は実体験が無いとうまく伝えるのは意外と難しい。
一般的には、モノレポの功罪とかって、 最近だとGoogleとかFacebookのモノレポなどの議論で学ぶ事だと思う。 でもその辺の話が好きなのはその辺の経験をすでに持っている人ばかりで、 意外とその辺の常識が共有されているのは、狭い世界だけだった。 そんな事にフリーランスになって初めて気づいたりした。
そうした時にFacebookとかGoogleのモノレポの記事にリンクを貼ってもいいのだけど、 記事は記事なのでやっぱり一面的というか、説得力が微妙。 もうちょっと実体験に基づいた話がある方が良い。
さらに、Googleのモノレポはおそらく当時のOfficeよりは遥かにでかくなっているはずなので、 ヤバさもずっと上になっているはずだ。 そうした経験があると自分とは違った見解もありそうで、自分個人としても聞いてみたい気がした。
という事で他の人にも聞いてみたい。とりあえず検索で世界最大規模のモノレポの仕事の経験がありつつ小さなオープンソースの仕事での非モノレポの経験もあって、 さらにChromeとAndroidという見るからにやばそうなコードと深いつながりのあるChrome OSの仕事をしているjmukにまず聞いてみたい。 モノレポってどうなんですか？