Monorepo vs Polyrepo: Bağlantı Mı, Depo Sayısı Mı?

Monorepo vs Polyrepo: Gerçek Soru Depo Sayısı Değil, Bağlantıdır

Monorepo ve polyrepo tartışması, mühendislik ekibiniz derleme zamanlarından daha hızlı büyüdüğü her seferinde tekrar ortaya çıkar. Yazılımda az sayıda kalıcı tartışma vardır:çoğu zaman hangi tool çalışacağını zaman gösterir. Ama bu tartışma farklı: mimari kararın ekibinizi üç yıl ileriye götürdüğü şekli belirleme potansiyeli vardır.

Kısa cevap: ekipler kodunu düzenli olarak paylaştığında ve ortak bir platformda değişiklikleri koordine ettiğinde monorepo kazanır; ekipler gerçekten bağımsız olduğunda ve birbirlerini beklemeden dağıtım yaptığında polyrepo kazanır. Arada kalan her şey, hizmetlerinizin ne kadar sıkı bağlı olduğuna ve ne kadar koordinasyon yüküne katlanmaya istekli olduğunuza bağlıdır. Bu yazı gerçek ticaretleri, hangi seçeneğe işaret eden işaretleri ve karar almak için pratik bir çerçeveyi açıklar.

Gerçek Soru: Depo Sayısı Değil, Bağlantı Derecesi

Çoğu monorepo vs polyrepo tartışması yanlış bir sorudan başlar. Kaç depoyunuz olduğu sorun değildir. Sorun, ekiplerinizin birlikte hareket etmesi gerekip gerekmediğidir.

Ekip A'nın değişiklikleri rutin olarak Ekip B'nin aynı yayın döngüsünde bir şeyler güncellemesini gerektiriyorsa, sıkı bir bağlantınız vardır. Bunun için tek bir depo hemen hemen her zaman temiz bir çözümdür. Ekip A Salı yayın yaparken Ekip B Perşembe bağımsız yayın yapıyorsa, sisteminizin farklı bölümlerine dokunuyorsa ve birbirlerini asla beklemiyor ise, ayrı depolar mantıklı bir seçimdir.

En kötü senaryo: hala birlikte yayınlanması gereken kod için iki ayrı depo. Bir monoreponun tüm koordinasyon maliyetini getirirsiniz ama faydalarını kaybedersiniz. Ekipleriniz depo A'da ve depo B'de eşzamanlı PR'lar açmaya başlarlar, umut edersiniz ki her ikisi de aynı anda CI'ı geçer. Bu model, erken polyrepo'yu seçen ama sonradan hizmetlerini daha bağımsız hale getiren kuruluşlarda sık görülür.

Herhangi bir karar vermeden önce yapılacak ilk şey basit bir bağımlılık haritası çizmektir. Yönettiğiniz her hizmeti ve paketi listeleyin, sonra biribirlerine bağlı olduğu yerlere oklar çizin. Oklar yoğun bir küme oluşturursa, o küme tek bir depoda olmalıdır. Bu, mimarinin tüm karmaşıklığını yakalamaması gerekir:sadece hangilerinin sürümlenmiş birlikte sürülmesi gerektiğini görmeniz yeterli.

Neden Google, Meta ve Microsoft Ölçekte Monorepo Seçti

Google, çoğu kodunu 80 TB veriyi aşan ve 2 milyardan fazla kod satırı içeren tek bir depoda tutar. Meta ve Microsoft'ta ana ürünleri için aynı modeli kullanır. Bu, büyük şirketlerin karmaşıklığı sevdiğinden değildir:yüzlerce depo arasında bağımlılıkları senkronize tutmanın ölçekte tam bir mühendislik sorunu haline gelmesinden kaynaklanır.

Paylaşılan bir kütüphanede tek bir API değişikliği, 40 farklı depoda eşgüdümlü güncellemeler gerektirebilir. Monorepo'da bu tek bir pull request, tek bir inceleme, tek bir merge ve hata olursa tek bir rollback işlemidir. Polyrepo'da üç ayrı PR, üç ayrı inceleme döngüsü açarsınız, hizmetlerinizin uyumsuz sürümleri çalıştığı bir zaman penceresini yönetirsiniz. En berbat ihtimalde, ikinci PR birleştirilir ama üçüncüsü başarısız olur ve kısmi dağıtım yaparsınız.

Sourcegraph tarafından yapılan araştırmaya göre, 50+ geliştirici olan şirketlerin %63'ü artık en azından kod tabanının bir bölümü için monorepo kullanıyor. Üç yıl öncesiyle karşılaştırıldığında keskin bir artış. Bu, şirketlerin bu yolu seçtikten sonra bundan pişman olmadığını ve büyüme sırasında da bunu sürdürdüğünü gösteriyor.

En somut fayda: atomik commit'ler. API'de değişiklik yapılırken ön uç ve arka uçta da güncelleme gerekiyorsa, monorepo üç değişikliği de tek bir PR'da indirebilir, hepsini beraber test edebilir, hata olursa hepsini beraber geri çekebilir. Polyrepo'da üç PR, üç inceleme, hata riski yüksek.

Bir mühendislik ekibi, ön uç paketlerini Nx monorepo'ya geçtikten sonra ayda birkaç dağıtımdan haftada 40+ uygulamaya çıkma raporu verdi. Daha önce aylar süren Angular güncellemeleri, ekiplerin diğer görevlerini durdurmadan halledebileceği rutin işlere dönüştü. Biscuit bu tür başarı hikayelerini çok sever.

Polyrepo'nun Gizli Koordinasyon Maliyeti

Polyrepo'nun ciddi avantajları vardır. Her ekip kendi CI/CD boru hattını, kendi yayın zamanlamasını, kendi erişim kontrollerini yönetir. Güvenlik ve uyum ekipleri bunu tercih eder: koda erişim depo başına adlandırılmış kişilere sınırlandırılabilir; düzenli endüstrilerde bu önemli. Açık kaynak bileşenleri, dahili kodu açmadan halka açık depolarda daha temiz duruş gösterir.

Gerçekten bağımsız olan ekipler için bu avantajlar gerçektir. Kendi zamanlamasında çalışan ve ana ürünle hiçbir kod paylaşmayan bir veri boru hattı ekibi, büyük bir monorepo içinde olmasından pek fayda görmez. Bu ekip depo güvenliğinden de yarar sağlar: sadece adında bağlantısı olan kişiler erişim alır.

Ama polyrepo kuruluşları sessizce biriktirir hale gelir: bağımlılık sürümleme arası depoların kendi disiplini haline gelir. Paylaşılan bir yardımcı kütüphane bazı depolarda eski kalırken diğerlerinde güncel kalır. Hangi paket sürümünün hangi depo sürümüyle çalıştığını bilmek için uyumluluk matrisleri tutmanız gerekir. Bu, hiç kimse istemiyor ama kültür haline gelen bir sorundur.

Bilmeye değer bir metrik: monorepo'larda ortalama PR döngü süresi 19 saat civarında, polyrepo'larda yaklaşık 2 saat. Monorepo'lardaki PR'lar daha fazla yüzeye dokunduğu için daha büyük olur ve incelemesi daha uzun sürer. Ama polyrepo'da tek bir özellik eklemek için üç depo arasında üç PR açıp birleştirmeniz gerekiyorsa, toplam döngü süresi monorepo'yu aşabilir:üstüne üstlük kısmi birleştirmeler hizmetlerinizi tutarsız durumlar bırakabilir.

Ekipler sık rastlayan sorun: "bağımsızlık için ayrı depolarla başladık, ama şimdi her yayın dört yerde PR açmamızı gerektiriyor." Bir doktor gibi malımızı döneceğiz: bu noktada her iki dünyanın kötü tarafları alıyorsunuz.

Derleme Zamanları 2024'te Artık Belirleyici Değil

Monorepo'ya karşı klasik itiraz derleme zamanıydı. Depo 200 pakete sahipse ve dosya değiştirirseniz gerçekten tüm 200'ü yeniden mi derlersiniz?

Bu argüman 2022-2024 arasında etkisini kaybetti (yığında ne olduğu önemli olmakla birlikte).

Modern derleme araçları içeriğe duyarlı önbelleğe alır. Yalnızca değiştirilen şeyleri yeniden derler, girdileri aynı olan her şeyi atlar. "Payments" paketinde yapılan değişiklik, "design-system"de hiçbir şey değişmediyse onu yeniden derlemez. GitHub Actions kullanıcılara 10 GB ücretsiz önbellek alanı sunuyor; bu kalırsa uzak önbellek çözümüne ödeme yapabilirsiniz. Büyük kuruluşlar sık kez bunu yapar ve geri ödemesi genellikle az zamanda kendini bulur.

Turborepo çoğu JavaScript ve TypeScript ekibini 20 pakete kadar sorunsuz karşılar. Yapılandırma tek bir turbo.json dosyası, Vercel'de ücretsiz uzak önbelleğe alma veya kendi barındırdığınız çözümler, öğrenme eğrisi bir gün içinde üretken olmaya yetecek kadar düşük. Dokümantasyon da açık ve pratiktir.

20 paketi aşınca veya derleme birden fazla dili kapsarsa, Nx'in daha yapılandırılmış yaklaşımı öğrenme eğrisine rağmen avantajlı hale gelir. Kod üretimi, otomatik CI dağıtımı ve depo büyüdükçe değerli olacak nitelikli bağımlılık takibi ekler. Nx, monorepo'yu ölçeklemek için tasarlanmıştır.

Binlerce paket arasında birden fazla dili çalıştıran çok büyük kuruluşlar için Bazel (Google'ın açık kaynak derleme sistemi) bu ölçek için tasarlanmış tek araçtır. Kurulum maliyeti yüksek ve hemen hemen her zaman adanmış platform mühendisliği ekibi gerektirir. Eğer Google'da çalışıyor veya aynı ölçekte iseniz, bu konuyu kendi başınıza çözmek zorundadır.

Ekibiniz İçin Sorunu Çözen Dört Soru

Evrensel doğru cevap yok, ama güvenilir bir çerçeve var. Bu dört soruya cevap verdiğinizde, seçim genellikle kendini belli eder.

1. Ekipleriniz sıklıkla kod paylaşıyor mu? Evet ise:paylaşılan tasarım sistemi, paylaşılan API istemci kütüphanesi, paylaşılan kimlik doğrulama mantığı:monorepo hemen hemen her zaman daha iyi seçimdir. Paylaşılan kütüphaneyi depolar arasında senkronize tutmak sabit disiplin gerektirir ve sürüp gider. En iyi şekilde, birisinin görevi olur. En kötü şekilde, hiç kimse sorumlu değil.

2. Ekipleriniz bağımsız dağıtım yapıyor mu? Ekip A Salı ve Ekip B Perşembe hiçbir koordinasyon gerekmeden dağıtım yapıyorsa, polyrepo yerini alır. Bir hizmetin dağıtılması başka hizmetin eşzamanlı dağıtımını gerektiriyorsa, bu bağlantı maliyeti denkleme katılır. Koordinasyon konuşmasının sonunda, birisi soracak: "Neden ayrı depolarda bunu bu kadar zor yapıyoruz?"

3. Bu kod tabanında kaç mühendis çalışıyor? 20'den az, depo yapısı düşündüğünüzden daha az önemlidir. Herkes her şeyi bilir. 50'yi aşınca polyrepo'nun koordinasyon maliyetleri açıkça görülür. 200'ü aşınca, ekipler ürün ve teknolojiye göre gerçekten bölümlenmiş olmadıkça monorepo çok güçlü bir seçenektir. Ölçek kendini belli eder.

4. Ekibe göre kodu izole eden güvenlik veya uyum gereksinimleriniz var mı? Finansal, sağlık, bazı kamu sektörü bağlamlarında koda erişim adlandırılmış kişilere sınırlandırılabilir. Denetçiler bunu talep edebilir. Bu kısıtlama diğer cevapları geçersiz kılabilir. Sıkı kod yalıtımı uyum şartı ise, polyrepo tercih değil, zorunluluktur. Tartışma sona erer.

Soru 1'e "evet", soru 4'e "hayır" yanıtı verdiyseniz monorepo hemen hemen kesindir. Soru 1'e "hayır", soru 2'ye "evet" verdiyseniz polyrepo savunulabilir. Geri kalan her şey yarıya bölünen bir kararıdır:her ikisi de işe yarayabilir, ama seçiminiz takip edilen kültür biçimini belirler.

Çoğu Büyüyen Ekip Nereye Varıyor

Çok az olgun mühendislik kuruluşu her iki aşırı uçta çalışır. En yaygın model: ana ürün için monorepo (ön uç, paylaşılan kütüphaneler, birbirlerine bağlı arka uç hizmetleri) + gerçekten bağımsız bileşenler için ayrı depolar. Hibrit yaklaşım.

Kendi zamanlamasında çalışan ve ana ürünle hiçbir kod paylaşmayan veri boru hattı monorepo dışında olmalı. Tek kişi ekip tarafından tutulan dahili araç dışında olmalı. Halka açık görünürlüğe ihtiyaç duyunan açık kaynak kütüphanesi dışında olmalı. Bu bileşenler serbest kalabilir.

Bu taviz değildir:temiz ikili yanıtı nadiren olan bir soruya doğru cevaptır. Birlikte hareket etmeleri gereken şeyleri bir arada tutun. Gerçekten bağımsız olanı ayırın. Bu karara bağlı kalın.

Önemli olan şey kararı kasıtlı vermektir, varsayılan olarak değil. Polyrepo dağılması yaşayan çoğu ekip bunu seçmedi: ilk hizmeti başlattı, sonra ikinci, sonra üçüncü hizmeti:ve hiç durmayıp bu hizmetlerin birlikte olması gerekip gerekmediğini sormadı. Sonra birleştirme gerektiği zaman çok geç olmuştur.

Bir Yaklaşımı Gerçekten İşe Koyan Araçlar

Monorepo'lar için:

• Nx: en zengin özellik seti; 20+ paket veya çoklu dil kullanan ekipler için iyi. Öğrenme eğrisi daha dik ama daha ileriye ölçeklenebilir. Şu anda endüstri standardıdır.

• Turborepo: başlamak daha basit; JavaScript/TypeScript ekipleri 20 pakete kadar mükemmel. Vercel'de ücretsiz uzak önbelleğe alma veya kendi kendine barındırılan seçenekler. Hızlı başlamak istiyorsanız, buradan başlayın.

• Bazel: çok büyük, çoklu dil, kurumsal ölçekteki depolar için. Kurulum maliyeti yüksek. Diğer seçenekler yetersiz kaldıktan sonra yapılacak hareket.

Polyrepo'lar için:

• Paylaşılan kütüphaneler için sürümlendirme disiplini zorunludur. Semantik sürümlendirme ve tutarlı changelog olmadan bağımlılık yalıtımı altı ay içinde norm hale gelir. Bu disiplin ekibinizin kültürü haline gelmeli.

• Paylaşılan bağımlılık değiştiğinde depolar arasındaki CI/CD boru hatlarını tetikleyen araçlandırma. GitHub Actions workflow_dispatch ve repository_dispatch olayları aracılığıyla destekler. Otomasyon kültür yerine alır.

• Paylaşılan paket dağıtımı için bağımlılık kaydı (npm private, GitHub Packages, Artifactory). Merkezi bir kaynağınız olması gerekir.

Biscuit konfigürasyon dosyasını getirebilir. Hangisini kullanacağı kararı yine bu dört soruya gelir. Tekrarlanıyor musunuz? Evet:çünkü bu sorular her şeyi açıklar.