Karakterleri farklı olsa da birbiriyle ilişkili birden fazla projeyi nasıl birleştirmeyi (ya da birleştirmemeyi) tercih ediyorsunuz?
Örneğin aynı hizmet için front-end, back-end(api), serverless, batch, pipeline, ... vb. varsa
-
Mono-repo
Hizmet aynıysa repository de tektir! Her proje paket/klasör yapısı içinde
-> Commit yönetimi nasıl olacak..? CI/CD ya da pre-commit gibi hook'lar daha karmaşık hale gelmez mi.. -
Git Submodules
Karakterleri farklıysa en azından git geçmişi ayrı yönetilmeli! Yine de mümkün olduğunca tek çatı altında toplansın..
-> submodule sync vb. için öğrenme eğrisi.. merge de daha karmaşıklaşıyor.. diğer geliştiriciler buna uyum sağlayabilir mi? -
Herkesin ayrı repo’su
Basitçe! Farklı projeyse repo da farklı olsun!
-> A hizmetine bakmak için hangi repo'ya bakmam gerekiyor? Ha bu, şu, ... bir de başka ne vardı...
Sanırım bunun tek bir doğru cevabı yok ama hangisini / neden tercih ettiğinizi merak ediyorum!
16 yorum
Ben ayrı ayrı repo taraftarıyım...
Bu özellikle ilgili API’nin geçmişine bakmak istersem neye bakmam gerekir? diye düşündüğümde, bir repo’yu tek bir özellikle eşleştirmek daha kullanışlı geliyor.
Ben çoğu durumda monorepo kullanıyorum ama submodule kullandığım iki durum var.
Dışarıdan bir yayıncı/markup geliştiricisi işe alındığında.
Yayınlama için gerekli bilgiler dışındakileri dışarıdaki yayıncıya göstermek istemediğimde submodule kullanıyorum.
Harici bir çözümü özelleştirmek gerektiğinde.
Özellikle eklenti özelliği sunan bir çözümse submodule kullanıyorum.
İlgili harici çözümü submodule olarak ekleyip, kendi eklentilerimi symlink vb. ile eklenti yolunun içine yerleştirerek çalışıyorum. Kendi eklentilerimin sürüm yönetimini ayrı yapabiliyor, harici çözüm de kendi version control yapısını olduğu gibi koruyabiliyor; bunun avantajı var.
Görünüşe göre herkesin submodule kullanım deneyimi pek iyi değil.. Bunu iyileştirebilecek bir araç olsa güzel olurdu
Yalnızca merge commit yapabileceğine güveniyorsan mono-repo,
sık sık rebase yapacaksan multi-repo,
submodule mü? Boş ver, işletim sisteminin sunduğu dizin linklerini kullan...
Eskiden her biri bağımsız repo'ları kullanıyordum ama son dönemde tamamen submodule kullanma yöntemine geçtim.
Önceden git konusundaki bilgi düzeyim düşük olduğu için submodule'leri düzgün kullanamıyordum, ancak şimdi submodule kullanmanın daha iyi olacağını düşündüğüm için böyle yapıyorum.
Ancak submodule kullandığınızda ilgili submodule'e commit atmanız ve parent repo'ya da yeniden commit atmanız gerekiyor; bunun sonucunda bu iki zamanlama arasında fark oluşuyor ve repo'nun tutarlılığını düşüren bir sorun ortaya çıkıyor gibi görünüyor.
https://monorepo.tools/
Bu siteye daha önce bakmadıysanız, bir göz atmanız iyi olabilir.
Kişisel deneyimime göre submodule pek tavsiye etmem.
Başka bir deponun kodunu submodule ile paylaşmak istiyorsanız, bence onu paket olarak dağıtmak daha iyi olur.
Bizim şirkette ise proje başına ekip üyesi sayısı azdı ve frontend ile backend'in dili ve teknoloji yığını ayrıştığı için roller arasında çapraz katkı neredeyse hiç olmadı. Tüm IT sistemlerinde olduğu gibi, sonunda işin organizasyon yapısını takip ettiğini düşünüyorum.
Oo.. arayüzü insanın mı uyarladığı yoksa aracın mı yaptığına göre karşı tarafın kod görünürlüğünü ayarlayan bir yaklaşım yani
Mono-repo deneyimim olmadığı için merak ettiğim bir şey var. Mono Repo kullanırken, birden fazla proje ya da hizmette ortak olan modüller (ör. tasarım sistemi) de aynı Mono Repo'nun içine mi giriyor? Yoksa bu tür şeyler mecburen ayrı bir Repo'ya ayrılıp oradan referans verilerek mi kullanılıyor?
Ortak modüle erişimde, sanırım
yarn workspacegibi araçların yardımıyla symlink biçiminde erişiyorduk!Ben şirkette de kişisel projelerde de front-end, back-end, batch vb. diye ayırmadan her şeyi tek bir git deposunda yönetiyorum.
Geriye dönük uyumluluğu korumaktan ziyade ikisini birlikte değiştirmenin daha pratik olduğu durumlar da oluyor. Zaten her iki tarafta da ekip küçük olduğu için boş yere ayırmanın pek bir faydası yok gibi... GitHub Actions tarafında da yalnızca değişen kısımların çalışmasını sağlayacak şekilde ayarlama zahmetine katlanmaya değdi. En önemlisi de, back-end ve front-end diye ayırmaktansa herkesin birbirine katkı verebilmesi daha iyi diyebilirim. (Örneğin front-end işiyle uğraşırken back-end’de gerekli bir şey çıkarsa onu doğrudan eklemek ya da hataları da bizzat düzeltmek gibi...)
Hmm, anlaşılan ölçek gerçekten küçükse ya da rol ayrımları çok katı değilse monorepo tercih ediliyor! Peki Git geçmişinin karışması gibi şeyleri çok da dert etmiyor musunuz? (Nasıl olsa herkesin baktığı kod olduğu için mi?)
İlginç olan şu ki bunu yan projelerimde de yapıyorum. Şu ana kadar yaklaşık 12 kişiyle birlikte çalıştım. Her bir kişi frontend'den backend'e kadar işi tek akışta ele alıyor. Vertical slice'a benziyor da denebilir.
Ben bunu karışmış olarak görmüyorum. Çünkü tek bir PR içinde hem frontend hem de backend tarafında birlikte değişiklik yaptığımız durumlar da sık oluyor. Bizim yaklaşımımız, herkesin full-stack çalışan 4 kişiden oluşması; bu yüzden backend/frontend ayırmadan birbirimizin işlerini review ediyor ve yapılan değişiklikleri de bilmemiz gerekiyor.
Modül çok büyük değilse monorepo
Modül büyükse submodule
Ya da açık kaynak olarak dağıtırken yalnızca submodule’e katkı yapılmasını isteyip ana repoyu ayrı şekilde yönetmek istiyorsanız,
submodule olarak ayırmak mantıklı gibi görünüyor.
Ama işin içine submodule girince, açık kaynakta başka kullanıcıların katkı verebilmesi için test veya build ile ilgili dokümantasyon hazırlamak biraz daha karmaşık hale geliyor gibi.
Bu yüzden kişisel olarak, ikisinin katkı modeli farklı değilse monorepo tercih ediyorum
ya da farklı GitHub repolarında tutup her birini paket olarak dağıtmak veya Docker image olarak yönetmek daha uygun geliyor.
Açık kaynakla ilgili olduğunu düşünmemiştim, görüşünüz için teşekkürler!