En basit tarafından baktığımızda, günlük hayatımızda sıkça karşılaştığımız bir şeydir kendisi. Kullandığımız yazılımsal ürünlerin sağında solunda v1.4.3 veya x.y.z gibi numaralandırmalar illaki gözümüze çarpmıştır. Bunlar versiyonlamanın ta kendisidir. Peki neye göre ve nasıl yapılır bu versiyonlama?
Neye göre ve nasıl yapıldığı, firmanın sektördeki pozisyonuna, yaptığı işlere göre tamamen farklılık gösterebilecek bir durumdur. Dünya genelinde sabit bir versiyonlama tekniği olmamakla birlikte, kullanılan teknikler birbirleriyle oldukça benzerdir.
Bu blog postta, bir mobil uygulamanın gelişim sürecini, SHERPA olarak kullanmakta olduğumuz versiyonlama tekniğiyle anlatmaya çalışacağım.
Mobil telefonlarımızın gerek işletim sistemlerinde, gerekse cihaza indirdiğimiz uygulamalarında “abi yeni bir şeyler yaptık, indir de gör” tarzı uyarılar aldığımızda indirdiğimiz şeyler içinde neler vardır ve bunlar nasıl sınıflandırılıp versiyonlanır, önce buna bakalım…
Elimizde bir mobil uygulama olduğunu varsayalım. Uygulamamızın versiyonu yayına alındığı ilk anda 1.0.0 olsun, şimdi de gelen güncellemelerle birlikte versiyonlamanın nasıl yapıldığı kısmına geçelim.
Uygulamamızı güncelledik. Bir de baktık ki; arayüz değişmiş, fonksiyonalitede ciddi farklılıklar var, “yahu ben artık bambaşka bir şey yapabiliyorum” diyebiliyoruz. Alın size majör değişiklik! Uygulamamız, versiyon 2.0.0’ı gurula sunar!
Uygulamamıza bir güncelleme daha geldi. Ve bir de baktık ki uygulamanın bir veya birden fazla kısmına müdahil olabiliyoruz. Veya uygulamanın renkleri değişmiş, veya yazı karakterleri, veya ek bir özelliğimiz daha var… veya, veya… Uygulama oldu mu sana 2.1.0 ?
Bir önceki versiyonda uygulamaya yeni bir özellik gelmişti. Lâkin istediğimiz gibi çalışmıyor. Saha koşulları uygun fakat ters giden bir şeyler var… Evet, yine o şirin “güncelleme var!” uyarısı geldi telefonumuza. Altında da açıklaması… “Ters giden bir şeyleri düzelttik biz!”
İndirdik ve kullanmaya başladık… Uygulamamız artık 2.1.1
Versiyonlama, son kullanıcıdan ziyade, geliştiriciye fayda sağlar. Şöyle ki;
Geliştiricinin, geliştirdiği uygulamanın veya herhangi yazılımsal ürününün gelişim sürecini adım adım görmesini sağlar. “Neydiiiik, ne olduk…” deyimini, versiyon loglarına bakarak, hakkıyla dile getirmiş olur. Bir sonraki ürün geliştirmede de versiyonlama sürecinde karşılaşabileceği şeylerin öncesinde gardını almış olur.
Versiyonlamayı basit bir dille size sunduktan sonra, biraz da işin teknik kısmına parmak basmak istedim. Ve kadim dostum Ahmet SAYIN’ dan, bize biraz daha detaylı bilgi vermesini rica ettim. Kendileri şöyle der;
“Versiyonlamada genel itibariyle 3’lü kullanım yaygın olduğu için 3’lü kullanımı anlatıyorum.
Versiyonlamayı a.b.c diye değerlendirecek olursak;
- Majör versiyon
- Minör versiyon
- Yama versiyon
olarak kabul edilir.
Majör versiyon, projede büyük değişiklikler gerçekleştiğinde veya altyapı değişikliklerinde değişime uğrar. Proje release (yayınlanma süreci) olana kadar majör versiyon 0 olarak projeye başlanır. Release olunca 1.0.0 şekilde proje versiyonlaması devam edilir.
Örnekleme için E-Ticaret projesini örnek alalım. Bir E-Ticaret projesinde altyapı olarak tek proje olarak açıldıktan sonra servis odaklı mimari (SOA) ye geçirilmesi bir majör değişikliktir. Database için mysql kullanılırken oracle kullanılmasından oluşacak alt yapı değişikliği majör değişikliktir. Projenin tekrar yazılması, farklı bir yazılım dilinde yazılması majör değişiklik olarak kabul edilir.
Minör versiyon, projeye yeni eklentilerin, özelliklerin eklenmesi sonucunda oluşan versiyonlamadır. Müşteri var olan bir sayfaya yeni bir alanın eklenmesini isteyebilir, yeni bir sayfa eklenmesini isteyebilir, Front-end üzerinden değerlendirirsek sayfa geçiş efektini beğenilmemesinden dolayı efektteki değişiklik minör versiyon değişiklikleridir. E-Ticaret projesinde kargo firmalarına yeni bir kargo eklenmesi, siteye arama bölümünün eklenmesi, yönetim panelinde çoklu resim ekleme özelliğinin eklenmesi minör versiyon değişikliği olarak kabul edilir.
Yama (Build, Patch) versiyon, projenin hatalarının düzeltilmesinden dolayı oluşan versiyonlamadır. Gerek müşteri gerekse şirket kendi içinde yaptığı testlerde hatalar varsa bu hatalar giderilir ve yama versiyon olarak sunulur.
Proje front-end’i ve back-end’iyle beraber bütün olarak kabul edilir. Fakat ayrı ayrı çalışılıyorsa bu versiyonlama 2 taraf için farklılaşabilir.
Projede versiyonlamayı ve proje kodlarını rahat çalışabilmek için Source Control ve Task Manager bu süreci daha rahat yönetebilmeyi sağlar. Source Control olarak Visual Studio Team Foundation Server ve Git en yaygın kullanılan source control uygulamalarıdır. Task Manager olarak da Team Foundation Server, GitHub, Basecamp, Agilezen, Asana, Teamwork gibi uygulamalar vardır. Team Foundation Server hem task management hemde source control özelliğini taşıdığı için süreçleri çok daha rahat takip edilebiliyor. Aşamalar halinde bakacak olursak;
- Müşteri iş girişini browser üzerinden yapar.
- İş girişi yapıldıktan sonra müşteri ilişkileri departmanı isteği değerlendirir, yazılımsal bir süreç yoksa kendi cevaplayıp müşteriye geri gönderir. Yazılımsal bir süreç varsa proje yöneticisi görevin niteliğine göre front-end veya back-end takım liderlerine görevi assign (atar) eder. Takım liderleri de yazılımcılara görevi aktarır.
- Görevle ilgili değişiklik yapan yazılımcı, proje üzerindeki çalışmasını bitirdikten sonra ilgili dosyaları check-in veya push ederken hangi görevle ilişkili bu değişiklikleri yaptığını belirtmek için, görevi, yaptığı check-in’e bağlar ve açıklama yazılarak ilgili görev resolved durumuna getirilir.
- Resolved durumuna gelen görev test ekibi tarafından test edilerek görev kapatılır ve proje build edilerek production ortamına taşınmış olur.
TFS kullanılması görev takibi, versiyonlama ve versiyon geçmişi olarak çok faydalı bir yöntem olacaktır.
Kısaca versiyonlama ile ilgili genel bilgi ve versiyonlama için kullanılabilecek en faydalı yöntemden bahsetmiş olduk. Bu şekilde bir yapı, iş süreçlerinin daha verimli olmasını sağlayacaktır.”
Kaynak: Sherpa.blog
İçerik İle İlgili Yorum Yap
