Aynı proje birden fazla müşteri için dallanma modeli önerisi

Farklı müşteriler için temel görevi gören çeşitli uygulamaları içeren çok büyük bir projemiz var.

Her müşterinin ürünün kendi kişiselleştirmesi, farklı kilometre taşları, farklı gereksinimleri vb. Vardır ve böylece her proje kendi ihtiyaçlarına göre bağımsız olarak gelişecektir.

Projenin özü, her projede benzerdir (ancak eşit değildir) ve organizasyon, her müşteriyi bağımsız olarak ele alan (ancak aralarında iletişim olan) ekipler olacak şekilde yapılır. Şimdiye kadar, internette arama yaparak veya parlak bir fikir bularak ihtiyaçlarımıza uygun bir plan bulamadım :)

Şimdiye kadar, ürünü tüm ihtiyaçlara uygun olarak, gerekli değişiklikler için belirli şubelerle elde ederek çalışıyoruz, ancak ürün iyi bir mimariye sahip olmasına rağmen, yavaş yavaş büyük bir sorun haline geliyor. Karşılaştığımız ana sorunlar şunlardır:

• Her müşteri için farklı kilometre taşları: Bu, her ekibin kararlılığı veya ürünlerini etkileyen geri kalan taahhütler olmadan farklı zamanlarda sürümler üretmesi gerektiği anlamına gelir.
• Bazı durumlarda sistemin çekirdeğini etkileyebilecek veya etmeyebilecek farklı gereksinimler.
• Büyük takımlar (20+ takım üyesi)
• Sistemdeki hataları işleme: Bir ekip projesinde diğer istemcileri etkileyebilecek bir hata bulursa ne yaparsınız?

Not: 10 + M LOC içeren bir projeden bahsediyoruz.

Not: Team Foundation System, Visual Studio 2008 ve C # (çoğunlukla) kullanıyoruz.

Durumun nasıl ele alınacağına dair herhangi bir öneri, kaynak veya fikir var mı? Piyasada benzer bir sorunu olan herhangi bir model var mı?

Aslında, sana bir dallanma modeli değil, sisteme ilişkin çok boyutlu kısıtlamaları ile başa çıkmak için tam bir kapsamlı bir yaklaşım gerekmez öneririm olmadan dallanma. Uygulamada, bazı ortaklıkları olan ancak dallarda farklı şekilde gelişecek olan birden fazla sistemi sürdürmenin her zaman bir sorun olacağına inanıyorum, bu yüzden her şeyi bir bütün olarak gelişecek, ancak farklı konfigürasyonlardan oluşan tek bir sisteme dönüştürmek daha iyidir. Bu çok basit görünebilir, ancak bu alanda birçok başarılı endüstriyel uygulama ile kapsamlı bir araştırma var.

Bu yaklaşımın adı Yazılım Ürün Hatları veya bazen Ürün Hatları Mühendisliği'dir . Gönderen CMU SEI Yazılım Ürün Hatları sayfa :

Bir yazılım ürün serisi (SPL), belirli bir pazar segmentinin veya misyonunun özel ihtiyaçlarını karşılayan ortak bir yönetilen özellik kümesini paylaşan ve ortak bir çekirdek varlık kümesinden öngörülen bir şekilde geliştirilen bir dizi yazılım yoğun sistemdir. .

Ana fikir, her gereksinimin, her kilometre taşının, her özelliğin (bu alandaki önemli bir terim) en yüksek düzeyde tüm sistemin bir parçası olmasıdır. Çeşitli müşterilere dağıtılan gerçek sistemler aslında bir dizi özelliktir. Bununla birlikte, her özellik yalnızca sisteme ezilmiş fiziksel bir bileşen değildir, diğer özelliklere bağlı olarak veya etkinleştirilerek tanımlanır (böylece bir özellik seçerek bağımlılıklarını otomatik olarak dahil edebilirsiniz).

Bunun yerine, tüm bu şubeleri korumak yerine, bir müşteriye özel konfigürasyon seti ile birlikte bir sistemi sürdürürsünüz.

Uygulamada çok büyük bir sistemle böyle bir yaklaşıma göç etmek zor hatta imkansız olabilir, ancak o zaman bile SPL'de kullanılan yaklaşımların en azından (kısmen) olabileceğini değerlendirmek için kullanılan yaklaşımları araştırmak yararlı olacaktır. çalışmalarınıza entegre edilmiştir.

Bazı yararlı bağlantılar:

• Vikipedi: Ürün Hattı Mühendisliği
• CMU SEI'den Örnek Olaylar
• Yazılım Ürün Hatları , çok sayıda tanıtım malzemesi olan bir site.

İlk işime başladığımda benzer projeler üzerinde çalıştım (ancak daha küçük ölçekli) ve aynı sorunlarla karşılaştık. Ayrıca tüm müşteriler için genel çözüm işleme gereksinimleriyle başladık, ancak bu sadece gereksinimlerin çelişkili olduğu noktalarda mümkün oldu. Önerilerinizi yaptık ve her müşteri için ayrı bir sürüm başlattık. Bu bile problemleri gereksinimler ve özelleştirme ile çözdü, böcekleri ve küresel değişiklikleri çözmek için bir bakım kabusu haline geldi.

Uygulamadaki kod sadece benzer olduğundan, bir müşteri sürümünden diğerine değişikliklerin yapılması çok karmaşıktı ve her sürümü ayrı ayrı yeniden test etmek gerekiyordu (otomatik testlerimiz yoktu!). Genellikle farklı versiyonlarda regresyon hatalarına neden olur. Senaryonuzda bu daha da kötü olabilir, çünkü bir takım kendi versiyonundaki hatayı çözecek ve başka bir takım bu değişikliği tam olarak anlamadıkları versiyondan birleştirmek zorunda kalacaktır (tüm versiyonlarda çalışan bir takımdık).

Bazı ortak küresel çekirdeğiniz olmadığı sürece aynı problemlere sahip olacaksınız. Şirketten ayrılmadan önce yaklaşımımızın yanlış olduğunu gördük. Bu tür geliştirme senaryosunu desteklemek için, üst özelleştirilebilir uygulama katmanlarından yapılandırılabilecek paylaşılan genişletilebilir çekirdek ve veri modeline ihtiyacımız vardı. Bu çekirdek, her müşteriye özel özelleştirme için temel olarak kullanılmalı ve ayrı bir ekip tarafından korunmalıdır. Birden fazla proje yöneticisinin aynı ekipten kaynaklara ihtiyacı olacağı için bazı yönetim komplikasyonları içerecektir, ancak mimariyi tutarlı hale getirmenin, tüm süreci kontrol etmenin ve sürümleri senkronize tutmanın tek yolu budur.

Temel olabilirim, ancak sisteminizin çekirdeği ile karşılaştığınız şeyin, bileşenleri kullanan ve yazılımlarının farklı sürümlerini korumak ve desteklemek isteyen herkesin karşılaştığı aynı sorun olduğunu düşünüyorum ve bu farklı sürümlerin her biri farklı bir set gerektiriyor Bileşen sürümleri.

Örneğin

• sürüm 1.0, Kütüphane A 1.0, Kütüphane B 2.0, Kütüphane C 5.6 gerektirir
• sürüm 2.0, Kütüphane A 1.0, Kütüphane B 3.7, Kütüphane C 5.7 gerektirir
• sürüm 3.0, Kütüphane A 1.2, Kütüphane B 3.7, Kütüphane C 5.8 gerektirir

Bileşen sorununu çözme şeklimiz, sürüm kontrol sistemimizdeki kütüphanelerin tüm sürümlerine sahip olmak (bunları kaynakta oluşturuyoruz) ve her projenin arama yolunu (referans yolu?) Değiştirerek uygun kütüphane sürümünü kullanmasını sağlamaktır.

Delphi'de bu, tasarım sırasında kütüphanelere ihtiyacınız yoksa projenin yapılandırma dosyası (kaynak kontrolü altında) aracılığıyla kolayca yapılır, aksi takdirde hala yapılabilir, ancak Delphi IDE'yi kullanmak için geçiş yapmanız gerektiğinden biraz daha acı olur doğru sürüm de (sürüm kontrolü altındaki kayıt (.reg) dosyaları burada kurtarmaya gelebilir).

Çekirdek sisteminiz için bir çözüm, onu farklı sürümleri tuttuğunuz bir kütüphane olarak ele almak olabilir. Hangi özünde her sürüm için farklı dallar kurmanız gerektiği anlamına gelir. Bir istemcinin uygulaması daha sonra uygun çekirdek sistemin şube klasörüne başvurarak çekirdek sisteminizin uygun "sürümünü" kullanabilir.

Çekirdek sisteminizin bağımlılıklarının yukarıdaki örneğe benzeyeceği durumlarda, istemci uygulamalarınızın bağımlılıklarının "sadece" ek bir referansı vardır: çekirdek sisteminizin sürümü.

Burada birden çok istemci uygulamasının avantajı, çekirdek sisteminizin belirli bir sürümünü ne zaman kullanmaya başlayabileceğinizi seçmeniz ve henüz belirli bir istemci uygulaması için kullanmaya hazır olmadığınız çekirdek sistemdeki değişikliklerden etkilenmemenizdir.