Mikroservis Repository Yapılandırması

6 Oca

Mikroservis yaklaşımında, kod depolama için iki seçenek bulunur. Birincisi tüm servislerin tek bir repository içerisinde tutulması. İkincisi her bir servis için ayrı repository oluşturulması.

Tek bir repository kullanımı

Genel olarak, tüm mikro servislerde tek bir repository tercih edilebilir, ancak kod büyüdükçe her bir servis için bir alt klasör dizini ve proje yapısını yönetmek zor olabilir. Tüm mikroservisleri tek bir havuza koymaya karar vermeden önce dikkate alınması gereken şeyler şunlardır:

Developer Sınırlarının Belirlenmesi

Tüm mikroservislerin kodu tek bir havuzda olduğundan, aralarında gerçek bir fiziksel sınır yoktur. Bu nedenle geliştiriciler, projeler arasında bir referans veya benzeri eklemeler yaparak diğer mikroservislerdeki bazı kodları kullanabilirler. Tüm mikroservislerin tek bir havuzda olması, geliştiricilerin sınırları aşmaması ve bunları yanlış kullanmaması için biraz disiplin ve kurallar konulması gerektirecektir. Kod sınırları belirlenmediğinde, developer sınırları belirlemek durumunda kalınabilir.

Paylaşılan Kod Oluşumu

Kod altyapısında servislerde ortak kullanılabilecek kodların cazibesine kapılarak, paylaşılan kodlar kümesi oluşabilir. Birbirinden bağımsız servisler oluşturmak amacıyla çıkılan mikroservis yolunda bağımlılıklar oluşmaya başlayabilir. Normalde ortak kullanılan kodlar paketlenerek Nuget, Npm gibi depolara aktarılarak kullanmak uygundur. Doğrudan kod repository içerisinde bağımlılık oluşturmak, servislerin bağımsız geleceği açısından uygun değildir.

Git Yönetimi

Çok fazla ekip üyesinin bir repository üzerinde çalışması pull request ve branch yönetimi açısından zordur. Sürekli gelen commit talepleri ve merge ile çakışmalar artabilir. Bir ekibi ilgilendirmeyen değişikliklerin bildirim mesajları, mailleri o ekibe de düşmeye başlar.

CI/CD Süreçleri

Kodu oluşturmak, test etmek ve/veya dağıtmak için Azure DevOps, Jenkins gibi araçlar kullanıldığında, Jenkins ve GitHub arasındaki entegrasyon gibi bazı yapılandırma güçlükleriyle karşılaşabilirsiniz. Birisi herhangi birmikroservise karşı bir merge/pull request isteği oluşturursa, yalnızca kodun belirli bir bölümünü (ilgili mikroservisi) oluşturacak/test edecek bir ardışık düzen yapılandırmak gerekir. Buna uygun bir yöntem de bulmak gerekecek. Kodda ilgili klasörde veya tag işleminde bir değişiklik olduğunda ilgili build adımının çalışması ve bir docker imaj çıkarması gibi senaryolar oluşturmak gerekebilir. Aynı senaryolar deployment adımları için de geçerlidir.

Sonuç

Bu sorunların tümü veya çoğu, bazı ekstra yönetim ve yapılandırma ile çözülebilir, ancak yine de ne kadar ek çabayla karşılaşabileceğinizi iyi tasarlamak gerekir. Bu nedenle genel tavsiye, mümkünse her bir mikroservis için ayrı repository kullanmak olacaktır.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.

Yorum için bu kutuya doğru sayıyı girin * Time limit is exhausted. Please reload CAPTCHA.