Laravel Türkiye Discord Kanalı Forumda kod paylaşılırken dikkat edilmesi gerekenler!Birlikte proje geliştirmek ister misiniz?

Merhaba, geliştirdiğimiz bir projede versiyon ve sürümlere ayırmak konusunda bir karışıklık yaşıyorum. Şöyle ki github üzerinde temel hali saklanan proje firma bazında kiralanabilir mantığında kullanılacak. Her firma için aynı proje klonlanarak kurlumu yapılacak. Buraya kadar sorun yok fakat temel (güvenlik, performans) geliştirmeleri daha önce kurulmuş ve sonrasında kurulacak tüm projeler için geçerli olmasını istiyorum. Bunun için github üzerinden versiyonlama yapabilirim diye düşündüm. Aynı zamanda firma bazında ek özellik veya varolan özelliğin değişmesi gibi bir durumda söz konusu. Firma bazındaki talepler için de branch ile çalışabilirim diye düşündüm fakat git konusunda tecrübem ve bilgim bu karmaşıklığı kurmaya yetmiyor

  • Bahsettiğim karışıklık için önerebileceğiniz daha iyi bir yöntem var mı?
  • Git konusunda nasıl ilerlemem gerekir?
  • Bu konuda öngöremediğim veya daha önce buna benzer bir yapı kullandıysanız öneriniz var mı?
  • mgsmus bunu yanıtladı.

  • motades498 Projenizi bilmiyorum ama yine tek repo önerirdim. Zaten tasarım desenleri kullanmamızın sebeplerinden biri de bu tarz problemleri çözmek. Yönetim açısından da, müşteri talebini iletir, PO/PM isteği değerlendirir ve teknik ekiple bir araya gelerek bu isteği projeye, projeyi müşteriye özel kılmadan nasıl eklenebileceğini tartışır.

    Müşteriye özel hizmet verebilirsiniz ama müşteri talebini değerlendirip projeye herkesin kullanabileceği şekilde eklemek ayrı bir şey, projeyi müşteri için izole edip diğerlerinden ayırmak ayrı bir şey. 20 müşteriniz oldu, hepsinde yapılması gereken bir değişiklik oldu, mesela bir düzeltme ya da geliştirme ama 5 müşteriye yaptığınız geliştirmeler yüzünden çakıştı, bu 5 müşteriye bu değişiklikleri veremediniz, nasıl olacak? Ayrıca bu tarz bir sistemde müşteri sayısı artınca eğer aranızda süper bir insan yoksa çalışan sayınızı da arttırmanız gerekir. Bir noktadan sonra insan kaynağı yetmez yani. Bu seferde gelir gider dengesi bozulur. Bu bahsettiğiniz şeyler tam da SaaS'ın ortaya çıkma sebeplerinden bazıları aslında. Siz orada 10 müşteri oldu mu biz bunu nasıl yöneteceğiz diye düşünürken 5 kişinin geliştirdiği ürünü 10 bin müşteri kullanıyor olacak.

    Eğer projeniz Wordpress gibi bir şey ise bahsettiğiniz yolla ilerlenebilir belki ama oluşacak sorunlar ile ilgili düşüncelerim hala geçerli. Benim tavsiyem olaya klasik SaaS şeklinde bakmanız; tek repo, tek veri tabanı, tenant yapısı, modüler yapı vs. Öteki türlü projenizi bir framework gibi tasarlayıp her müşteriye bundan özel ürün üretmeniz lazım.

      • mgsmus

        Seviye 1382
      • Gönderi #2

      motades498 Okurken bile sanki içgüdü gibi karamsarlığa kapıldım ve bunun sonu kaos gibi hissettim 🙂 Bu bana yönetilebilir gelmedi. Sanırım ben olsam feature flag tarzında bir şey geliştirir ve repoyu tek bir kod kümesi olarak tutmaya çalışırdım. Yani tek repo olacak, müşteri bazlı branch fork vs olmayacak, tüm müşteriler aynı ürünü kullanacak, tüm özellikler üründe olacak ama müşteri bazlı açıp kapatılabilecek (feature flag). Ürünü de bu şekilde geliştirirdim.

      • A özelliğini tüm müşteriler kullanıyor.
      • B özelliğini bazı müşteriler kullanıyor.
      • Bazı müşteriler A özelliğini farklı kullanıyor, A'dan AB özelliğini türettim.
      • Bazı müşteriler AB özelliğini farklı kullanıyor, AB'den ABC özelliğini türettim.

      Sonra mesela kodda

      if($flagManager->isEnabled('AB', $customer)) {
    // Müşteri AB özelliğini kullanıyorsa...
}

      Bir yerde de müşteri için hangi özellikleri kullandığını tutardım; bir dosyada ya da veri tabanında.

        Hissiyat konusunda hem fikir olduğumuza göre sorunumu doğru açıkladım zannediyorum peki bu durumda örneğin x firmasının ihtiyaç duyduğu özelliğe bağlı ayrı veritabanı kaynakları (tablolar, sütunlar)/servisler/entegrasyonlar gerekebileceğini de düşünürsek yine bahsettiğiniz gibi tek bir repo mu önerirdiniz?

        Her firma için ayrı hostlar ve veritabanları olmalı diye kurgulamıştım. O açıdan sadece bir firmanın kullanacağı özelliği diğer 20 firmanın kaynak kodunda bulunması mantıklı gelmemişti ama daha önce bu tarz bir tecrübem olmadığı için karşılaşacağım durumları öngöremiyorum, ek bir tavsiyeniz varsa fikrinizi almak isterim

          motades498 Projenizi bilmiyorum ama yine tek repo önerirdim. Zaten tasarım desenleri kullanmamızın sebeplerinden biri de bu tarz problemleri çözmek. Yönetim açısından da, müşteri talebini iletir, PO/PM isteği değerlendirir ve teknik ekiple bir araya gelerek bu isteği projeye, projeyi müşteriye özel kılmadan nasıl eklenebileceğini tartışır.

          Müşteriye özel hizmet verebilirsiniz ama müşteri talebini değerlendirip projeye herkesin kullanabileceği şekilde eklemek ayrı bir şey, projeyi müşteri için izole edip diğerlerinden ayırmak ayrı bir şey. 20 müşteriniz oldu, hepsinde yapılması gereken bir değişiklik oldu, mesela bir düzeltme ya da geliştirme ama 5 müşteriye yaptığınız geliştirmeler yüzünden çakıştı, bu 5 müşteriye bu değişiklikleri veremediniz, nasıl olacak? Ayrıca bu tarz bir sistemde müşteri sayısı artınca eğer aranızda süper bir insan yoksa çalışan sayınızı da arttırmanız gerekir. Bir noktadan sonra insan kaynağı yetmez yani. Bu seferde gelir gider dengesi bozulur. Bu bahsettiğiniz şeyler tam da SaaS'ın ortaya çıkma sebeplerinden bazıları aslında. Siz orada 10 müşteri oldu mu biz bunu nasıl yöneteceğiz diye düşünürken 5 kişinin geliştirdiği ürünü 10 bin müşteri kullanıyor olacak.

          Eğer projeniz Wordpress gibi bir şey ise bahsettiğiniz yolla ilerlenebilir belki ama oluşacak sorunlar ile ilgili düşüncelerim hala geçerli. Benim tavsiyem olaya klasik SaaS şeklinde bakmanız; tek repo, tek veri tabanı, tenant yapısı, modüler yapı vs. Öteki türlü projenizi bir framework gibi tasarlayıp her müşteriye bundan özel ürün üretmeniz lazım.

              4 gün sonra

              mgsmus İlginiz için teşekkür ederim, bir süre bu yöntem de denedim fakat her projeyi bölmem gerektiğine karar verdim. Aksi takdir de çok sürdürülebilir olmayacak gibi görünüyor tabi bu biraz da paylaşmadığım proje detayları ile ilgi, yine de bu tarz bir durum da bahsettiğim gibi git üzerinde sürümleme/versiyonlamanın çok mantıklı olmadığını fark ettim, teşekkür ederim