Uzun vadeli projelerin ürün sürümlendirmesini ve dallanmasını ele almanın en iyi yolu nedir?

Genel anlamda, ürünlerin yaşam döngüsü boyunca birden fazla sürüm alabilen ve önceki ürünlerin desteğini gerektiren uzun vadeli projeler için, ürün sürümlerini ve kod tabanının dallanmasını ele almanın en iyi yolu nedir?

Daha spesifik olarak, uygun dağıtılmış sürüm kontrolünün (yani git) yerinde olduğunu ve ekiplerin küçükten büyüğe kadar olduğunu ve geliştiricinin aynı anda birden fazla proje üzerinde çalıştığını varsayalım. Karşılaşılan en büyük sorun, eski sürümleri destekleme konusunda sözleşmeye bağlı bir zorunluluk olduğu ve yeni geliştirmelerin eski kodları yamalayamayacağı anlamına gelir (Microsoft Office ürünleri bunun bir örneği olabilir, yalnızca sahip olduğunuz yıl).

Sonuç olarak, mevcut ürün versiyonlaması, her ana ürünün, her biri yıllık sürümler arasında değişebilen kendi versiyonlarına sahip birden fazla bağımlılığa sahip olduğu için kıvrımlı bir dokunuş. Benzer şekilde, her ürünün kendi havuzu olmasına rağmen, işin çoğu ana kaynak gövdesinde değil, o yıl için bir ürün dalında, ürün piyasaya sürüldüğünde yeni bir dal ile desteklenebilmesi için yapılır. Bu, bir ürünün kod tabanını almanın, sürüm kontrolünü kullanırken düşünebileceği gibi basit bir mesele olmadığı anlamına gelir.

Ne kadar (ve ne tür) bir yapıya ihtiyacınız olduğu, ne yapmak istediğinize çok bağlıdır. Neler olmadan yaşayamayacağınızı, neye sahip olmak istediğinizi ve neyi umursadığınızı bulun.

İyi bir karar kümesi örneği şunlar olabilir:

Onsuz yaşayamayacağımız şeyler:

• geçmiş bir sürümü istediğiniz zaman yeniden oluşturabilir
• istediğiniz zaman ürünün birden fazla desteklenen ana sürümünü koruyabilme

Sahip olmak istediğimiz şeyler:

• şube birleşmeleri hakkında endişelenmeden devam eden ana özellik geliştirme (bir sonraki büyük sürüm için) yapabilme
• geçmiş sürümlerde bakım güncellemeleri yapabilir

Olmadan yaşayabileceğimiz şeyler:

• mevcut işten geçmiş sürümlere kadar değişikliklerin otomatik olarak geri raporlanması
• ana özellik geliştirmeyi asla birkaç gün veya bir hafta boyunca bile kesmeyin

Yukarıdaki hedefleriniz olsaydı, böyle bir süreci benimseyebilirdiniz:

1. Tüm geliştirme işlerini VCS'nizin gövdesinde yapın ("master" git)
2. Büyük bir sürüme yakın olduğunuzda, büyük özellik geliştirmeyi durdurun ve bir hafta kadar sistem kararlılığına odaklanın
3. Bagaj stabil göründüğünde, bu büyük sürüm için bir şube oluşturun
4. Ana özellik geliştirme artık gövdede devam ederken, dalda yalnızca hata düzeltmeleri ve sürüm hazırlığına izin veriliyor
5. Ancak, şubeye yapılacak tüm hata düzeltmelerinin öncelikle gövdede test edilmesi gerekir; bu onların gelecekteki tüm sürümlerde de bulunmalarını sağlar
6. Serbest bırakmaya hazır olduğunuzda dalda bir (VCS) etiketi oluşturun; bu etiket, aynı dalda daha fazla çalıştıktan sonra bile, sürümü istediğiniz zaman yeniden oluşturmak için kullanılabilir
7. Bu büyük sürümün (küçük sürümler) ilave bakım sürümleri artık şubede hazırlanabilir; her biri yayınlanmadan önce etiketlenecek
8. Bu arada, bir sonraki büyük sürüme yönelik önemli özellik geliştirme, bagajda devam edebilir
9. Bu sürüme yaklaştığınızda, söz konusu sürüm için yeni bir sürüm dalı oluşturarak yukarıdaki adımları tekrarlayın . Bu, her biri kendi dalında, aynı anda desteklenen statülerde, her birine karşı ayrı küçük sürümler yayınlama yeteneği ile birden fazla büyük sürümünüz olmasını sağlar.

Bu işlem tüm sorularınızı yanıtlamayacaktır - özellikle, bir sürüm dalında hangi düzeltmelerin yapılabileceğine karar vermek ve ilk olarak hataların bir sürüm dalına sabitlenmemesini sağlamak için bir işleme ihtiyacınız olacaktır (bu tür düzeltmeler) mümkün olduğunca her zaman bagajda test edilmelidir). Ancak size bu tür kararları verebileceğiniz bir çerçeve verecektir.

"Uzun vadeli", sürüm oluşturmaya ihtiyaç duyduğunuz bir göstergedir , ancak belirli bir sürüm oluşturma ve dallanma stratejisi içermez. Daha ilginç olan soru, kaç ürün hattını veya ana sürüm satırını desteklemek istediğinizdir (bu, müşterilerinizle yapılan sözleşmeye bağlıdır). Bakım sözleşmeniz olan her ürün grubu / ana sürüm hattı için en az bir şubeye ihtiyacınız olacaktır.

Öte yandan, takımınızın büyüklüğüne bağlıdır. Büyük bir geliştirme ekibiniz varsa, farklı insanlar paralel olarak farklı özellikler üzerinde çalışıyorlar, açıkçası bir veya iki kişilik ekibiniz olduğundan daha fazla özellik dalına ihtiyacınız olacak. Daha büyük bir ekiple çalışıyorsanız, farklı dallarda paralel çalışmayı (ve daha sonra gövdeye yeniden entegre etmeyi) çok daha verimli hale getiren dağıtılmış sürüm kontrolünü kullanmayı düşünmelisiniz.

Git bir sürüm kontrol aracıdır - dosyaların sürümlerini yönetir. Neyin peşindeyseniz bir yapılandırma yönetim aracıdır. Bunlar mevcut, ancak çoğunlukla IBM gibi yüksek $$$.

Sürüm kontrol araçları, ek araç desteği olmadan rudementy yapılandırma yönetimi sağlayan dallanma ve etiketleme sağlar, bu nedenle menay geliştiricileri farkı anlamıyor. İhtiyaçlarınız muhtemelen GIT'in yapmak için tasarlandıklarının ötesine uzanır.

Git için bir CM aracı eklentisinin farkında değilim, ancak var olacağından eminim.

Bu soru çok benzer gibi görünüyor başka bir soru Bunu cevap geçenlerde.

Kısacası, bu bir ürün tasarımı ve dağıtım problemine bir versiyon kontrol / dallanma probleminden daha çok benziyor. Tabii ki, bunu söylemek benim için kolay ve zaten sorunun derinliklerinde iseniz, düzeltmeniz daha zor.

Sorununuzun ayrıntılarını daha ayrıntılı bilmeden. Genel olarak, ürünler arasında büyük miktarda paylaşılan kod bulunan bir kod tabanına dayalı ürünlerin birden çok sürümüne sahip olsaydım, mümkünse, ürünleri daha modüler hale getirecek şekilde yeniden düzenlemeye çalışırdım. modüllerin kendilerinin ek kod dallaması gerektirmemesini sağlayın. Kod tabanının çoğunu bir arada tutarken müşterilerimi desteklemenin daha iyi bir yolu olup olmadığını görmek için dağıtım modelime de bakarım. Özel müşteri özelleştirmesi gerektiğinde, sistemdeki yinelenen kod miktarını azaltmak için modüllerin daha fazla ayrıntı düzeyi gerekebilir.

Bu kolay bir iş değildir, ancak işi iyi yönetirseniz ve işi zamanlayabilirseniz, böylece her şeyi aynı anda "yükseltmenize" gerek kalmaz.