Sürüm Yönetimi Pratikleri - II

Bir önceki blogumda Sürüm Yönetimi pratiklerine bir giriş yapmış, Sürüm Numarasının Runtime'da kullanımına (Version.class) değinmiştim. Bu yazıda ise diğer kullanım şekillerinden bahsedeceğim.

Version Control Tool

Hangi Versiyon Kontrol aracını (CVS, SVN, ClearCase, StarTeam, vs.) kullanırsanız kullanın tüm bu araçlarda mutlaka bir etiketleme (Tag, Label, vs.) sistemi vardır. Sürümü oluştururken bir önceki blog 'da bahsettiğim Sürüm Numarasını kullanarak, sürüm kapsamına giren java, jsp, xml, html, sql, vs. tüm dosyalara mutlaka etiket atılmalıdır. gibi

Etiketleme işleminde kullanılan Sürüm Numarası genelde en sade formattadır.

Örnek: TestProject_2.1.2_15022006 , TestProject_2.1.2 veya 2.1.2 gibi.

Etiketleme işleminde baz alınacak versiyonların seçimi için 3 yöntemden birini seçebilirsiniz:

1) Development Baseline (Latest Version) Bu yöntemde sürüm zamanı geldiğinde Development Baseline 'ındaki kodların son versiyonlarına etiket atılır. Sürüme dahil edilmek istenmeyen versiyonlar etiketleme öncesi geri alınarak sürüme çıkması engellenir. Bu yöntem genelde bir dosya üzerinde birden fazla kişinin çalışmadığı, küçük takımlardan oluşan, yapılan değişikliklerin kısa sürede sürümlere dahil edildiği projelerde tercih edilir. Bu yöntemde eğer ekip üyeleri dosyalarına ve değişikliklerine hakim ise çok sorun yaşanmaz ama gene de diğerlerine göre en riskli yöntemdir. Etiketleme işlemi tamamlandıktan sonra, etiketlenen dosyalar Production Baseline 'ına transfer edilir.

2) Production Baseline (Latest Version) Bu yöntemde developer'lar sürüme dahil olmasını istedikleri dosyaları kendileri manuel olarak Production Baseline (branch) 'ına transfer ederler. Sürüm zamanı geldiğinde bu baseline 'deki kodların son versiyonlarına etiketleme yapılır. Bu yöntem diğerlerine göre en güvenli olanıdır. Yanlış kodların gönderilmesi gibi hataların önüne bu yöntemle geçilmiş olur. Bu yöntemin en büyük handikapı ise developer'ların sık sık, gerçekten sürüme dahil olması gereken dosyaları bu baseline' a transfer etmeyi unutmalarıdır.

3) Development Baseline (Release Label) Bu yöntemde ise developerlar Development Baseline 'ında sürüme dahil olmasını istedikleri dosyalarının ilgili versiyonlarına TO_RELEASE, TO_TEST, TO_PROD vs. gibi önceden belirlenmiş sabit etiketler atarlar. (ya da kaydırırlar) Sürüm zamanı geldiğinde Sürüm Yönetimi, üzerinde bu sabit etiketten bulunan dosyaların ilgili versiyonlarını sürüm numarası ile etiketler. Bu yöntemde genelde ayrıca bir Production Baseline kullanılmaz.

Bu etiketleme işlemini ister ant yardımıyla otomatik, isterseniz de manual yapabilirsiniz:

Manual Etiketleme çok sık sürümün çıkarılmadığı projelerde en çok tercih edilen yöntemdir. Bu işlem developerlar veya Sürüm Yöneticisi tarafından gerçekleştirilebilir. Dikkat edilmesi gereken nokta ise etiketleme işleminin daha evvelden Sürüm Yönetimi tarafından yayınlanmış tarihte ve saatte yapılmasıdır. Özellikle derleme ve paketleme işlemi belli bir saatte otomatik olarak başlayacaksa zamanlama çok daha önemli olacaktır.

Otomatik Etiketleme genelde periyodik olarak çok sık sürüm çıkarılan projelerde tercih edilen bir yöntemdir. Otomatik etiketleme işlemi, derleme ve paketleme işleminin bir ön işi olarak birlikte gerçekleştirilir. Otomatik yapılan işlemlerde treni kaçıran :) developer sayısı çok olsa da, sürümler sık çıktığı için bir sonraki sefere yetişilerek bu durum kolayca telafi edilebilir.

Genelde developer ve testçi sayısının fazla olduğu büyük projelerde periyodik olarak sürüm zamanları ve numaraları önceden belirlenir ve yayınlanır. Ayrıca bu sürüm numaraları, test sürümleri baz alınarak oluşturulur. Küçük ekiplerin geliştirdiği ve sürümlerin çok sık çıkmadığı projelerde ise sürüm numaları production sürümleri baz alınarak oluşturulur.

Sürüm Yönetimi hakkında konuşacağımız daha çok şey var, bir sonraki blogda görüşmek üzere :)