Çevikte anlamsal sürüm oluşturma


10

Diyelim ki yeni özellikler, birkaç iyileştirme ve düzeltilecek bazı hatalar için birkaç hikayem olan 14 günlük sprint yinelemelerim var. Bu değişiklikleri hazır olduklarında da dağıtıyorum, sprint sonu için beklemiyorum.

Benim sorunum - bu şekilde geliştirilen ve sürdürülen ürünlerin anlamsal sürümlerini nasıl izleyebilirim? Her 14 günde bir yayınlanacaksa, kolay olacak, sürüm numarasını artıracağım ve changelog'daki tüm değişiklikleri not edeceğim. Peki ya değişiklikler sürekli olarak uygulanırsa? Her şey konuşlandırıldığında sürüm artırılmalı mıdır? Yoksa sprint bitene kadar beklemeliyim ve bundan sonra, bir miktar "devam et" yapmalı ve gerçek dağıtımda bağımsız olarak yineleme başına sadece bir kez sürüm numarasını artırmalı mıyım? Agile'da semantik sürüm oluşturma için en iyi uygulamalar nelerdir?

EDIT: İhtiyaçlarımı daha iyi açıklamak için öncelikle paydaşlar için değişim günlüğü istiyorum. Her değişiklik yapıldıktan sonra changelog'da yeni kayıtla ilgileneceklerini sanmıyorum.



"Anlamsal versiyonlama" ile ne demek istiyorsun? Sürüm numarası oluşturma günü mü?
k3b

2
@ k3b: Google'ı deneyin. Semver.org'a
Doc Brown

3
Sprint ortasında kime dağıtıyorsunuz? Doğrudan son kullanıcıya mı? Bazı test kullanıcılarına mı?
Doc Brown

@DocBrown doğrudan son kullanıcılara. Bir şey yapıldığında üretime dağıtılır.
Pavel Štěrba

Yanıtlar:


7

Tipik sürüm yönetimi için, DLL'lerin her dağıtıldığında sürümlendirilmesi için derleme sisteminiz tarafından bir derleme numarası oluşturulmasını istersiniz. Bu, daha sonra belirli bir sunucuda hangi sürümün dağıtıldığını kontrol edebilmenizi sağlar.

Genellikle sürüm notlarına yerleştirilen veya sitenizde yayınlanan 'pazarlama' sürümünüz her sürümde güncellenmemelidir. Bu sürüm notları biriktirilmeli ve gruplandırılmalıdır, muhtemelen sprintinizin sonuna göre zamanlanmalıdır.


Evet, changelog'un bu "pazarlama" sürümü tam olarak ihtiyacım olan şey. Teknik olmayan paydaşlar için bile kolayca okunabilir hale getirin.
Pavel Štěrba

6

Klasik anlamsal sürüm oluşturma şeması "MAJOR.MINOR.PATCH" mantıklıysa, kime dağıttığınıza ve özellikle son kullanıcıya ne zaman ve ne sıklıkta dağıttığınıza bağlıdır . Şema en çok 4.5.0 ile başladığınız kararlı sürüm "4.5" ile çalışıyorsanız yararlıdır. 4.5.1, 4.5.2 ve benzeri sürümler yalnızca hata düzeltmeleri içerirken, dahili olarak 4.6 sürümü üzerinde çalışmış olursunuz.

Örneğin, son kullanıcınıza bir "kararlı dal" sağlarsanız, ilk dağıtım için 4.5.0 ve yama eklediğinizde 4.5.1, 4.5.2 sürümünü verin. Dahili "çevik" geliştirme ve sprint dağıtımınızda, bir 4.6 sürümüne sahip olabilirsiniz, sadece "beta sürümü" olarak adlandırın. Sprint ortasında her dağıttığınızda, "4.6.beta build 123" gibi otomatik oluşturulan derleme numarasını ekleyin. Sprintiniz sona erdiğinde, ona "4.6.0" atayın ve bir sonraki sprint için sürüm numarasını dahili olarak "4.7" olarak değiştirin. ".0" ile başlamak yalnızca bir kuraldır, beta sürümlerini etiketlemek için ".0" kullanabilir ve son kullanıcılarınız için ".1" ile başlayabilirsiniz. IMHO "beta" kelimesi çok daha etkileyici ve herkese sprint'in "henüz tamamlanmadığını" söylüyor.

Her beta sürümüyle tam bir son kullanıcı değişiklik günlüğü çıkarırsanız, ancak en azından sprint sonunda değişiklik günlüğü tamamlanmalı ve son kullanıcıya bir hata düzeltmesi yaptığınızda, tarih belgeleri.

Inkscape, Firefox veya 7-zip gibi birçok açık kaynak ürününde iki ayrı dal, bir anlamsal sürüm numarasına sahip bir "kararlı" dal ve yapı numaraları veya benzer bir şeyle işaretlenmiş bir "geliştirme dalı" serbest bırakma stratejisini bulacaksınız.

Bununla birlikte, ayrı kararlı ve geliştirme dalları ile çalışmaz ve son kullanıcıya günlük olarak yeni bir sürüm yayınlarsanız, günlük sürüm numarasını da artırmanız gerekir. Böyle bir durumda, "4.5.1", "4.5.2", ... sürüm numaraları muhtemelen bireysel dağıtımlarınızı yansıtır ve hata düzeltmeleri ile diğer değişiklikler arasındaki farkı göstermez. Tamam olabilir, artık sadece klasik "anlamsal sürümleme" değil. Bu senaryoda, gerçek bir fark vermeyen 4.5, 4.6, 4.7, 4.8 sürümlerini de dağıtabilirsiniz.

Değişiklik günlüğünüzdeki girişler hakkındaki sorunuzla ilgili olarak: Son kullanıcı tarafından bir şey göründüğünde IMHO, değişikliği dağıtır etmez değiştirmez bir girişe değer. Örneğin, özellik arasında geçiş yapar ve henüz kullanıcı tarafından etkinleştirilmemiş olan yarı pişmiş bir özellikte değişiklik yaparsanız, bu bir changelog'a ait değildir. Kullanıcıda görünür bir değişiklik olmadan yalnızca yeniden düzenleme yapıyorsanız, bu bir changelog'a ait değildir. Bazı kullanıcıları etkileyebilecek bir hatayı düzeltirseniz, bu kesinlikle changelog'a aittir - ve bugfix'i dağıtırken aynı zamanda burada belirtilmelidir. Günlük veya aylık veya yıllık olarak yayınlamanızın bir önemi yoktur.


3

Yapı numaralarını kullanırdım. Genellikle bir yapı numarası sürüm kontrol sisteminin en yüksek sürümüne karşılık gelir. Pazartesi yapı numarası 1745 ise ve salı günü 5 değişiklik yapılmışsa, salı akşamları yapı numarası 1750 olur.

Ardından 1745 ile 1750 arasında değişenlere kısa bir özet yapın.

Ardından, sisteminizin sürüm numarasını her güncellediğinizde, son sürüm numarasından yeniye değişiklikleri almak için derlemelerdeki tüm kısa özetleri ekleyebilirsiniz.


3

En az birkaç yıldır kullandığım tercih ettiğim yöntem, her hikaye tamamlandıktan sonra sayıyı arttırmak. Bu, sprint sonunda yayınlanan sürümlerin sürekli olmayacağı anlamına gelir, örneğin 1.2.3'ten sonra 1.4.0 yerine 1.5.2 bulabilirsiniz.

Değişiklik günlüğünde, ara sürümleri ilgili açıklamalarıyla birlikte listeleyebilir veya tüm değişiklikleri "yayınlanmış" sürümde gruplandırabilir ve sürümleri atlayabilirsiniz.

Başlangıçta, kullanıcıların sürüm numaraları arasındaki "delikleri" sorunlu bulacağından korkuyordum, ancak bir kez öğrendiklerinde, pratikte bir sorun değil. En büyük avantajı, her öyküden sonra sayının artırılmasının süreci daha az hataya yatkın hale getirmesidir - bir sonraki sürüm numarasının ne olacağına karar vermek için tüm çalışmayı 2 haftadan kontrol etmeniz gerekmez - tek bir hikayeye bakıldığında açıktır . Ayrıca, her sürüm arasındaki sürüm numaralarındaki "sıçramalar", sürümde kaç değişikliğin meydana geldiğine dair kabaca bir tahmin verir. Sonuçta, bu sistemin iyi çalıştığını buldum (bu şirket içi müşterilerle yapıldı, ancak zaten çevik bir serbest bırakma döngüsünde çalışıyorsanız, dış müşteriler için de çalışmalıdır).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.