Sürüm oluşturma, çok tutkulu olduğum ve kullanımı kolay bir sürüm oluşturma sistemi bulmak için uzun zaman harcadığım bir şey. Sorunuzda daha önce söylediklerinizden, önemli bir noktayı anladığınız açıktır, montaj sürüm numaraları ürün sürümü ile eşanlamlı değildir. Biri teknik olarak, diğeri ise işletme tarafından yönlendirilir.
Aşağıda, bir tür kaynak denetimi ve bir yapı sunucusu kullandığınız varsayılmaktadır. Bağlam için TeamCity ve Subversion / Git kullanıyoruz. TeamCity az sayıda (10) proje için ücretsizdir ve çok iyi bir yapı sunucusudur, ancak bazıları tamamen ücretsiz olan başkaları da vardır.
Sürüm numarası ne anlama geliyor?
Bir versiyonun bir kişi için anlamı, diğerinden farklı bir şey anlamına gelebilir, genel yapı majör, minör, makro, mikrodur. Bir sürüm numarasına bakma şeklim, onu iki parçaya ayırmaktır. İlk yarı ana sürümü (Ana) ve tüm önemli güncellemeleri (Küçük) açıklar. İkinci yarı, ne zaman yapıldığını ve kaynak kod sürümünün ne olduğunu gösterir. Sürüm numaraları ayrıca bağlama göre farklı anlamlar ifade eder, API, Web Uygulaması vb.
Major. Minor. Build.Revision
Revision Bu, gerçekte neyin inşa edildiğini belirlemek için kaynak kontrolünden alınan sayıdır.BuildBu, yapı sunucusunda belirli bir yapıyı bulmak için kullanılabilecek sürekli artan bir sayıdır. Bu önemli bir sayıdır, çünkü yapı sunucusu aynı kaynağı farklı bir parametre kümesiyle iki kez oluşturmuş olabilir. Derleme numarasını kaynak numarasıyla birlikte kullanmak, neyin inşa edildiğini ve nasıl yapıldığını belirlemenizi sağlar.MinorBu yalnızca genel arayüzde önemli bir değişiklik olduğunda değişmelidir. Örneğin, bir API ise kod tüketmeye devam edebilir mi? Ana numara değiştiğinde bu sayı sıfırlanmalıdır.Majorürünün hangi sürümünde olduğunuzu gösterir. Örneğin, tüm VisualStudio 2008 derlemelerinin Binbaşı 9 ve VisualStudio 2010 10'dur.
Kural istisnası
Kuralın her zaman istisnaları vardır ve bunlara rastlarken uyum sağlamanız gerekir. Orijinal yaklaşımım yıkımı kullanmaya dayanıyordu ama son zamanlarda Git'e taşındım. Merkezi havuz kullanan yıkım ve kaynak güvenliği gibi kaynak kontrolü, belirli bir zaman dilimindeki belirli bir kaynak kümesini tanımlamak için kullanılabilecek bir sayıya sahiptir. Git gibi dağıtılmış bir kaynak kontrolü için durum böyle değildir. Git, her geliştirme makinesinde dağıtılmış depolar kullandığından, kullanabileceğiniz otomatik artan bir sayı yoktur, check-in sayısını kullanan bir saldırı vardır, ancak çirkin. Bu nedenle yaklaşımımı geliştirmek zorunda kaldım.
Major. Minor. Macro.Build
Revizyon numarası gitti, derleme revizyonun olduğu yere kaydırıldı ve Makro eklendi. Makroyu uygun gördüğünüz gibi kullanabilirsiniz, ancak çoğu zaman yalnız bırakıyorum. TeamCity'i revizyon numarasından kaybedilen bilgileri derlemede bulabildiğimiz için, bu iki adımlı bir süreç olduğu anlamına gelir, ancak hiçbir şey kaybetmedik ve kabul edilebilir bir uzlaşmadır.
Ne ayarlanır
Anlaşılması gereken ilk şey, Montaj Sürümü, Dosya Sürümü ve Ürün Sürümü'nün eşleşmesi gerekmemesidir. Farklı sayı kümelerine sahip olmayı savunmuyorum, ancak bağımlı derlemeleri yeniden derlemeye zorlanmadığınız herhangi bir genel arabirimi etkilemeyen bir mecliste küçük değişiklikler yaparken hayatı çok daha kolay hale getiriyor. Bununla başa çıkmak için yalnızca Derleme Sürümünde Büyük ve Küçük sayılar ayarlamak ama Dosya Sürümü'ndeki tüm değerleri ayarlamaktır. Örneğin:
- 1.2.0.0 (AssemblyVersion)
- 1.2.3.4 (Dosya Sürümü)
Bu, derleme sürümleri eşleşmediği ancak dosya sürüm numarasına bakarak bir derlemenin revizyonunu / derlemesini görmenize izin verdiği için mevcut kodu bozmayacak olan düzeltmeleri kullanıma sunma olanağı sağlar. Bu yaygın bir yaklaşımdır ve montaj ayrıntılarına baktığınızda bazı açık kaynaklı montajlarda görülebilir.
Takım sorumlusu olarak, herhangi bir değişiklik yapılması gerektiğinde küçük sayıyı arttırmak sizin sorumluluğunuzdadır. Bir arabirimde gerekli bir değişikliği uygulamak, ancak önceki kodu kırmamak için bir çözüm, geçerli olanı eski olarak işaretlemek ve yeni bir arabirim oluşturmaktır. Bu, mevcut kodun, yöntemin eski olduğu ve herhangi bir zamanda kaldırılabileceği konusunda uyarıldığı, ancak her şeyi derhal kırmanızı gerektirmediği anlamına gelir. Daha sonra, her şey taşındığında kullanılmayan yöntemi kaldırabilirsiniz.
Birlikte nasıl bağlanır
Yukarıdakilerin hepsini manuel olarak yapabilirsiniz, ancak çok zaman alıcı olurdu, süreci nasıl otomatikleştirdiğimiz aşağıdadır. Her adım çalıştırılabilir.
- Tüm proje AssemblyInfo.cs dosyalarından
AssemblyVersionve AssemblyFileVersionözniteliklerini kaldırın .
- Ortak bir montaj bilgi dosyası oluşturun (bunu VersionInfo.cs olarak adlandırın) ve tüm projelerinize bağlantılı bir öğe olarak ekleyin.
- "0.0.0.0" değerleriyle sürüme ekleyin
AssemblyVersionve AssemblyFileVersionöznitelikler ekleyin .
- Çözüm dosyanızı oluşturan bir MsBuild projesi oluşturun.
- VersionInfo.cs dosyasını güncelleştiren derlemeden önce bir görev ekleyin. Sürüm numarasını ayarlayabilen bir AssemblyInfo görevi içeren bir dizi açık kaynak MsBuild kütüphanesi vardır. Sadece rastgele bir sayıya ayarlayın ve test edin.
- Yapı numarasının her bir segmenti için bir özellik içeren bir özellik grubu ekleyin. Büyük ve küçük olanı burada ayarlıyorsunuz. Derleme ve düzeltme numarası bağımsız değişken olarak iletilmelidir.
Yıkım ile:
<PropertyGroup>
<Version-Major>0</Version-Major>
<Version-Minor>0</Version-Minor>
<Version-Build Condition=" '$(build_number)' == '' ">0</Version-Build>
<Version-Build Condition=" '$(build_number)' != '' ">$(build_number)</Version-Build>
<Version-Revision Condition=" '$(revision_number)' == '' ">0</Version-Revision>
<Version-Revision Condition=" '$(revision_number)' != '' ">$(revision_number)</Version-Revision>
</PropertyGroup>
İnşallah net oldum ama çok şey var. Lütfen sorularınızı sorun. Daha özlü bir blog yayını bir araya getirmek için herhangi bir geri bildirim kullanacağım.