Monorepo: tek depoda birçok proje

Kısaca: Birbiriyle ilişkili birkaç program ve kütüphane, birçok ayrı depo yerine tek bir Git deposunda birlikte yaşar.

Biraz daha ayrıntılı: Bir monorepo’da ön yüz, arka uç, paylaşılan kütüphaneler ve araçlar tek bir depoyu paylaşır, ancak genellikle kendi klasörleri ve paketleri vardır. Google veya Meta gibi büyük şirketler bu şekilde çalışır ve JavaScript dünyasında pnpm workspaces, Nx veya Turborepo gibi araçlarla yaygındır. Karşıtı, her projenin kendi deposu olduğu polyrepo’dur.

Ayrıntılı

Yapı

my-company/
  apps/
    web/
    api/
  packages/
    ui/            paylaşılan yapı taşları
    config/
  package.json     çalışma alanı yapılandırması

Paketler birbirlerine yerel bağımlılıklarla başvurur ve tek bir komut her şeyi kurar.

Avantajlar

• Atomik değişiklikler: bir kütüphanedeki ve tüm kullanıcılarındaki bir değişiklik tek bir commit ve çekme isteğinde yapılabilir.
• Ortak araçlar: tek bir lint ve test düzeni, tek bir sürümleme stratejisi.
• Paket yayımlamadan kolay kod paylaşımı.
• Genel bakış: her şey tek yerde, aranması kolay.

Dezavantajlar ve çareler

Depo büyür ve naif ardışık düzenler her değişiklikte her şeyi yeniden derler. Modern araçlar yalnızca etkilenenleri derler (bağımlılık grafı) ve ekip genelinde de paylaşılan bir derleme önbelleği kullanır. Erişim hakları proje başına daha zor ayrılır; kod sahibi dosyaları (CODEOWNERS) yardımcı olur. Çok büyük depolar seyrek checkout gibi Git özelliklerine ihtiyaç duyar.

Karar vermek

Birbiriyle ilişkili parçalardan oluşan küçük bir ekip için monorepo çoğunlukla daha rahattır. Projeler bağımsızsa, ayrı ekipler ve sürüm döngüleriyle, polyrepo daha mantıklı olabilir. Monorepo bir monolitle aynı şey değildir: hizmetler orada da ayrı derlenip teslim edilebilir.

Ayrıca bak: Git, CI/CD ardışık düzeni, SemVer, Modüler monolit