Nx、monorepoの遅いCIをproject graphとcacheで解いた開発基盤の設計

Nxは、元GoogleのJeff CrossとVictor Savkinが2018年に創業したNrwlから始まった。

二人はAngularの開発経験を背景に、チームのrepositoryが大きくなるほどbuild・test・依存関係の調整に時間を奪われる問題へ向き合った。出典

Victor SavkinはNxを「the monorepo platform」と説明し、開発者がcodeを書く時間を増やすためにgraphとcacheを組み合わせた。出典

当初のAngular周辺のtoolingは、やがてTypeScript・JavaScript全体のmonorepoへ広がった。

Nxはproject graphで構造を読み、task pipelineを依存順に実行し、同じtaskの結果をcacheする。

つまり高速化の中心を「速いmachine」ではなく「不要な仕事をしない仕組み」に置いた。出典

次の転機は、localの便利さをCIへ移したことだった。

Nx Cloudのremote cacheとAgentsは、teamの実行結果を共有し、変更されたprojectだけを選んで走らせる。

CIが遅いという抽象的な不満を、task単位の再利用と並列化へ分解した。出典

現在のNxはOSS core、plugins、Nx Console、Nx Cloud、Enterpriseを重ねるplatformになっている。

無料で始められる入口を残しつつ、複数repository、observability、self-hostingが必要な企業には別の価値を提示する。出典

この道のりから見えるのは、developer toolが単機能のCLIで終わらず、teamの意思決定モデルまで扱うときにplatformへ変わるということだ。

NxのPMFは、複数アプリ・libraryを同じrepositoryで運用するengineering teamにある。

課題はbuild/testの重複、依存関係の見えにくさ、CIの長期化だ。

Nxはproject graphとtask orchestrationで構造を可視化し、cacheで再実行を省く。出典

単なるtask runnerではなく、localからCIまで同じモデルで扱える点が導入理由になる。

既存repoへnx@latest initで加えられるため、全面移行を要求しない。出典

技術的なmoatはproject graph、task hash、plugins、長期に蓄積したCI実行データの組み合わせにある。

個別のcache機能は模倣できても、repository構造の理解とdeveloper workflowへの統合は一度導入されるほど強くなる。出典

ネットワーク効果は中程度。

利用者同士の直接ネットワークではなく、OSS plugin、community、既存workspaceの知見が間接的に価値を増やす。

Nx Cloudのremote cacheは同一team内で強く効くが、公開市場全体のnetwork effectではない。出典

主な対象は、複数teamがweb・mobile・libraryをまたいで開発するengineering organization。

特にCIの待ち時間と重複buildが経営課題になった企業に合う。出典

単一の小規模アプリで依存関係が単純な個人開発では、Nxの機能が過剰になり得る。

第一はproject graphを中心にした一貫したmental model。

第二はlocal cacheからNx Cloudのremote cache、Agentsへ段階的に拡張できること。

第三はpluginsとgeneratorsで技術スタック別の摩擦を減らすことだ。出典

OSSのCLIを入口にし、CIの経済性をNx Cloudで回収する構造は、個人開発者からenterpriseまでの導線を作る。出典

monorepo導入はrepositoryの境界設計とチーム習慣の変更を伴うため、Nxを足すだけではarchitectural erosionは止まらない。

cache設定のinputs/outputsを誤ると、速さより再現性の問題が先に出る。出典

またNx Cloudの価値はCI規模に依存する。

小規模repoでは設定・学習コストが節約額を上回る可能性があり、OSS coreと有料cloudの境界も比較検討が必要だ。出典

OSS CLIとdocs、GitHub、pluginsで開発者を獲得し、cacheやdistributed CIが必要になったteamをNx Cloudへ移す。

Hobby free、Team、Enterpriseの段階化は入口を狭めずに収益化する設計だ。出典

enterpriseではcross-repo visibility、CI observability、SSO/SAML、自社運用を差別化にする。

一方、CIコスト削減の定量価値をcase studyとbenchmarkで示す必要がある。出典

主要チャネル: content, community, github, developer_relations, enterprise_sales

カテゴリを「monorepo管理」から「開発サイクル全体の摩擦削減」へ広げたことが示唆的だ。

cache、graph、releaseを同じ設定モデルに置くことで、機能の足し算をworkflowの一貫性に変えた。出典

OSSを無料のdistribution layer、有料cloudを高頻度な痛みの解決 layerと分ける構造は、開発者向けinfraにも応用できる。

日本企業では、事業部ごとに増えたfrontend、backend、shared packageを一つのmonorepoへ整理する際にNxのgraphとboundaryが役立つ可能性がある。出典

ただし組織の所有権とrelease責任を先に決めないと、tool導入が構造問題を隠すだけになる。

まずaffected taskとcacheから小さく検証するのが現実的だ。