Yazılım sürüm numaralarını VCS'de saklamak iyi bir uygulama mıdır?

Gibi bir ürün sürümü, v1.0.0.100yalnızca yazılımın benzersiz bir üretim sürümünü değil, aynı zamanda söz konusu ürün için özellik kümelerini ve düzeltme aşamalarını tanımlamaya yardımcı olur. Şu anda bir ürünün nihai paketini / derlemesini / ikili sürümünü korumanın iki yolunu görüyorum:

1. Sürüm Kontrolü Bir yerde bir dosya sürüm numarasını saklar. Sürekli Entegrasyon (CI) derleme sunucusunda, gerekli olan tüm yazılım alanlarına (ikili dosyalar, yükleyici paketleri, yardım sayfaları, belgeler vb.) Uygulamak için bu iade edilmiş sürüm numarasını kullanan yazılımı derleyen bir komut dosyası olacaktır.

2. Çevre ve / veya yapı parametreleri. Bunlar sürüm kontrolü dışında tutulur (yani, enstantane / etiket / dalla ilişkilendirilmezler). Derleme komut dosyaları, sayıyı aynı şekilde dağıtır ve kullanır, ancak değeri farklı bir şekilde elde ederler ( kodun kaynak ağacına göre nereden alınacağını bilmesi yerine, derleme komut dosyasına sağlanır ).

İlk yaklaşımla ilgili sorun, ana hatları kullanarak birleşmeleri karmaşık hale getirmesidir. Aynı yazılımın 2 paralel yayınını hala koruyorsanız, sürüm son birleşmeden bu yana her ikisi de değiştiyse, iki ana hat arasında birleştiğinde çakışmaları çözeceksiniz.

İkinci yaklaşımla ilgili sorun uzlaşmadır. 1 yıl önce bir yayına geri döndüğünüzde, sürüm numarasını tanımlamak için yalnızca etiket bilgisine güvenirsiniz.

Her iki durumda da, CI derlemesinden önce bilinmeyen sürüm numarasının belirli yönleri olabilir. Örneğin, bir CI derlemesi programlı olarak gerçekten otomatik derleme numarası olan dördüncü bir bileşene yerleştirilebilir (ör. Daldaki 140. derleme). Ayrıca VCS’de bir revizyon numarası olabilir.

Bir yazılımın sürüm numarası ile yetişmenin en iyi yolu nedir? "Bilinen" parçalar daima VCS'de tutulmalı mı? Ve eğer öyleyse, ana hattaki çatışmalar bir sorun mu oluşturuyor?

Şu anda sürüm numaramızı CI yapım planında (Atlassian Bamboo) belirtilen ve sürdürülen parametrelerle koruyoruz. Şubemize katılmadan önce , CI inşaatı başlamadan önce mastersürüm numaralarının doğru şekilde ayarlandığından emin olmalıyız . Gitflow iş akışıyla ilgili olarak, sürüm numarası kaynak denetiminde izlenirse, sürümün releasehazırlanmasında şubemizi oluştururken düzgün şekilde kurulmasını garanti edebileceğimizi hissediyorum . KG, bu dalda nihai entegrasyon / duman / regresyon testini gerçekleştirecek ve imzalandığında, masterserbest bırakma taahhüdünde bulunan bir birleşme gerçekleşecek.

Şahsen, ben seçenek 3'ü seçiyorum: sürüm bilgilerini VCS meta verilerinde , özellikle etiketlerde tutmaya devam et .

Git bunu yapmayı çok kolaylaştırıyor, çünkü git describebir etikete dayanan bir taahhüdü benzersiz bir şekilde tarif edebilecek bir komut var . İşte nasıl çalışıyor:

• Geçerli taahhüt etiketlendiyse, etiketin adını yazdırın.
• Eğer çıktılı sonra aşağıdaki biçimde bir açıklama etiket bulmak ve kadar Aksi halde, tarih geriye doğru yürümek: <tag>-<number of commits since the tag>-g<abbreviated commit hash>.
• Worktree'de kabul edilmemiş değişiklikler varsa, ekleyin -dirty.

Dolayısıyla, bir sürüm oluşturma işlemi yapıyorsanız ve taahhüdünüzü etiketlemişseniz 1.2.3, çıktı verir 1.2.3. Halen 1.2.4 üzerinde çalışıyorsanız ve 1.2.3'ten beri 4 görevde bulunduysanız ve ağaçta değişiklik yapmadıysanız, çıktı verir 1.2.3-4-gdeadbee-dirty.

Bu, benzersiz ve monoton olduğu kadar insan tarafından okunabileceği ve bu nedenle doğrudan sürüm dizgisi olarak kullanılabileceği garantilidir . Sağlamanız gereken tek şey etiketler için uygun bir adlandırma kurallarıdır.

Evet. Sürüm numarasının çoğunu vcs biçiminde tutmak iyi bir uygulamadır. Eğer major.minor.patch.build olan semantik versiyonlama semver.org'u dikkate alırsak, ilk üçünün vcs içinde yaşaması gerekir. Sonuncusu, bir binaryin yapıldığı belirli taahhüdü geri almak için kullanılan derleme sunucunuzdaki artan bir sayı olabilir.

Bunu .NET'te kolaylaştırmak için, gitmeyi taahhüt eden küçük bir cmd satır exe yaptık. Bir derleme öncesi olayla birlikte, ekip takımının derleme sırasında etiketlediği derleme numarasını alır. Bu cmd çizgi aracı otomatik derleme numarasını içeren bir sabit olan bir sınıf oluşturur. Sürüm numarasının geri kalanı: major.minor.patch başka bir dosyada sadece normal bir sabittir. Bu iki paylaşılan dosya her montajda bir bağlantı olarak bir çözüme dahil edilir (alt + shift-drag).

Bu yaklaşım ekip takımımızın kodumuzu oluşturması ve test etmesi için yeterince güçlü. Azure'a bastırın ve kudu'yu yeniden inşa ettirin, ancak takımın derneği dll'lerin versiyonu olarak derleyin.