Monorepo mu Polyrepo mu? Projen İçin Doğru Yapıyı Seçmek

Yeni bir yazılım projesine başlarken kaynak kodun nerede tutulacağı basit bir karar gibi görünebilir. Ancak uygulamalar, servisler ve ekipler çoğaldıkça bu tercih; kod paylaşımını, test süreçlerini ve sürüm yönetimini doğrudan etkiler.

Bir web uygulaman, mobil uygulaman ve bu uygulamaların kullandığı servislerin olduğunu düşün. Tüm kodu tek bir Git deposunda mı tutmalısın, yoksa her bileşen için ayrı bir depo mu oluşturmalısın?

Monorepo mu polyrepo mu sorusunun yanıtı, bileşenlerin birlikte ne kadar değiştiğine ve ekiplerin ne kadar bağımsız çalışması gerektiğine bağlıdır. Doğru kararı vermek için önce bu iki yaklaşımın ne anlama geldiğini netleştirelim.

Monorepo nedir?

Monorepo, birden fazla uygulamanın, servisin veya kütüphanenin tek bir kaynak kod deposunda yönetilmesidir.

Örneğin, bir e-ticaret projesinin monorepo yapısı şöyle olabilir:

e-ticaret/
├── apps/
│   ├── web/
│   ├── admin/
│   └── api/
└── packages/
    ├── ui/
    └── shared-types/

Bu yapıda web sitesi, yönetim paneli ve API aynı depoda bulunur. Ortak arayüz bileşenleri ve veri tipleri de ilgili paketlerde tutulur.

Monorepo, monolitik mimari demek değildir. Aynı depoda bulunan uygulamalar ayrı ayrı çalışabilir ve bağımsız olarak yayınlanabilir. Depo düzeni ile uygulamanın çalışma mimarisi farklı kararlardır.

Monorepo avantajları

• Birlikte değişiklik yapmak kolaylaşır. Bir API değişikliği ile onu kullanan uygulamadaki düzenlemeyi aynı değişiklik isteğinde inceleyebilirsin.
• Ortak kod daha erişilebilir olur. Paylaşılan paketler aynı depo içinde geliştirilebilir.
• Standartları ortaklaştırmak kolaylaşır. Kod biçimlendirme, test ve geliştirme ayarlarını merkezi olarak yönetebilirsin.
• Kodun bütünü görülebilir. Bir bileşendeki değişikliğin diğer uygulamaları nasıl etkilediğini incelemek kolaylaşır.

Monorepo zorlukları

Proje büyüdükçe her değişiklikte bütün uygulamaları test etmek zaman kaybına neden olabilir. Değişiklikten etkilenen bölümleri belirleyen test ve derleme süreçleri kurmak gerekebilir.

Ortak depoda bulunmak, bağımlılıkların kontrolsüz oluşmasını da kolaylaştırabilir. Hangi uygulamanın hangi paketi kullanabileceğini açıkça tanımlamak önemlidir.

Ayrıca kaynak kod erişimini depo seviyesinde yöneten sistemlerde, farklı ekiplerin yalnızca belirli klasörlere erişmesini sağlamak zorlaşabilir. Kod inceleme sorumluluğu tanımlamak, erişimi kısıtlamakla aynı şey değildir.

Polyrepo nedir?

Polyrepo, uygulamaların, servislerin veya kütüphanelerin ayrı kaynak kod depolarında yönetilmesidir. Multi-repo adıyla da anılır.

Aynı e-ticaret projesi polyrepo yaklaşımında şu depolara ayrılabilir:

e-ticaret-web
e-ticaret-admin
e-ticaret-api
e-ticaret-ui

Her deponun kendi geliştirme ayarları, erişim izinleri ve yayın süreci olabilir. Ortak kod ise sürümlenmiş paketler gibi yöntemlerle paylaşılabilir.

Polyrepo avantajları

• Ekip sınırları belirginleşir. Her ekip sorumlu olduğu depoyu kendi süreçleriyle yönetebilir.
• Erişim izinleri ayrıştırılabilir. Depolara farklı yetkiler tanımlanabilir.
• Yayın süreçleri ayrı yönetilebilir. Her bileşen kendi sürüm takvimini izleyebilir.
• Teknik tercihler özelleştirilebilir. Farklı depolar, ihtiyaçlarına uygun araçlar ve ayarlar kullanabilir.

Polyrepo zorlukları

Birden fazla bileşeni etkileyen değişiklikler koordinasyon gerektirir. Ortak bir kütüphaneyi güncellediğinde önce yeni sürümü yayınlaman, ardından bu sürümü kullanan depoları güncellemen gerekebilir.

Ayrı depolardaki test ve geliştirme ayarları zamanla birbirinden uzaklaşabilir. Ortak standartları korumak için şablonlar veya paylaşılan yapılandırmalar kullanmak faydalı olur.

Depoların ayrı olması, sistemlerin otomatik olarak bağımsız hale geldiği anlamına da gelmez. Birlikte yayınlanmak zorunda olan servisler, ayrı depolarda tutulduklarında da koordinasyona ihtiyaç duyar.

Monorepo ve polyrepo arasındaki farklar

Projen için doğru yapıyı nasıl seçersin?

Kararı yalnızca ekip büyüklüğüne veya popüler araçlara göre verme. Küçük bir ekip ayrı ürünleri polyrepo ile yönetebilir; büyük bir ekip de iyi tanımlanmış sınırlarla monorepo kullanabilir.

Aşağıdaki sorular, günlük çalışma biçimine uygun yaklaşımı bulmana yardımcı olur.

1. Bileşenler ne sıklıkla birlikte değişiyor?

Bir özellik geliştirmek için sürekli web uygulamasını, API’yi ve ortak paketleri birlikte güncelliyorsan monorepo koordinasyonu kolaylaştırabilir.

Bileşenlerin değişiklikleri çoğunlukla birbirinden bağımsızsa polyrepo daha uygun olabilir.

Örnek: Yönetim paneli ve müşteri uygulaması aynı arayüz bileşenlerini yoğun biçimde kullanıyorsa ortak paketi aynı depoda geliştirmek pratik olabilir.

2. Ekiplerin sorumlulukları ne kadar bağımsız?

Aynı ekip bütün uygulamalar üzerinde çalışıyorsa ayrı depolar arasında geçiş yapmak ek yük oluşturabilir.

Her servisin ayrı bir sahibi, geliştirme planı ve operasyonel sorumluluğu varsa polyrepo bu sınırlarla uyumlu olabilir. Monorepo tercih edildiğinde de klasör ve paket sahipliğinin açıkça tanımlanması gerekir.

3. Kaynak kod erişimini ayırman gerekiyor mu?

Bir dış iş ortağının yalnızca belirli bir uygulamanın koduna erişmesi gerekiyorsa ayrı depolar erişim yönetimini kolaylaştırabilir.

Bu ihtiyacı kararın başında değerlendir. Sonradan erişim sınırları oluşturmak, depo yapısını yeniden düzenlemeyi gerektirebilir.

4. Test ve yayın süreçlerini kim yönetecek?

Monorepo büyüdükçe yalnızca etkilenen bileşenleri test etmek, derleme sonuçlarını önbelleğe almak ve bağımlılıkları takip etmek önem kazanır.

Polyrepo tarafında ise çok sayıda deponun ayarlarını güncel tutmak ve ortak paket sürümlerini yönetmek ek çalışma yaratır.

Dolayısıyla asıl soru, hangi yapının daha az araç gerektirdiğinden çok, ekibinin hangi bakım yükünü sürdürebileceğidir.

İki örnek senaryoyla karar verelim

Senaryo 1: Birbiriyle yakından ilişkili uygulamalar

Beş kişilik bir ekip; web uygulaması, yönetim paneli ve API geliştiriyor. Özellikler sıklıkla bu üç bileşeni birlikte etkiliyor. Arayüz bileşenleri ve veri tipleri paylaşılıyor.

Bu durumda monorepo güçlü bir başlangıç seçeneğidir. İlişkili değişiklikler birlikte incelenebilir ve ortak kod aynı geliştirme akışında güncellenebilir.

Yine de uygulamalar arasındaki sınırlar korunmalı, her uygulamanın nasıl test edileceği ve yayınlanacağı tanımlanmalıdır.

Senaryo 2: Farklı ekiplerin yönettiği bağımsız ürünler

Bir şirketin birbirinden farklı müşterilere hizmet veren üç ürünü bulunuyor. Ürünlerin ekipleri, erişim ihtiyaçları ve yayın takvimleri farklı. Ortak kod kullanımı sınırlı.

Bu durumda polyrepo uygun olabilir. Her ekip kendi deposunu yönetebilir; ihtiyaç duyulan ortak kütüphaneler sürümlenerek paylaşılabilir.

Burada dikkat edilmesi gereken konu, temel kalite standartlarının depolar arasında korunmasıdır.

Karar verirken sık yapılan hatalar

• Monorepo ile monoliti aynı şey sanmak: Tek depo, tek uygulama veya tek yayın zorunluluğu oluşturmaz.
• Polyrepo kullanınca bağımlılıkların biteceğini düşünmek: Servisler arasındaki bağımlılıklar depo ayrımıyla ortadan kalkmaz.
• Ortak kodun tamamını paylaşmaya çalışmak: Benzer görünen iki kod parçası farklı ihtiyaçlara hizmet ediyor olabilir.
• Yalnızca ilk kurulum kolaylığına bakmak: Test, sürümleme ve bakım süreçlerini de hesaba katmak gerekir.
• Depo değiştirerek mimari sorunları çözmeyi beklemek: Belirsiz sorumluluklar ve sıkı bağımlılıklar ayrıca ele alınmalıdır.

Sık sorulan sorular

Monorepo içinde farklı programlama dilleri kullanılabilir mi?

Evet. Aynı depoda farklı dillerle geliştirilmiş uygulamalar bulunabilir. Her uygulamanın bağımlılık, test ve derleme süreçlerinin uygun biçimde yönetilmesi gerekir.

Mikroservisler için polyrepo zorunlu mu?

Hayır. Mikroservisler monorepo veya polyrepo içinde geliştirilebilir. Servislerin çalışma ve yayın bağımsızlığı, depo sayısından ayrı değerlendirilmelidir.

İki yaklaşım birlikte kullanılabilir mi?

Evet. Birbiriyle yakından ilişkili uygulamalar aynı depoda tutulurken bağımsız ürünler ayrı depolarda yönetilebilir. Böyle bir yapıda sınırların neden çizildiği açık olmalıdır.

Sonradan depo yapısını değiştirmek mümkün mü?

Evet. Ancak kodu taşımak dışında erişim izinlerini, otomatik testleri, yayın süreçlerini ve paket bağımlılıklarını da düzenlemek gerekebilir. Geçişin faydası bu maliyetle birlikte değerlendirilmelidir.

Seçimini günlük geliştirme ihtiyaçlarına göre yap

Monorepo mu polyrepo mu kararını verirken son birkaç özelliğin nasıl geliştirildiğine bak. Kaç bileşen birlikte değişti? Kaç ekip koordinasyon kurdu? Ortak kod nerelerde kullanıldı?

Birlikte değişen ve yoğun kod paylaşan bileşenler için monorepo; ayrı sahiplik ve erişim sınırları bulunan bağımsız bileşenler için polyrepo uygun olabilir.

Kararının gerekçesini kısa bir notla kaydet. Böylece proje büyüdüğünde mevcut yapının ihtiyaçlarını karşılayıp karşılamadığını somut ölçütlerle yeniden değerlendirebilirsin.