Java Teknolojileri ve Programcıları Derneği | İstanbul JUG

Versiyonlama sistemleri (versioning systems) içerisinde SVN, özellikleri ile açık kaynak kodlu projelerde (Open Source Project) ve çevik takımlarda en çok kullanılanı olmuştur.

Mercurial Versiyonlama Sistemi ile desteklenmiş bir ortamda ise ana depodan (repository) - bu depo SVN, Mercurial olabilir - oluşturulan Mercurial depoları ile her kullanıcı offline olarak kodlarını kendi Mercurial deposuna commit yapabilir. Online duruma geçtiğinde kendi deposunu ana depo ile senkronize hale getirebilir.

Açık kaynak kodlu projelerde benimsenen belli bir depo (repository) yapısı mevcuttur:

Depo (Repository)
|
|
|- Proje_1
|
|-trunk
|-branhces
|-releases/tags
|-site
|-sandbox
|
|-developer_1
|-developer_2

trunk : Geliştirme patikalarının (branch) oluşturulduğu, her zaman deploy edilebilir kodların bulunduğu ana proje hattıdır.

branches : Geliştirmelerin yapılacağı, trunk'dan oluşturulan patikalardır. Trunk'dan oluşturulabilecekleri gibi başka bir patikadan da oluşturulabilirler.

releases / tags : Trunk üzerinde gerçekleştirilen Nightly Builds ve Deploy'lar sırasında oluşturulan patikalardır. Bu patikalar kabul görmüş geliştirmeleri içerir.

site : Projeye ait bilgileri içeren web sayfalarının bulunduğu yerdir. Özellikle Maven ile otomatik olarak oluşturulan raporları içerir.

sandbox : Sandbox (kum havuzu) içerisinde her uygulama geliştiriciye ait klasörler bulunur. Bu klasörler içerisinde uygulama geliştiriciler yapacakları araştırmaları ve denemeleri burada depolar.

Versiyonlama Sistemi Yönetim Kuralları

Aynı proje üzerinde 5 kişiden oluşan takımların geliştirme yaptığını düşünelim. Oluşabilecek kod çakışmalarını ve getireceği sorunları tahmin edebiliriz; kod çakışmaları, birbirlerinin kodlarını ezme, birim ve entegrasyon testlerinden geçememe v.b..

Elimizde Gövde (trunk) ve patikalar (branch) klasörleri ile ilgili katı kurallarımız olursa yaşanabilecek sorunları en aza indirgemiş olabiliriz.

Gövde (Trunk) Yönetimi

Gövde'nin özellikleri

1. Gövde (trunk) her zaman deploy edilebilir olmalı
2. Sağlıklı (Stable) olmalı
3. Üzerinde kod geliştirmesi gerçekleştirilmemeli
4. Birim (Unit Test) ve entegrasyon (Integration Test) testlerinden geçmelidir
5. Gövde Yöneticisi tarafından yönetilmelidir.

Gövde Yöneticisinin Görevleri

1. Nightly Build sonrası Gövde'nin sağlık durumunu sürekli takip etmelidir
2. Testleri bozan kod aktarımlarında (merge), aktarımın hangi takım tarafından yapıldığını tespit etmelidir.
3. Sorun tespit ederse hemen ilgili takımın lideri ile irtibata geçip hatalı kodu düzelttirmelidir.

Geliştirme Patikalarının (Branch) Özellikleri

Gövde üzerinde kod geliştirilmesi yapılmayacaksa nerede yapılacak? Bunun için patikalar yardımımıza koşmaktadır. Çevik süreçlerde bir projenin planlama toplantılarında verilen Hikaye Puanları (Story Points) projenin kaç sprint'den oluşacağı ver her sprint'de hangi hikayelerin (Story) bulunacağı belirlenir. Belli büyüklükteki hikayeleri ise görevlere (Task) böleriz.

İlgili proje için Gövde'den (trunk) bir Patika (branch) oluşturalım. Bir takım birden fazla uygulama geliştiriciden oluşursa ve projeye ait hikayeler paralel olarak geliştirilirse Gövde'de yaşadığımız sorunlarla Proje Patika'sında da karşılaşmayacak mıyız?

Evet karşılaşacağız.Çözüm ne olacak peki?

Çözüm 1: Takım içerisindeki tüm geliştiriciler tek bir hikayeye odaklanacak.
Çözüm 2: Proje Patikasından (Project Branch) Hikaye Patikaları (Story Branch) oluşturulur, her hikaye kendisine ait patkida geliştirilir. Onaylanmış hikayeler Proje Patikasında birleştirilir.

Proje Patikasının Özellikleri

1. Gövde'den (Trunk) veya başka bir patikadan oluşturulurlar.
2. Üzerinde sadece önceliği en yüksek hikayenin geliştirmesi yapılabilir veya her hikaye kendisine ait patikada geliştirilir.
3. Takım içerisinden bir kişi Proje Patikasının yöneticisi olarak seçilmelidir.
4. Üzerinde birim testler (Unit Test) çalıştırılmalıdır.

Proje Patikası Yöneticisinin Görevleri

1. Proje patikasının sağlıklı (stable) olmasını sağlar
2. Sürekli Entegrasyon (Continuous Integration) ile birim testlerin periyodik olarak çalıştırılmasını sağlar
3. Hikaye patikalarından (Story Branch) gelen aktarımların (merge) düzgün yapıldığını kontrol eder
4. Hatalı aktarımı yapan kişiyi uyarır, sorunun çözülmesini sağlar
5. Kabul gören hikayelerin, Gövde'ye (Trunk) aktarımını gerçekleştirir.
6. Belli periyodlarla Gövde'deki değişiklikleri Proje Patikası'na aktarmalıdır.

Kod Aktarımını İlk Yapan Kraldır

Çevik takımların bulunduğu geliştirme ortamında takımların birbirlerinin kod aktarımlarını bozmaları kaçınılmazdır. En önemli kuralımız Gövde'nin (Trunk) her zaman deploy edilebilir bütün testlerden geçmiş olmasıdır. Bu kural dahilinde bir T2 takımı, tüm testlerden geçmiş bir T1 takımının aktarımını bozuyorsa o sorunu çözmek T2 takımının görevidir. Bu yüzden T1 takımını kral olarak ilan edebiliriz.


Kaynaklar
1. InfoQ : Version Control for Multiple Agile Teams : Henrik Kniberg

Projenin kullanımı;
Hizmetten faydalanabilmeniz için üye olmanız gerekiyor. Web sitesine girerek üyelik formunu doldurmalısınız. Ayrıca Sun Developer Network(SDN) hesabınız var ise buradaki email adresinizle hemen üye olabilirsiniz.

Üye olduktan sonra My Page bölümünden projelerinizi yönetebilirsiniz. En fazla 5 proje oluşturabiliyorsunuz.
Netbeans ile kullanımı ise şöyle;
Kenai project netbeans 6.7 sürümüden sonra entegre olarak gelmekte. Yeni bir proje oluşturmak için File menüsünden Open->Kenai project diyoruz. Açılan pencereden Create Project e basıyoruz.



Açılan pencerede resimde gördüğünüz gibi proje bilgilerini giriyoruz. Resimde gördüğünüz gibi proje isimleri sadece küçük karakterlerden oluşmalıdır.



Proje ismini küçük harflerle girdikten sonra next diyoruz gelen pencereden Netbeans üzerinde önceden oluşturduğunuz projeyi browse ile bulup gösteriyoruz. Bu bizim local depomuz oluyor. Sonra next diyoruz.



Finish dediğinizde girdiğiniz bilgilerle kenai de yeni bir proje oluşturulacak. Bir süre beklemeniz gerekli.





Bu ekranı gördüğünüzde projeniz başarı ile oluşturulmuş demektir. şimdi bu pencereyi kapatıp kod üzerinde düzenlemeler yapabiliriz.



Yaptığınız değişikliklerden sonra kenai sunucusundaki kod fakları renklendirme ile gösterilmektedir. Yapmak istediğiniz kısmi geri alımlarıda üzerlerine tıklayarak yapabilirsiniz.



Proje üstünde yaptığınız değişiklikleri kenai sunucusuna göndermek içinse proje ismine sağ tıklayıp Kenai->Versioning actions->Commit... e basıyoruz açılan pencerede hangi dosyalara ne değişiklikler yapılacağının ayrıntısını görebiliyoruz. Commit Message bölümüne bu commit ile ilgili detayları yazabilirsiniz.



İşlem bittikten sonra detaylar email adresinize gelecektir.