Sürüm Kontrolünde Aynı Kod Tabanından İki Ayrı Yazılım Sürümünün Korunması

Aynı yazılımın / programın / uygulamanın / komut dosyasının iki farklı sürümünü yazdığımı ve sürüm kontrolü altında sakladığımı varsayalım. İlk versiyon ücretsiz bir "Temel" versiyon, ikincisi ise ücretsiz versiyonun kod tabanını kullanan ve üzerinde birkaç ekstra değer katan özelliklerle genişleyen ücretli bir "Premium" versiyon. Yeni yamaların, düzeltmelerin veya özelliklerin her iki sürümde de yollarını bulması gerekir.

Şu anda kullanıyorum düşünüyorum masterve developkenarı boyunca ana kod tabanı (ücretsiz sürüm) dalları master-premiumve develop-premiumödenen sürümü için dalları. Ücretsiz sürümde bir değişiklik yapıldığında ve masterşubeyle birleştirildiğinde develop(elbette kapsamlı testlerden sonra ), daha fazla test develop-premiumiçin cherry-pickkomutla şubeye kopyalanır ve daha sonra birleştirilir master-premium.

Bu durumla başa çıkmak için en iyi iş akışı bu mu? Dikkat edilmesi gereken herhangi bir potansiyel sorun, uyarılar veya tuzaklar var mı? Şimdiye kadar elde ettiklerimden daha iyi bir dallanma stratejisi var mı?

Görüşleriniz çok takdir edilmektedir!

PS Bu Git'te depolanan bir PHP betiği içindir, ancak cevaplar herhangi bir dile veya VCS'ye uygulanmalıdır.

İki kod versiyonunun ortak bir temele sahip olması yerine, uygulamanızı, bu premium özellikleri farklı kod tabanlarından ziyade yapılandırılabilir ve yapılandırılabilir hale getirecek şekilde tasarlamalısınız.

Bu premium özellikleri (konfigürasyon ile devre dışı bırakılmış) temel sürümle birlikte göndermekten korkuyorsanız, bu kodu son bir derleme / paketleme adımında kaldırabilir ve sadece iki derleme profiline sahip olabilirsiniz.

Bu tasarıma sahip olarak, ayrıca 5 farklı tat gönderebilir ve çok esnek hale gelebilir, hatta üçüncü tarafların katkıda bulunmasına izin verebilir.

Şiddetle tavsiye değil bu amaçla şube kullanarak. Genel olarak, daha sonra tekrar birleştirilecek (veya birleştirilebilecek) şeyler için dalları (veya dalların birinin gelişimini durduracağınız salım dalları için) göz önünde bulundurmalısınız. Sizin durumunuzda, "temel" ve "premium" sürümlerinizi asla bir araya getirmeyeceksiniz ve her ikisi de süresiz olarak korunacaktır, bu nedenle dallar uygun değildir.

Bunun yerine, kaynak kodun ortak bir sürümünü kullanın ve #ifdef"temel" ve "premium" arasında farklı olan kod bölümlerini dahil etmek veya hariç tutmak için koşullu derleme (örneğin , C / C ++ dilinde PHP'nin ne olduğundan emin değilsiniz) kullanın.

PHP yerleşik bir derleme özelliğine sahip olmayabilir gibi gözüküyor, bu nedenle cpportak kaynak kodunuzu önceden işlemek için C önişlemcisini ( muhtemelen zaten kullanıyorsunuzdur) kullanabilir ve ondan "temel" ve "prim" üretmek için kullanabilirsiniz. önişlemci direktifleri olmadan sürüm. Elbette, bunu yapmayı seçerseniz make, önişlemciyi çalıştırma işlemini otomatikleştirmek için kullanmanız veya benzeri bir şey kullanmanız gerekir .

Temel projeye bağlı olan Temel ve Prim olan 2 ayrı proje kullanıyoruz. Parantez kullanmayın, bunlar genellikle özellikler için kullanılır.

Güncel cevapların çoğu şubeler yerine koşullu derleme lehine olsa da, şubeleri kullanmanın net bir faydasının olduğu tek bir senaryo vardır: (şimdi veya daha sonra) temel versiyonun kaynak kodunu mevcut tüm sürüm geçmişi ancak tüm premium özellikleri hariç tuttuğunuzda, bunu şubeler yaklaşımı ile yapabilirsiniz, ancak tek bir şube ve koşullu derleme ile yapabilirsiniz.

Vişne toplanmasına karşı tavsiyede bulunmak isterdim, bunun yerine temel sürümden premium sürüme kadar tüm değişiklikleri birleştiririm . Temelde hiçbir özellik veya hata düzeltmesi olmamalı, ancak premium sürümde eksik olmalıdır. İşleri olabildiğince acısız yapmak için, premium şubenin genel dosyaları mümkün olduğu kadar az değiştirdiğinden emin olmalısınız. Bu nedenle, premium şube çoğunlukla ek dosyalar ve talimatlar oluşturmak için belki de bazı küçük değişiklikler içermelidir. Bu şekilde, temel sürümdeki değişiklikler çakışmalara neden olmadan otomatik olarak birleştirilir.

Greg'in cevabı , “daha ​​sonra tekrar birleştirilecek (veya birleştirilecek) şeylerin dallarını göz önünde bulundurmanızı” önerdi. Az önce tarif ettiğim yaklaşımla durum böyledir, ancak tüm komisyonların nihai şubesi (ki aslında ) master-premiumolmayacaktır .mastermaster-basic

Alt modüller elbette bir seçenek olacaktır. Bu sizin derleme sürecinize bağlıdır, ancak eğer temel sürümü bir modül olarak kullanan bir projeye premium sürümünü yapabilirseniz, bu iyi olabilir. Ancak, bir noktada premium şubeden temel şubeye özellikleri seçmeye karar verirseniz, daha zor zaman geçirebilirsiniz. Alt modüllerde bu tür bir değişiklik iki ayrı komisyon olarak temsil edilirken, şubeler ile bu temel sürüme tek bir bağlılık olacak ve premium sürüme bir sonraki birleşme bu değişikliklerin zaten dahil edildiğini ve sahip olmadıklarını bilecektir. tekrar birleştirilmek üzere.

“Donanım” da bu sıklıkla yapılır, karışıklığı kontrol altına almak için satılan sistemlerdir, üzgünüm ne dediklerini hatırlayamıyorum.

“Orta menzilli” çamaşır makinesi gönderildikten sonra, birkaç ay sonra gönderilen “düşük uçlu” çamaşır makinesinde aynı kod değiştiğinde bile, çok önemli bir hata düzeltmesinden başka bir kod değişmez.

Müşteriler, daha önce getirdikleri bir çamaşır makinesinde yükseltme yapmayı beklemiyorlar, birkaç ayda bir yeni bir model de sunulmuyor.

Birçoğumuz o dünyada yaşamıyoruz, bu yüzden çamaşır makineleri için yazılım yazmıyorsanız Greg'in söylediklerini yapın.