Monorepo:バンドワゴンを飛ばす価値はありますか?

今日の傾向は、物事を分割し、薄くすることです.我々は、マイクロサービスの出現を目撃した.
この傾向に対して、いくつかの企業やプロジェクトは、同じGITリポジトリの下に複数のアプリケーション/ライブラリを置くことを決めた.我々はこのアーキテクチャコンセプトをmonorepo(またはモノリポジトリ)と呼びます.

私は、現在、2年の間monmonepoを維持していて、維持していました.ここに私の考えがあります.
コンテキスト:私が働いているmonorepo ~ 40 NPMパッケージ、大部分はスタンドアロンVue.jsアプリ.すべてのそれらの小さなアプリケーションは、大きなアプリケーションの一部です.主なものが維持するのが難しくなったので、我々は小さなものに我々の大きいアプリを分割することに決めました.また、我々は、このmonorepo(フルタイムでない)に取り組んでいる~ 15の開発者です.

長所

🤝 チームワーク

貢献
あなたが既にコードを持っているとき、貢献はより簡単です.あなたはrepoを検索する必要はありません、それをクローンし、事前にインストールします.
システム全体のより良い概要
あなたは既にすべてのソースコードを持っています.それで、あなたはrepo URLを見つける必要はありません、それをクローンしてください.普通の古いCtrl + Fは十分です.
大きなリファクタリングを好む:
あなたが他のどこで使われる1つのパッケージで何かを変えたいと言いましょう.あなたは1コミット内のすべてのパッケージを更新することができます!
未使用のコードを信頼して削除します.
どのように何度もコードを削除したいが、コードがどこか他の場所で使用されていたかどうかわからなかったので、あなたはいなかった?Monorepoでは、このコードが使用されているかどうかを確認するすべてのrepoを通過する必要はありません.それは非常に便利です.
真実の単一の源:
私が働いているプロジェクトは、メインブランチのために非常に奇妙な名前を持っていました.この名前を別のものに変更したとき、いくつかのリポジトリが更新されました.Monorepoでは、一度だけこの情報を見つける必要があります.

👨‍👩‍👧 依存

ハードドライブの空き容量は少ない:
JavaScript生態系に精通しているなら、おそらくnode_module フォルダはinsanely heavy . 私たちは30のアプリ/パッケージを持っていたとき、それは私たちのハードドライブ上で12 GBを取るために使用.はい、12 GB!Vueのような依存関係がありました.JSが30回インストールされました.幸いなことに、いくつかのツール(スレッドのような)は、ワークスペースが有効になったときに冗長な依存関係をシンボリックリンクします.この機能のおかげで、.

注:NPM 7.0は現在ワークスペースをサポートしています.しかし、それはまだ初期段階です.重要なコマンドare not supported yet .
クロスパッケージホットリロード
いくつかのツールが自動的にローカルの依存関係をシンボリックリンクします.つまり、package - aがpackage - bで使用されている場合、package - aで動作し、package - bでのライブ結果を見ることができます.
新しいパッケージの追加は簡単です.
私たちのために、すべてのパッケージはpackages フォルダ.新しいパッケージを追加することは非常に簡単です:パラメータの連続的な統合/パッケージマネージャ資格情報を必要としません.すべてが既にそこにあります.

短所

🛠 GIT &コードホスティングプラットフォーム

権限
GITLAB/GITHUB/etcに対してread/write権限を設定すると、通常はREPO全体のためです.
💡 ヒント:あなたはまた、CODEOWNERS file 特定の所有権規則を定義する.

# .gitlab/CODEOWNERS
packages/app-1 @user1
packages/app-2 @user2

上の例で、User 2がAMP - 1を変更するためにマージ要求を開くなら、User 1はそれを承認しなければなりません.
Gitログは読めません.
マージ要求が「そのまま」とマージされた場合、git log すぐに解読できなくなるので、使用できません.
💡 ヒント:使用することができますconventional commit パッケージの名前を括弧で括ります.それで、1つの古いコミットを取得したいなら、それは簡単になります.

# will list all feature added in package-B
git log --all --grep="feat(package-B):"

# or:
git log --all path/to/package-b

Gitログは使用できなくなります.
多くのコミット/リビングブランチ/タグを持っている場合、それはあなたが格納されている多くのGitオブジェクトを持つことを意味します.Gitは、おそらく特定のファイルの履歴を得るのに苦労するでしょう.
あなたの長命の分岐を忘れてください
主な枝が真実の唯一の源であるならば、あなたはAを持つことができませんnext 枝.特定の環境でのみ利用可能な機能を持っている場合は、フィーチャーフラグを使用することをお勧めします.
リポジトリが特大となります.
The .git あなたのmonorepo根のフォルダは、数GBに達するかもしれません.
💡 ヒント:いくつかのスペースを保存する場合は

# truncate the history
git clone --depth 1 <repo-url> 

# 1. clone an empty repo with no history 
# 2. pull the desired package
git clone \
  --depth 1 \
  --no-checkout \
  --filter=blob:none \
  <repo-url>
git checkout main -- packages/package-a

注意:もっと学ぶpartial cloning ._

🤖 連続積分( CI )

それが壊れているとき、誰でもです!
If the main ブランチはあなたの継続的な統合によって赤いマークされ、誰もが影響を受けています.この問題はじゅうたんの下に置くことはできない.それは直接対処する必要があります.
連続積分ジレンマ
コードベースがmutualizedされるならば、あなたはより多くのコードを持ちます.そして、より多くのコードは、テストのような仕事のための連続統合(CI)のためのより多くの仕事を意味します.
CIを扱うとき、時間と信頼性は問題の核心です.一方で、あなたはそれが可能な限り高速であるが、一方で、それは信頼できるようにしたい.つまり、私のCiが私に緑の光を与えるとき、私は私の仕事を合併する自信があります.
それはいくつかの時間を得るために分析パッケージの数を減らすために誘惑することができます.しかし、連続的な統合は「クロスリポジトリ」回帰を見つけることができないので興味を失います.
全体のコードベース
選択パッケージ
影響を受けるパッケージ
ビルド/リント/テスト速度
🐌 スロー
🚀 ファースト
🚗 中
スポットクロスパッケージ回帰?
✅ はい
❌ なし
✅ はい
簡単にセットアップするには?
😀 はい
😀 はい
😟 なし
番目のオプションは、私の意見では、最も実行可能です.しかし、手動で行う必要があります.番目のオプションはフィルタを使用することができます.「重要な」ラベルのパッケージは第1の戦略を使用します、そして、残りは第2の戦略を使います.
💡 ヒント

あなたのCIパイプラインが十分に良いし、並列タスクを持っている場合は、フェイル高速オプションを有効にすることを忘れないでください.

私は、CIを短絡するために特定のラベルを加えることを勧めます.readmeでtypoを変更するように、不要なコマンドを実行する必要はありません.(つまり、プルリクエストに"NORIGN CI "のラベルがある場合、ビルドは起動されません)

🤝 チームワーク

隠れた変化
一部のreposは時々より敏感です.それは大きなインパクトでコードの小さな部分を追加するのは簡単です.それが間違っているならば、それは問題でありえます.
コードの量は脅迫的です.
私が最初にggsbyのソースコードを“git引き”.JS、私は90のパッケージの完全な歴史を引っ張った.一見して、圧倒された.それは完全なリポジトリ(すべての歴史を持つクローン)に年齢を私にとったので.また、コードの量が大きかったので!
CodeBaseの10 %で動作する場合は、おそらく残りの90 %を気にしないでください.

結論

全体的に、monorepoは良いことだと思います.

私たちの場合、それは私たちの生活を容易にします.すべてのパッケージは、同じ大きなアプリケーションの一部であり、同じ言語で書かれています.彼らは同じアプリケーションの一部であるため、彼らは“互いの間の通信”.また、我々はそれに取り組んでいる人間のサイズのチームです.
そして、いつものように、私に、または下記のコメントで手を伸ばす自由!😊
もともと公開maxpou.fr .