Çok bileşenli bir projeyi sürümlendirmenin en iyi yolu nedir?

5 ana bileşenden oluşan bir programım var. Standart sürüm numaralandırmasını çok sınırlayıcı buluyorum çünkü her bir bileşenin hangi sürümde olduğunu görmek istiyorum.

Herkes bunu ayrı ayrı listelemek dışında bunu yapmanın kolay bir yolunu buldu mu?

Ürünümüzle aynı sorunu yaşıyoruz ve her bileşen için ayrı sürüm numaraları yapmaya karar verdik ve ürün sürümü yalnızca belirli bir revizyondaki çeşitli bileşenlerden oluşan bir pazarlama sürümüdür.

Belirli bir bileşen yapılandırmasını açıklayan standart bir sürüm numarası olan bir "sistem sürümü sürümümüz" var, daha sonra ayrı bir dosya söz konusu sistem sürümü için ayrı bileşen sürümlerini listeler. Müşteriler 5.2.1 diyorlar, ancak gerekirse bireysel yapıyı arayabiliriz. Genellikle büyük bir sürüm için tüm ayrı sürümleri senkronize ederiz, böylece her şey tekrar aynı şube numarasından oluşturulur.

Sürüm oluşturma, bileşen tabanlı uygulama geliştirmeden ayrı bir sorundur. Ya her bir bileşeni sürümlendirmek ya da tüm uygulamayı sürümlendirmek istiyorsunuz.

Sürüm oluşturma için iyi bilinen bir model Microsoft'tan :

major version.minor version.build number.revision

Örneğin, .NET platformundaki DLL dosyalarının 2.0.3600.1 veya bunun gibi bir sürümleri olduğunu görebilirsiniz.

Bu nedenle, önce tüm sistemi veya bileşenlerini sürümlendirmek isteyip istemediğinizi belirlemenizi öneririz. Tüm sistemi sürümlendirmek istiyorsanız, her entegrasyondan sonra projenin tamamını derleyin ve derleme numarası bölümünü artırın . Değilse, her bileşeni derlemede sürümlendirin.

Sürüm oluşturma konusunda dikkatli olun, sizi öldürebilir :-) İşleri çok karmaşık hale getirmeye çalışmayın.

Aşağıdaki yaklaşımın size yardımcı olabileceğini düşünüyorum:

İstediğiniz sürüm şemasıyla her bileşeni ayrı ayrı sürümleyin. Yorumlarınızdan, yerinde bir VCS'niz olduğunu anlıyorum. Ayrıca her bileşenin, sürümünün tutulduğu bir dosyaya sahip olduğunu varsayıyorum (doğru?). Günde / haftada bir kez (ekibiniz için hangisi daha iyi çalışıyorsa), VCS'deki en son revizyonlardan birine bu revizyonu en son resmi revizyon olarak işaretleyen (ve isteğe bağlı olarak bir süper revizyon numarasını arttıran) bir etiket ekleyin. Şimdi VCS'yi bu etiketle yapılan düzeltmeler için sorgulayabilir ve ardından bu resmi derlemedeki bileşenlerin sürümünü arayabilirsiniz.

Yalnızca yerel olarak istiyorsanız, kodda depolanan yerden her bileşenin sürümünü toplayacak küçük bir komut dosyası yazın.

Daha da zengin hale getirmek istiyorsanız, etiketlemeyi yaptıktan sonra, belirli bir bileşene ait dosyaları tanımlayabileceğinizi göz önünde bulundurarak, her bileşene ait dosyalara bakabilirsiniz. Herhangi bir değişiklik olursa, söz konusu bileşenin sürümünü artırın. Alternatif, bunu manuel olarak yapmaktır. Başka bir alternatif, dallanma ve birleştirmenin sürüm izleme ile birleşimidir.

Çoğu sürüm numarası, pazarlama tarafından yönlendirilen büyük ve küçük bir düzeltme kullanır, bu nedenle bunları ayrı bileşen sürümlerini izlemek için kullanamazsınız. Kısacası, sürümün ayrı bileşenlerin sürümlerini izlemek için kullanabileceğiniz başka bir bölümünü bulmanız ve tüm paketi izlemek için büyük ve küçük sürüm numaralarını ayırmanız gerekir.

Microsoft modeline benzer bir şey izliyorsanız:

major-version.minor-version.build-number.revision

Her bir bileşenin sürümünü izlemek için .revision öğesini kullanabilir ve her zamanki gibi tam bir ürün değişikliğini izlemek için küçük ve büyük revizyon numaralarını kullanabilirsiniz.

Buna benzer bir desen izliyorsanız:

Major-Version.Minor-Version.Build-Number

Tek tek bileşen sürümlerini izlemek için derleme numarasını kullanmanız gerekir.

Versiyon yazılımı hakkında bütün kitaplar yazılmıştır.

İşte benim kullandığım bir yaklaşım.

Her bölümün bir sürümü vardır:

major.minor.developmental

Bunların her biri 0'dan başlayan bir sayıdır.

Resmi bir sürüm için (yani müşteriler için), gelişimsel kısım, politika olarak daima 0 olmalıdır.

Binbaşı pazarlama kararı ile artırılır.

Küçük, piyasaya sürülen özellik kümeleri tarafından artırılır.

Misal:

• Yeni bir bileşen üzerinde geliştirmeye başladım, bu yüzden sürüm numaram 0.0.1 olacak. Örneğin, dahili testler için masamı meslektaşlarıma bıraktığımda, geliştirme numarası 0.0.2, 0.0.3'e kadar yükselir.

• Bu yeni şeyi piyasaya sürdüğüm 1.0.0 sürümüyle piyasaya sürdüm, burada geliştirme sonundan serbest bırakılmasına izin verilen tek değişiklik sürüm numarasını değiştirmekti (örn.

• Bazı yeni özellikler eklenecektir. Bu özellikleri ekleyerek 1.0.0 taban çizgisi üzerinde çalışmaya başladım, böylece meslektaşlarıma test etmek için serbest bıraktığım sürümler 1.0.1, 1.0.2, vb.

• Bir sonraki özellikler 1.1.0 olarak piyasaya sürüldü.

• Pazarlama, bir sonraki büyük şeyin gerçekten büyük olacağına karar verdi, bu yüzden 2.0.0 olarak çıkacak. 1.1.1 üzerinde çalışmaya başlıyorum, 1.1.x'e geçiyorum ve 2.0.0 olarak çıkıyorum.

Ve böylece döngü tekrar eder.

Bu yaklaşım, her bileşen için, ataların izlenebilirliğini sağlar.

Kaynak (ve nesne) revizyon yönetim sisteminizin içinde, gelişimi yönetmek için şubeleri ve etiketleri (günün terminolojiniz ne olursa olsun) kullanın.

Revizyon kontrolünüz daha sonra her bir bileşeni, her biri için geliştirme dalları ve etiketler / etiketlerle tamamen ayrı olarak yönetebilir. Veya hepsini bir araya toplayabilirsiniz, bu durumda iş paketine göre dallanmak isteyebilirsiniz - ancak her bir bileşenin serbest bırakılmasıyla etiketlediğinizden / etiketlediğinizden emin olun (ve bunu yaptığınızda, her şeyin etiketlemesini / etiketlemesini unutmayın. Bu şekilde, o anda her şeyin durumunun bir anlık görüntüsüne sahip olursunuz.)

Serbest bırakma süreciniz dikkatli bir düşünce gerektirecektir. Bu yaklaşımı kullanmak bazı manuel adımlar içerir ve bu istenmeyen bir durum olabilir - bu, tüm sürüm sisteminizin sürüm numaralarını son nesneye nasıl aktardığına bağlıdır. Sürüm numaralarının sadece sayılar olarak adlandırıldığı çok gömülü kod için (örneğin, C kodunda #defined), bunu yine de elle yapmaktan başka bir seçeneğiniz yoktur. Güzel GUI'lere sahip masaüstü platformları genellikle bunu daha kolay hale getirir.

özet

Benim için sürüm yazılımını kullanmanın tek güvenilir yolu sürüm kontrol sisteminizden karma veya changeet tanımlayıcısını kullanmaktır .

Genel bir derleme sürüm numarası yararlı olabilir, ancak yalnızca bir derleme sunucunuz varsa ve / veya her sürümü imzalarsanız benzersiz olması garanti edilir. Birçoğumuz için bu geçerli değil.

Projeniz birden çok sürüm kontrol havuzuna bölünmüşse, kullanıcı arayüzünüzün her bağımlı havuzu sorgulayabileceği ve karma değerini kullanıcıya geri bildirebileceği bir mekanizma oluşturmanız gerekecektir.

Kişisel deneyimlerden örnek

Önceki bir işverendeki, (dahili) müşteri değiştirme yazılımımızla sorunları yeniden derlediğimiz ve derlediğimiz bir projede, cıva karmaları her bir uygulama ve kütüphaneye derlendi. Yazılım her başlatıldığında, tüm yazılım bileşenleri sorgulanarak bir revizyon dizesi oluşturuldu.

Bu düzeltme dizesi, yaklaşık sayfaya gittiğinizde görüntülenir ve uygulama her başlatıldığında günlük dosyasına yazılır. Şu şekildeydi:

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

Bundan kolayca Library3'ü değiştirdiklerini ve depoda bu değişiklikleri yapmadıklarını görebiliyordum, bu yüzden kontrol edilmeyen bir kod kullanıyorlar. Ayrıca karmaları mevcut test sistemimle karşılaştırabilirim, böylece Library1'i daha eski bir sürüme geri döndürdüklerini belirleyebilirim.

Bu, bir hata bildirdiklerinde, sorunun oluştuğu sırada kullanılan kodu tam olarak yeniden oluşturabileceğim veya en azından kurulumu yeniden üretemediğimden emin olabileceğim anlamına geliyordu.

Kullandığım derleme sistemi, bunu nasıl başardığım, yaşadığım sorunlar ve insanların bunlardan kaçınmak için önerdikleri şeyler hakkında daha fazla bilgi için Stack Overflow sorumuna bir göz atın .

Not: Bu sistem, yalnızca belirli bir karmanın, belirli bir çalışma dizini bir dosya karışımı içerebiliyorsa, çalışma dizininizde aynı dosya kümesiyle (örneğin git ve mercurial) sonuçlanacağı garanti edilen bir revizyon kontrol sistemi kullanırsanız gerçekten geçerlidir. ve birkaç revizyondan (örn. svn) gelen dizinler, çalışma dizininin durumu ile ilgili tüm bahisler kapalıdır ve bu yöntem hiç çalışmaz.