そうそう、私もそのビルドチームで働いてたかも！多くのユーザーにとって、モノレポの開発環境が特にローカルかリモートかよりも再現性が重要だと思う。リモートの開発サーバーで定期的にイメージを取得する方が確かにやりやすいよね。

この記事で触れられていないことの一つは、ほとんどの開発がデータセンターで動いている開発サーバー（大体50～100コアくらい）で行われていたことだ。私も多くの小さなチームでこれをやってきたよ。エンジニアが開発中に「ローカルに考える」のをやめさせるのはかなり難しい。現代のハードウェアのコストや密度を考えると、開発チームのためにどこかにラックを見つけるのは理にかなってるよね。開発、ステージング、テスト、必要なツールを動かすためのボックスをいくつか作るのは簡単だし、成長する余地もある。インフラに近くて、本番環境に似ていると、モノレポの中のコードがすごく違って見えてくる。 > 大規模なビルドシステムを管理するには、そのシステム自体に取り組むチームが必要になる。これが多くの小さなチームがモノレポに移行するのを妨げているんだ。あなたの10～20人のチームは、GoogleやFB、MSには決してなれない。大規模なビルドシステムの問題は起きない。すべてを維持するのは、20人のチームで非常に複雑な製品がある場合に誰かのパートタイムの仕事になるかもしれないけど、それでも厳しいかも。

ほとんどのモノレポは、GoogleやUber、他のテックジャイアンツのリポジトリと同じサイズにはならないってことは覚えておく価値があるよ。毎日新しいサービスを導入する会社もあれば、サービスの数が安定している会社もある。もし会社が100のサービスを持っているなら、VCSのスケール問題は起きないし、LSPはノートパソコンのメモリに全コードベースのタグを収められるし、CIで全てのテストを実行するのもほぼ問題ない。要するに、すべての会社がGoogleの規模になるわけじゃないし、なるべきでもない。

大きなモノレポの会社で元ICだったけど、ポリレポよりモノレポの方が好きだった。これは「THE」モノレポで、会社のサービスグラフやコールグラフ、オーナーシップグラフなどがすごく明確に理解できた。クリスタルクリアで、鮮やかに。ポリレポは部族的な知識みたいなもので、どこに何があるか分からないし、探すこともできない。各チームがそれぞれのやり方でやってるから、新しいコードを引き継ぐのは呪いみたい。コード考古学は、隠された難解な書物の図書館での根本原因分析の冒険みたい。ポリレポはDiscordやSlackのチャンネルに閉じ込められたメッセージや知識みたいで、保持ポリシーが悪い。すべてが暗い隅で萎縮していく。モノレポが数百万のコストなら、ポリレポも別の形で同じくらいかかると思う。モノレポは巨大なメガファウナの大陸。大きなリソース、単一栄養。ポリレポは千の種が生きたり死んだりしていて、繁栄するものもあれば、知られることのないものもあり、大半は完全に暗闇の中。

うちの会社は言語スタックごとにモノレポに移行してるんだ。まあ、悪くない妥協だと思う。

今の職場では、バックエンドが約11個のGitリポに分かれてて、1つの機能が4〜5個のマージリクエストに分かれちゃってて、すごく面倒なんだ。これからモノレポを導入して、全部まとめることを検討する予定なんだけど、リポをまとめられない場合、モノレポ以外の選択肢は何になるんだろう？

あなたの前提は、組織が最初からどちらかに進むことを望んでいなくて、技術的な選択によって後から押し出されるということ？たいていの場合、哲学的な決定（より共有された部分か、より良い分離か）は、リポジトリの扱いを決める前にされていると思う。もし組織が途中で方向を変えたとしても、コードの扱いは根本的にリポジトリの構造を切り替えなくても適応できる。多くの組織はマルチレポだけど、エンジニアはほとんどすべてのコードにアクセスできるし、モノレポチームも自分たちのやっていることを強く隔離することができる。異なるCIルールやデプロイ管理を持つこともできるんだ。

ポリレポの設定で起こることについて、楽観的な見方だね。一般的な代替案（おそらくこっちの方が多いと思う）は、共通エリアに変更が加えられるけど、下流のリポジトリには反映されないってこと。そうなると、みんな異なるバージョンの共通リポに固定されちゃって、数年も古くなると更新が大変になるんだよね。

たくさんの変更が一度に入るから、共通エリアに触れるものは壊れる可能性がすごく高くなる。そのため、単一の「フィーチャー」を提供するための労力が急増する。モノレポの特定の変更が非常に中心的に埋め込まれていて、原子的に行うためには信じられないほどの労力が必要な場合（モノレポを持つ利点）、それでも複数の段階的な変更に分けることができる（「数週間にわたっていくつかのPRを調整する必要があり、内部の政治も絡むけど、それは専用のビルドチームにいない異なる開発者の間で分けられることもある」）。だから、モノレポではマルチリポで説明したのと同じ利点を享受できるし、モノレポのおかげで段階的な変更の展開をより良く把握できるんだ。

共有を目的としたライブラリを作るときは、ほんとに一瞬立ち止まってAPIについて考えないとダメだよ。理想的にはAPIは変わらないべきで、もし変わるなら大規模な変更を計画しておくか、新しい関数を使って古いのを非推奨にするべきだね。便利なコードの一部をコピー＆ペーストすることに何も問題はないと思うし、すべてが依存するライブラリである必要はないよ。小さいものなら特にね。

この世代の開発者たちの間で、断片化と原子主義への推進がすごく強いね。マイクロサービスや小さなリポジトリがたくさんあって、「モノリス」を恐れて何でも分けちゃう obsession。彼らがやってるのは、組織の問題を将来の技術的な問題に変えてしまう複雑さの塊を作ってるだけで、同時に自分たちが構築しているソフトウェアシステムの内部依存関係を認識していない。幸い、今の職場はそんな感じじゃないけど、前の職場はそうだった。protobufスキーマファイルのフィールドを更新するような簡単なことに無駄な時間を費やしてたのには信じられなかったよ。

まだ四半期ごとのリリースをしてるところがあるんだね。それを解決する方がモノレポより重要な気がする。

ここでの疑問は、なぜ2人の開発者でマイクロサービスパターンとK8sを使ってるのかってことだよね。そのパターンはそんな小規模な運用には向いてなくて、余計な複雑さを増やすだけだし。1.5人のエンジニアがいる時に、どれを選んでも本当に重要なの？その規模では、両方のエンジニアがビルドプロセスをしっかり理解してるから、頭の中で全部把握できるし。私もその規模ではリポを全く使わなかったし、Dropboxにリポを保存したり、VCSやSVNを使ったりしても、全然問題なかったよ。成功に何もプラスになってないと思う。ちなみに、開発者が自分のノートパソコンでリポを立ち上げるのは今でも普通だし、2人の開発者でK8sを使うような無駄なことをしてない多くの開発ショップでは特にね。実際、キャリアの初めには、10人くらいの開発者と一緒に古いMSのやつで働いてたけど、ファイルをロックしないと他の人が使えなかったんだ。ファイルをチェックアウトして変更できるようにしてたけど（git checkoutとは全然違う）、そうしないと自分のドライブでは読み取り専用だった。ビルドは手動でパラメータを指定して実行しなきゃいけない大きなVBスクリプトだったけど、それでもちゃんと動いてたよ。SVNに移行した時も、古いシステムの方が良かったって文句があったけど、ファイルをロック解除してもらうために走り回らなきゃいけなかったのが馬鹿らしかった。特に、数日間オフィスにいない開発コンサルタントがいたから、ファイルを解除してもらうために管理権限を持ってるおじいさんに頼まなきゃいけなかったんだ（実際はそんなに年取ってなかったし、髭もなかったけど）。

約1.5人のフルタイムエンジニアの小さなチーム そうだね、1.5人のFTEならリポは1つだけでいいと思う。Bazelの経験はすごく悪かったけど、完全に避けるべきとは思わない。超大規模なマルチチームプロジェクトでは価値があるかもしれないけど、2人未満のFTEには過剰すぎる気がする。Kind（とTiltかも？）を使えば、Bazelなしでも必要なことはできると思う。 > 「このツールレイヤーを作ったから、リポ内でgoやkubectlを実行すると、Bazel自体がビルドして提供してくれる。これで、みんなが常に同じツールのバージョンを使えるし、ローカルインストールを維持する必要もない。」 Goはgo.modでそれをやってくれてるし、kubectlもGoプログラムだから、同じように実現できるよ。 > 「元GoogleのSREがチームにいるのは重要だった」 元Googleの人の給料を考えると、他に何人チームメンバーを雇えるかな。Bazelのメンテナンス費用が今後も価値があるといいな、心からそう願ってるよ。

私もあなたと似たような状況で、Bazelに全力投球してるおかげでかなりのメリットを感じてるよ。

「私たちはこのツールレイヤーを作ったから、リポジトリ内でgoやkubectlを実行すると、それがBazelによってビルドされて提供されるんだ。」 これのおかげで、みんなが常に同じツールのバージョンを使えるし、ローカルのインストールを管理する必要もない。今はbazel runを実行しなきゃいけないけど、あなたの解決策の方がずっと良さそうだね。あなたのはどうやって動いてるの？

大きなモノレポで働いたことはあまりないけど、あなたのコメントはすごく興味深い。HEAD（あるいは実際にはコミットSHA）を指し示す能力は、モノレポを使わないことの良さの一つだと思うことがあるんだ。

これって、めっちゃ断片化を生むだけだよね。複数のチームが複数のバージョンに依存し始めたら、もう終わりだよ。複数のバージョンを維持しなきゃいけなくなって、それぞれのクセやバグに悩まされることになる。健康的なモノレポのためには、1つのバージョンルールが一番大事だと思う。