2025/05/25 10:49 The Ingredients of a Productive Monorepo
やっほー、ロボ子！モノレポについて話すのじゃ！
博士、こんにちは。モノレポ、興味深いテーマですね。よろしくお願いします。
モノレポって、開発者の生産性向上や組織の一貫性を高めるのに役立つらしいぞ。エンジニアリング・リーダーシップがエンジニアリングの慣習を定義・強化できるのがミソじゃ。
なるほど。異なる組織のエンジニアが同じように動作するコードベースに貢献できる、というのも大きな利点ですね。
そうそう！でも、リポジトリに対する操作は高速じゃないとダメだぞ。変更に対してO(change)である必要があるらしい。
大規模なモノレポだとGitのパフォーマンスが問題になることもあるんですね。MicrosoftやMeta、Googleが独自のソース管理システムを開発しているのも納得です。
Sparse Checkoutや仮想ファイルシステムを使って、リポジトリのサブセットを操作できるようにするってのがポイントじゃな。
生成コードの増加がソース管理の問題を悪化させる、というのも見逃せない点ですね。
ビルドの話も重要じゃ。Bazelは便利だけど複雑だから、単一言語のモノレポを維持して、言語エコシステムのビルドシステムを使うのがオススメだぞ。
ビルドシステムには、効率的なビルドと、変更によって影響を受けるターゲットのリスト生成が求められるんですね。
ターゲットデターミネーターを使って、ビルドグラフを検査するってわけじゃ。
テストも重要ですね。モノレポではテストの数が多いため、テストの失敗を自動的に再試行したり、実行する必要のあるテストのみを実行したりする必要があるんですね。
Flakyテストを隔離することも忘れちゃいかんぞ。
継続的インテグレーション（CI）では、変更の範囲に基づいて必要なビルド成果物を生成し、変更を検証する必要があるんですね。
ターゲットデターミネーターを使って、変更に基づいてトリガーする必要のあるジョブを特定するのじゃ。CIはできるだけ高速に保つのが重要だぞ。
スループット、正確性、テールレイテンシのトレードオフを考慮する必要がある、と。
継続的デリバリーでは、異なるデプロイ可能な成果物が異なるタイミングでデプロイされることを考慮する必要があるぞ。
サービス契約の変更を検証し、意図的な変更でない限り、変更が加えられないようにする必要があるんですね。
デプロイシステムは、モノレポで発生することとは非同期に動作することを理解する必要があるのじゃ。
モノレポは組織の一貫性を高めるための強力なツールであり、エンジニアリング文化や組織標準を強化し、コード共有の文化を構築するのに役立つんですね。
そう！でも、スケールに応じてツールが壊れ始めるから、継続的なプロセスが必要なのじゃ！
勉強になりました！
ところでロボ子、モノレポって、もしかしてモノを盗むレポのことだと思う人、いると思う？
それは…ないと思いますよ、博士。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。