Sürüm Yönetimi hakkında bir kaç şey
Bu yazıda sürüm türleri ve sürüm yönetiminden bahsetmek istiyorum. Ayrıca bazı araçların çalışma mantığına ve bir iki pratiğe de değinmeye çalışacağım.
Sürüm Nedir?
Bana göre; sürüm kullanıma sunulan yazılım ve diğer şeylerdir.
Apache Vakfının sürüm politikası da sürümü benzeri bir şekilde tanımlıyor.
SÜRÜMÜN TANIMI
Genel olarak, bir sürüm bir grubun adına yayınlanan herhangi bir şeydir. Bir Apache projesi için, bu geliştirici topluluğunun dışındaki herhangi bir yayın olabilir. Bu topluluk geliştirmeye aktif olarak katılan bireyler olabileceği gibi geliştirici bültenlerini takip eden kişiler de olabilir.
DEFINITION OF “RELEASE”
Generically, a release is anything that is published beyond the group that owns it. For an Apache project, that means any publication outside the development community, defined as individuals actively participating in development or following the dev list. Bağlantı
Bizim ve herkesin şu anda hangi sürümü kullandığını bilmesi için kullanıma sunulan sürümlerin numaraları ve içerikleri değişmez kabul edilir.
Bir sürüm isimlendirme yöntemi olan “anlamsal versiyonlama“nın konu ile ilgili maddesi de şöyle;
Sürümlenmiş bir paket sunulduğunda, o sürümün içeriği DEĞİŞTİRİLMEMELİDİR. Yapılan her hangi bir değişim yeni bir sürüm olarak sunulmalıdır. (semver.org — Madde 3)
Genelde bağımlılık yönetimi araçları ve eser depoları da varsayılan olarak buna göre tasarlanmıştır. Sürümleri uzaktaki depodan yerel ortamlarımıza sadece bir kere indirerek aynı sürümü tekrar tekrar indirmeye çalışmazlar. Zamandan ve kaynaklardan tasarruf etmemizi sağlarlar.
Aşağıda üreticisi tarafından kullanıma sunulmuş bir sürümü görüyoruz.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.8.1</version>
</dependency>
Sürüm öncesi geliştirme safhası
Yazılım paketi oluştururken genelde en çok değişiklik yapılan süreç geliştirme sürecidir. Henüz herhangi bir şey kullanıma alınmadığı için büyük değişiklikler normal karşılanabilir ve bu büyük değişiklikler istenen şey de olabilir.
Geliştirme sürecinde hem kendi yerel ortamımızda hem de sürekli tümleştirme ortamında yazılım paketlerini oluşturup, deneyip, işlerin nasıl olduğuna bakarız. Bu esnada oluşturulan paketlere anlık paketler (SNAPSHOT) denir.
Aşağıda bir anlık paket tanımını görüyoruz.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
<version>3.8.2-SNAPSHOT</version>
</dependency>
Anlık sürümler geliştirmenin o andaki halinin bir fotoğrafıdır.
“ŞİPŞAK” (SNAPSHOT)
Geliştirme esnasında oluşturduğumuz paketler anlıktır. İki farklı kişinin bilgisayarında oluşan paketlerinin ikisi de kendi makinelerinde anlık ifadesi (SNAPSHOT) ile etiketlenmiştir. Bu paketleri birbirinden ayıran pek bir şey yoktur. (Paketlerin içeriğine bakarak, üretim zamanlarından bir şeyler çıkarmanız mümkün olabilir ama bu işleri zorlaştıracak bir yöntem olduğu için bu baz alınmaz.)
Bahsettiğimiz bu durum zaten geliştirme sürecinde üretilen paketlerin kullanıma sunulmayacağı için bir problem oluşturmaz.
Genelde eser depoları anlık paketleri ayrı bir anlık deposunda tutarlar. Böylece anlık paketler ile kullanıma hazır paketler arasına belirgin bir çizgi çekerler.
Eser deposu kendisine son gelen anlık paketi, güncel anlık paket olarak kabul eder. Kendisinden geliştirme paketi istendiğinde de bu anlığı verir. Birden fazla anlığın tutulabilmesi ve son gelenin güncel olarak kabul edilebilmesi için arka tarafta zamanı baz alır.
Anlık (SNAPSHOT) ifadesinin genel olarak yazılım dünyasında kabul görmesi sayesinde, biz üzerinde “SNAPSHOT” yazan bir paket gördüğümüzde artık o paket için geliştirmenin devam ettiğini ve o paketi stabil kabul edemeyeceğimizi de anlamış oluruz. Bundan dolayı bizim kullandığımız kütüphanelerin anlık hallerini üretim ortamlarında kullanmamız doğru olmaz, hoş görülmez. Sürüm hazırlama esnasında kimi araçlar bağımlılıkları tarayarak içlerinde bir anlık olmadığını doğrular.
Sürüm öncesi test ve onay safhaları
Geliştirme sürecinin sonuna yaklaştıkça ara sürümler ve sürüm adayları üreterek bunları onaya sunabiliriz.
Ara sürümlerin farklı farklı son-ekler ile tanımlandıkları da olur. Milestone kelimesinin M harfi, alpha, beta kelimeleri gibi. Örneğin; 1.5.0.M1, 1.5.0-alpha-1, 1.5.0-beta-2
Ara sürümler ile tamamlanan işler test ve onaya sunulur. Kalite kontrol ile ilgilenen kişiler ve sistemler bu paketlerde tamamlanan bazı özellikleri önceden edinerek test etme şansını bulmuş olurlar. Bu ara sürümler kimi yerlerde sadece yazılım üreten topluluğunun içerisinde paylaşılırken kimi yerlerde önden giden ve o özelliğe daha fazla ihtiyaç duyan kullanıcılar tarafından da kullanılabilir.
Bir de sürüm adayları (Release Candidates) vardır. İsminden de anlaşılacağı gibi bir çok sürüm adayından bir tanesi sürüm olur. Örneğin 1.5.0.RC1, 1.5.0.RC2 sürüm adaylarından bir tanesi test edilip, onaylandıktan sonra 1.5.0 ile bir sürüm olur.
Bu paketlerin bu adımlardan geçerek bir sürüm haline gelme sürecine eser terfisi (artifact promotion) veya sürüm aşamalandırma (release staging) denir.
Anlamsal Versiyonlama (Semantic Versioning)
Versiyonlama konusunda farklı farklı yaklaşımların işleri dağınık hale getirmesinden dolayı Tom Preston-Werner anlamsal versiyonlama diye bir yöntem oluşturmuştur.
Sürümlendirme konusunda kısa, öz ve pratik bilgiler vermesi açısından bu yöntemin yararlı bir yöntem olduğunu düşünüyorum. Bununla birlikte sıkı sıkıya takip etmek gerekli olmayabilir. Spring altyapısına ait kütüphanelere baktığımızda da bu yöntem ile hafif farklılıklar olduğunu görebilirsiniz.
Sürüm isimlendirmede alfabetik yaklaşım
Spring altyapısının sürüm isimlendirmesi dikkate değer. Aynı zamanda yukarıda sık sık “SNAPSHOT” son-ekinden bahsettik. Spring bunu “BUILD-SNAPSHOT” halinde kullanıyor. Yazılımcılar SNAPSHOT ifadesini görebildikleri için bu bir sorun oluşturmuyor.
Spring’in yolu
1.0.0.BUILD-SNAPSHOT
1.0.0.M1
1.0.0.RC1
1.0.0.RC2
1.0.0.RELEASE
Semver’in yolu
1.0.0
1.0.0-M.1
1.0.0-M.2
1.0.0-RC.1
1.0.0-SNAPSHOT
Spring‘in yukarıdaki yaklaşımı ile yaşam döngüsünün aşamalarını alfabetik olarak görebilmemiz mümkün oluyor. Ayrıca versiyon politikalarını anlattıkları dokümanlarında OSGI ile ilgili teknik bir durumdan da bahsemişler. Bağlantı burada.
Bunlar da klasik versiyonlama konusunda da tek bir doğrunun olmadığını gösteriyor.
Konfigürasyona dikkat
Ortam değişkenleri adını verdiğimiz konfigürasyonların paketin içerisine eklenmesi bazı sorunlar doğuruyor. Test ortamı, geçiş, üretim ortamı gibi ayrı ortamlar için ayrı ayrı paket oluşturılmasına neden oluyor.
Her ortam için ayrı bir sürüm üretmek hem masraflı bir iş hem de sürümü aşamalandırma (release staging, artifact promotion) yaklaşımını ihlal ediyor. Şimdi test ettiğimiz bir sürümü, artık geçişe aktarmak istediğimizde gidip tekrar bir sürüm üreterek, onu kullanmaya çalışırsak iki farklı sürüm ile çalışmış oluyoruz, aynı sürümü test etmiyor, onaylamıyoruz.
Dolayısı ile sürüm yönetiminin bir konusu da paketin içerisine nelerin girmesi yada girmemesi gerektiği. Bu da değerlendirilecek konulardan bir tanesi.
Sürüm yönetimi uygulama yaşam döngüsünün önemli bir parçasını oluşturuyor. Kullandığımız programla ortamının araçları ile daha iyi bir sürüm yönetimine doğru yol olmak mümkün. Buradakiler ve daha fazlası ile ilgili olarak yorumlarınızı beklerim. Görüşmek üzere.
