Makale Özeti

Bu makalede kaynak kod yonetimi(SCM) nasil yapilir, kaynak kod yonetiminin arkasindaki mantik nedir, kaynak kodlarini yonetebilmemizi saglayan araclar nelerdir ve kaynak kod yonetiminin neden bir gelistirici icin onemli olduguna deginecegim.

Makale

Kaynak Kod Yonetimi

Bu makalede kaynak kod yonetimi(SCM) nasil yapilir, kaynak kod yonetiminin arkasindaki mantik nedir, kaynak kodlarini yonetebilmemizi saglayan araclar nelerdir ve kaynak kod yonetiminin neden bir gelistirici icin onemli olduguna deginecegim.

  1. Kaynak kod yonetimi nedir
  2. Kaynak kod yonetimi genelde birden fazla kisinin projeyi gelistirmesi sirasinda gelistiriciler arasinda koordinasyonun saglanabilmesi ve yapilan degisikliklerin kayit altinda tutulmasi amaciyla kullanilir. Kaynak kod yonetimi genelde merkezi bir repository ve o repository ustunden calismasini surduren developer clientlariyla gerceklestirilir. Developerlar merkezi repositoryden kodlarini ceker, degisikliklerini yapar ve daha sonra bunu tekrar repository'ye isler. Bu model "Checkout-Modify-Commit" modeli olarak gecer, bu modelin orneklerinden aklima gelenler CVS ve SVN'dir. Yakin zamanda populerlik kazanan bir diger SCM turu ise Dagitik SCM'dir ve bunun orneklerinden biri Git'tir.

  3. Kaynak kod yonetiminin getirdikleri neler?
  4. Birden cok developerin es zamanli calismasini saglayabilmek icin, developerlardan birinin yaptigi degisikligin digeri tarafindan yazilmamasi(concurrency ve locking mekanizmalari), yapilan degisikliklerin kayit altina alinabilmesi ve revision gecmisinin tutulmasi (logging and revision history), degisiklikler ayni dosya uzerinde yapildiysa SCM aracimizin bunu mumkun oldugu kadar merge edebilmesi gibi yeteneklere ihtiyac var. Bunlari ayri ayri inceleyecek olursak:

    • Concurrency ve Locking

    • Birden fazla developerin oldugu gelisme ortamlarinda iki developerin ayni anda ayni dosya ustunde calismasi kacinilmaz bir durum. Boyle bir durumda veriyi sonradan kaydeden developerin yaptigi degisikligin, onceden kaydilen degisikligin ustune yazilmasi hem veri hem de zaman kaybina yol acar. Yani somut bir ornekle anlatmak gerekirse,

      1. Merve  A dosyasini acar.

      2. Tuna A dosyasini acar.

      3. Tuna, A dosyasinda degisiklik yapar ve kaydeder.

      4. Merve  A dosyasinda yaptigi degisikligi kaydetmeye kalktiginda bu Tuna'nin yaptigi degisikligin kaybolmasina yol acar.

      Boyle durumlari sanirim multithreaded uygulamalardan hatirliyoruz. Iki farkli threadin ayni datayi degistirmek istemesi bununla ayni durum. Multithreaded uygulamalarda bu durumun cozumu kilit tutmakti, ayni durum burada da gecerli. SCM'de dosya bazinda kilit koyup diger developerlarin ayni dosya ustunde calismasini engelleyebilirsiniz. Ayrica kullandiginiz SCM ve bunu clientina gore siz kilit koymasaniz dahi farkli iki kisi ayni dosyada duzenleme yapip kodu commit ettiginde ikinci gelen kisi, kendi kopyasini guncellemesi gerektigine dair hata alir. Bu konu ustunde daha sonraki makalelerde duracagim.

    • Versiyonlama, Loglama ve Revision kavramlari

    • Versiyonlama terimi yapilan her committe revision numarasinin bir artmasi ve onceki versiyon ayni kalmak sartiyla yapilan degisiklerin yeni versiyonda tutulmasi demek. Bir kitabin farkli baskilari gibi dusundugunuzde, eski baskiya hala erisilebilir veya yeni baski kullanilabilir. Revision ve versiyonlama kavraminin onemi su noktada geliyor: Hatayla bir degisikligi commit ettiniz veya bir kodun onceki hali simdiki halinden daha iyi calisiyor, bu durumda eski bir revisiona donup kodu tekrar yazma zahmetinden kurtulabilirsiniz.

      Loglama olayi ise developerlarin yaptiklari degisikligi diger developerlarin anlayabilecegi sekilde metne dokmesi. Log mesajlarinin uzun olmasina gerek yok sadece "XYZ yapilmak suretiyle NH-XYZT bugi giderildi" demeniz cogu zaman yeterli olacaktir.Boylece bir baska developerin yazdigi kodu anlamak icin cok ugrasmaniza gerek kalmayacak.

    • Izole calisma ortamlari

    • Projenize eklemeyi dusundugunuz cok guzel bir ozellik var fakat bu ozellik projede buyuk degisiklikler gerektiriyor ve yapmayi dusundugunuz seyin hazir hale gelmesi biraz uzun surecek. Diger gelistiricilerin calismasini engellememek istiyorsunuz fakat yine de kendi kodunuzu kontrol altinda tutmak istiyorsunuz. Bu durumda SCM'in branch/tag ozelligi yardima geliyor. Projenin branch'ini olusturup kendinize izole bir calisma ortami yaratiyorsunuz ve SCM'in tum faydalarini kullanmaya devam ediyorsunuz. Eger yaptiginiz calisma basariya ulastiysa bunu tekrar ana kodla birlestirmeniz bir iki tik kadar kolay. Bu branchin diger bir kullanim amaci eski versiyonlara yama cikartabilmenizi kolaylastirmak.

      Bu branch/tag'in yararlarindan biri de projenizin release versiyonlari icin kullanilan kodlari ayri bir klasore alabilmeniz. Kodlar degistirilmeyecek bile olsa eski versiyonunuzu kullanmak isteyen bazi kullanicilariniza bu kodlari sunmak faydali olacaktir.

  5. Kaynak kodu yonetimi yapilirken dikkat edilmesi gereken hususlar
  6. Aslinda dikkat edilmesi gereken bir cok konu var fakat bunlari zamanla ogrenmek, el aliskanligi kazanmak onemli. Benim su an aklima gelen en onemli nokta, kodlarin mumkun oldugu kadar sik commit edilmesi, yani ana repository'ye islenmesi. Bunun avantaji diger developerlarla cakismayi en aza indirmek ve diger developerlari sizin nelerle ugrastiginiza dair haberdar etmek. Bu bakimdan sik commitlemenin yaninda log mesajlarinin aciklayici olmasi da onemli. Ayrica agile prensiplerine daha uygun olmasi acisindan(yazdiginiz uygulamaya kisa surede feedback almak bakimindan) daha faydali.

Bu makalede Kaynak kod yonetiminin bize ve takimimiza neler kazandirdigindan bahsettim. Bir sonraki makale'de bunun uygulamasini opensource bir proje olan "NHibernate" ustunde gorecegiz.

Tortoise SVN

Visual SVN

Using Team Explorer