C#nedir?com
 
YAZAR HAKKINDA
Murat Uysal
Murat Uysal
http://www.csharpnedir.com/
İletişme geçmek için tıklayın.
1 Makalesi yayınlanmakta.
Yazar hakkında detaylı bilgi için tıklayın.
Yayınlanan diğer makaleleri için tıklayın.
İlgili etiketler: degisikligi hatayi kaynak kontrol olmasi olusturma sistemine sonunda studio testleri testlerin uygulamanin yapilan yazilimcilar yazilimcinin Yazılım Müh. Murat Uysal
 
YAZI HAKKINDA
Türü : Makale
Serbest Köşede C#nedir?com üyelerinin hazırladıkları yazılar yayınlanır. Bu yazılar editör incelemesine girmeden yayınlanır.
Seviyesi : Orta
Kategori : Yazılım Müh.
Yayınlanma Tarihi : 27.9.2005
Okunma Sayısı : 21769
Yorum Sayısı : 2     yorum yaz
Site İçi AramaSİTE İÇİ ARAMA
Üye Girişini AçÜye GİRİŞİ
Üye girişi için tıklayın.
Kullanıcı Adı
Şifre
 
Beni her zaman hatırla
Bir hafta boyunca kullanıcı bilgilerinizi kullanıcı çıkışı yapana kadar hatırlar. (Paylaşılan bilgisayarlarda önerilmez.)
 
Şifremi / Kullanıcı Adımı unuttum.
 
.net TV RSS Serbest KÖŞE (?)
Serbest Köşede C#nedir?com üyelerinin hazırladıkları yazılar yayınlanır. Bu yazılar editör incelemesine girmeden yayınlanır.
emre TAŞ
XML - Deniz Kılınç
emre TAŞ
yazının devamı >
emre TAŞ
Decompiling and Reverse Engineering .Net Radyo
emre TAŞ
yazının devamı >
emre TAŞ
Masaüstü mü ? İnternet Mi? .Net Radyo
emre TAŞ
yazının devamı >
emre TAŞ
.Net Kavramları - .Net Radyo
emre TAŞ
yazının devamı >
emre TAŞ
Yeni Başlayanlar için - .Net Radyo
emre TAŞ
yazının devamı >
Makale Gönder Bende Yazmak İstiyorum
.net TV RSSBlogroll
Turhal Temizer 'in Blogu
ChatBot UI Sample 19.10.2017
Turhal Temizer 'in Blogu
C# – IRR Function 19.10.2017
Burak Selim Şenyurt
.NET Core 2.0 ile Basit Bir Web API Geliştirmek 19.10.2017
Burak Selim Şenyurt
Python - Flask ile Basit Bir Web Uygulaması Geliştirmek 19.10.2017
  Diğer Herşey
Sponsorlar
BT Akademi
Medya Portakal
Video Hosting Sponsoru
Csharpnedir.com bir Ineta üyesidir
Uzman Abi
Her Yönüyle C# - Sefer Algan
Sürekli Tümleştirme (Continuous Integration)
 
Kapat
Sayfayı Yazdır Sık Kullanılanlara Ekle Arkadaşıma Gönder MySpace Del.Ico.Us Digg Facebook Google Mixx Reddit StumbleUpon
Aşağıdaki gibi bir eviniz olmasını ister misiniz ?



Evet seslerini duyar gibiyim. Yanlız bir sorun var, bu ev legolardan yapılmış. Biliyorum hayal de olsa güzeldi. Şimdi bu ev muhabbeti de nerden çıktı diye düşündügünüzü biliyorum o yüzden hemen konuya girecegim.

Legoları sınıflara (class), legoların üzerindeki girinti ve/veya çıkıntıları ara birimlere (class interface) benzetebiliriz. Aynı legoları kullanarak üzerlerindeki basit ama kullanışlı girinti/çıkıntılar sayesinde çok farklı şekiller üretebilirsiniz. Tabii ki bu girişi yapmak için yukardaki eve aylarımı harcamadım. Bu sanat eserini http://club.lego.com/eng/coolcreations/ adresinden buldum. Bu adreste meraklılarını çok daha değişik eserler bekliyor.

Peki anladım bu legolardan ev yapmak yazılım sürecine benziyor da, bunun devamlı tümleştirme (continuous integration) ile ne ilgisi var, benim legolarla uğraşacak vaktim yok diyorsanız yazının devamını okumayabilirsiniz.

Farzedelim ki bu yazıyı okuyan bir hayli küçük bir grup bir araya geldi ve bu legolardan yukardaki evi yapmak istediler. Aralarında bir görev paylaşımı yaptılar. Şanslı bir grup ön bahçeyi aldı, diger grup binanın ön cephesini aldı ve en talihsiz gruba da binanın çatısı kaldı. Farzedelim ki bu gruplar içinde hiç proje yöneticisi yok, herkes bifiil çalıştı ve kısa zamanda her grup kendine düşen görevi bitirdi. Elimizde bir bahçe, bir ev ön cephesi, bir de çatı var. Üç grup da heyecanla ellerindeki parçaları birleştirmek istiyorlar ve biliyorlar ki eğer bahçenin, evin ön cephesine uyumlu girintisi/çıkıntısı yoksa ve/veya evin ön cephesinin, evin çatısına uyumlu girinti/çıkıntısı yoksa bu ev tekrar hayal olacak ve kendi başarıları, birbirleriyle entegre olmadaki başarısızlığları nedeniyle unutulacak.

Yukardaki senaryodan da anlaşılacağı gibi, grubların kendi aralarındaki tümleştirmeyi son derece önem vermesi gerekmekte ve tümleştirmeler mümkün olan en kısa zamanda tamamlanmalıdır. Örnekteki görev paylaşımını yazılımdaki sistem/altsistem modeline benzetirsek ve herbir altsistemin başka bir proje ekibi tarafından geliştirildiğini düşünürsek, ekipler arasındaki tümleştirmenin önemini görürüz. Buraya kadar okuduysanız tümleştirmenin önemli olduğunu düşündüğünüzü varsayıp, yazının geri kalan kısmında yazılımda ki tümleştirme biçimlerinden ve özellikle devamlı tümleştirmenin (continuous integration) faydalarından bahsedecegim.

Öncelikle uygulayabilecegimiz değişik tümleştirmeleri inceleyelim.

Günlük Oluşturma (Daily Build) ve Duman Testleri (Smoke Tests)

Günlük oluşturma farklı alanlarda çalışan yazılımcılar tarafından üretilen kodun, günün sonunda bir araya getirilmesidir ve derlenmesidir. Gün sonunda yapılan bu derleme ile tümleştirmeden kaynaklanan sorunlar en geç günün sonunda farkedilir, yazılımcı(lar) tarafından yapılan hatalar daha kısa bir süre içinde bulunur, uygulamanın her zaman derlenebilir durumda olması sağlanır. Sanırım hepimiz daha önce tümleştirme problemleriyle karşılaşmış, ‘Nasıl olur benim bilgisayarımda çalışıyor’ cümlesini defalarca işitmişizdir. Burada esas olan günlük oluşturmalara önem verilmesi ve gün sonunda bulunan hataların ertesi gün yeni hiçbir işe başlamadan düzeltilmesidir.

Duman testleri (Smoke tests) olmadan gün sonundaki derlemenin başarılı olmasının pek anlamı yoktur. Duman testleri uygulamanın temel özelliklerini test etmesi, uygulamanın çalışması durumunda ‘duman’ çıkıp çıkmadığını göstermesi bakımından önemlidir. Bu testler uygulamaya yapılan değişikliklerden sonra yenilenmeli ve bu testleri yazmanın, kodları yazmak kadar önemli olduğu anlaşılmalıdır. Testler, uygulamanın öngörülen fonksiyonaliteyi yerine getirdiğini ispat etmesi bakımından önemlidir. Günlük oluşturma ve duman testleri uygulamanın sağlıklı bir biçimde geliştirildiğinden emin olmak adına atılması gereken büyük bir adımdır.

Bilmiyorum sizde farkettiniz mi ama günlük oluşturma yukardaki lego örneğindeki soruna pek de güzel bir çözüm bulamamış gibi. Gün boyunca kendi başlarına tümleştimenin sorun olmayacağını farzederek çalışan gruplar gün sonunda bir araya geliyor ve geliştirdikleri parçaları tümleştirmeye çalışıyorlar. Günlük oluşturmanın en iyi ve aynı zamanda en kötü tarafı, tümleştirmenin başarısız olması durumunda bir günlük emeğin boşa gitmesidir. Bu soruna daha iyi bir çözüm olması gerekir diye düşünüyorsanız yanlız değilsiniz. Gelin hep beraber sürekli tümleştirmenin aradığımız cevap olup olmadığına bakalım.

Sürekli Tümleştirme (Continuous Integration)

Uç programlama (Extreme Programming) ile literatüre giren bu konsept günlük oluşturma sürecini otomasyona almakla kalmayıp bu süreyi kısaltıp, kodda yapılan herbir değişikliğin oluşturma sürecini tetiklemesini sağlamaktadır.

Sürekli iyileştirme aşağıdaki basamaklardan oluşan bir süreçtir.

Ø Projenin son hali kaynak kontrol sisteminden alınır.

Ø Oluşturma için kullanılan dizinlerdeki dosyalar (önceki oluşturma sonuçları) silinir.

Ø Tüm proje yeniden oluşturulur

Ø Projenin içinde yer alan testler (birim testleri, kabul testleri, fonksiyonalite testleri vb) çalıştırılır. (Tercihe bağlı)

Ø Kodun statik analizi yapılır. (Kodun kodlama standartlarına uyumluluğu) (Tercihe bağlı)

Ø Oluşturma ve test sonuçları raporlanır.

Oluşturmalar arasındaki sürenin kısaltılmasıyla, yazılımcının yaptığı bir hatanın kısa bir süre içinde ortaya çıkması ve düzeltilmesi sağlanır. Süre ne kadar kısalırsa yazılımcının aldığı geri beslemeler o kadar değerli olur. 15 dk önce yazdığınız koddaki hatayı düzeltmek mi kolaydır yoksa dün yazdıgınız kodun hatasını mı daha da kötüsü haftalar yada aylar önce yazdığınızın mı? Burada düşünmemiz gereken bir diğer sorun da sizin yazdığınız kod başka yazılımcılar tarafından kullanıldığı gerçeğidir. Sizin geliştirdiğiniz kodda yaptığınız bir hata kodu kullanan diğer yazılımcıları da etkileyebilir ve oluşturmalar arasındaki zaman arttıkça hatayı düzeltmek için sarfettiğiniz efor da eksponansiyel olarak artar.

Sürekli iyileştirmeyi uygulamak için aşağıdaki bileşenlere ihtiyacımız var.

Ø Kaynak kontrol sistemi (Visual Studio 2005 Team System, Visual SourceSafe, CVS*, Perforce, Subversion, Rational ClearCase, SourceGear Vault, StarTeam),

Ø Oluşturma scripti geliştirecek araç (NAnt*, MSBuild),

Ø Uygulamanın fonksiyonalitesini testlerini ,birim testlerine, kabul testlerine, fonksiyonalite testlerine vb, çalıştıracak araç (Visual Studio 2005 Team System, NUnit*, Fitnesse*),

Ø Kodun statik analizini yapacak araç (Visual Studio 2005 Team System, FxCop*)

Ø Kaynak kontrol sistemlerini sorgulayıp değişiklik bulduğu takdirde oluşturmayı tetikleyecek, oluşturma ve test sonuçlarını görüntüleyecek araç (Visual Studio 2005 Team System, CruiseControl.NET*, Draco.NET*)

Yukardaki araçların sayısı çok gelebilir. Şu anda bu araçların maaliyetlerini düşünüyor olabilirsiniz ama güzel size güzel bir haberim var. Her kategoride * işaretli ile ya başarılı bir açık kaynak bir araç yada maaliyeti olmayan bir araç bulunuyor.

Dikkat edilmesi gereken hususlar:

Yukardaki sürece bakarsanız bütün süreç yazılımcının kodu kaynak kontrol sistemine yüklemesiyle (check-in) başlıyor. O halde yazılımcılar bu yükleme işinde hassas davranmalı ve kaymak kontrol sistemine yaptıkları değişikliği göndermelidirler aksi halde sürekli bir oluşturma olması mümkün değildir.



Uygulamanın amacına hizmet ettiğini kontrol etmek için çalıştırılan testlerin başarılı olması kadar testlerin etki alanının da (test effectiveness) belirlenmesi gerekir. Örnegin 100 sınıftan oluşan bir uygulamada sadece 50 birim testi (unit test) ve 10 kabul testi (acceptance test) olması testlerin yeterli olmadığını gösterir. Test sayısından daha etkili bir ölçüt de testlerin çalıştırılmasıyla uygulamada çalışan kodların yüzdesinin belirlenmesidir. Buradaki hedef olarak belli bir yüzdeden ziyade son kullanıcının uygulamayla iletişimi dikkate alınmalı ve genel senaryoların kontrolünün mümkün olduğunca testlerde kapsanmasına özen gösterilmelidir. Bu test kümesi sadece uygulamanın kontrolunde yardımcı olmakla kalmayıp, yazılımcınım kodda yaptığı değişikliklerin kodun başka kısımlarında bir hata oluşturup oluşturmadığını da bulmamıza yardım edecektir.

Sürekli tümleştirme sürecinde bulunan uygulamadaki hatalar için, hatanın düzeltilmesinden önce bu hatayı tespit edecek testin yazılması ve bu şekilde bu hatanın bir daha ortaya çıkma olasılığının önüne geçilmesi gerekmektedir. Bahsedilen bu testin eklenilmesinin ardından hatayı düzeltmek için gerekli kod değişikliği yapılmalıdır.

Geliştirilebilecek hususlar:

Yazılımcılar kendi bilgisayarlarında da sürekli geliştirme sürecini uygulayabilirler. Bu sayede sadece kodun son haline sahip olmakla kalmayıp, yaptıkları değişikliği kaynak kontrol sistemine yüklemeden gerekli testleri çalıştırabilir, sonuçlarına bağlı olarak değişikliği kaynak kontrol sistemine yansıtabilirler.

Yazılımcılara değişiklik yaptıkları kodları en azından gün sonunda kontrol sistemine yüklemeleri için hatırlatma mesajları gönderilebilir.

Her ne kadar kulağa hoş gelmese de; sürekli tümleştirme süreçinin minimum hata ile devam etmek için bu sürecin hata vermesine sebep olan yazılımcının deklare edilmesinde hatta küçük cezalar verilmesinde fayda vardır. Örneğin hataya sebep olan yazılımcı kitap fonuna katkıda bulunabilir. Bu sayede yazılımcılar sürekli tümleştirme konusunda daha hassas hala gelebilirler.

Özet:

Sürekli tümleştirme, tümleştirme periyodunun azaltarak bu süreç içinde oluşabilecek hataları minimize etmekle kalmayıp, hataların daha kolay düzeltilmesine imkan vermektedir. Testlerin, geliştirme sürecinde bulunan hataların ve test apsamlarının düzenli raporlanması projenin gelişimi hakkında daha kapsamlı bilgi edinmemizi sağlar. Kodun statik analizi kodun belli bir standart da yazılmasını sağlayarak kodun daha harmonik olmasını saglar. Bu sayede yazılımcılar birbirlerinin kodunu daha rahat anlarlar, ekibe yeni katılan yazılımcıların adaptasyon süresi kısalır.

Referanslar bölümündeki linklerden daha detaylı bilgiye sahip olabilirsiniz. Legolar ile yazılımdaki benzerliği bir süreliğine unutup legoların sınırlarını zorlayabilirsiniz...J

Referanslar:

http://www.stevemcconnell.com/bp04.htm

http://www.theserverside.net/articles/showarticle.tss?id=ContinuousIntegration

http://www.martinfowler.com/articles/continuousIntegration.html


Makale:
Sürekli Tümleştirme (Continuous Integration) Yazılım Mühendisliği Murat Uysal
  • Yazılan Yorumlar
  • Yorum Yaz
EKİ
4
2005
Profesyonel yazılım geliştirmenin, en önemli süreçlerinden birisini anlatmışsınız. Geliştiriciler açısından oldukça yararlı olacağını umuyorum. Yeni yazılarınızı görmek dileğiyle.
EYL
28
2005
Faydalı Bir makale. Teşekkür ederiz
Sayfalar : 1 
Yorum yazabilmek için üye girişi yapmalısınız. Üye girişi için tıklayın.
Üye değilseniz Üyel Ol linkine tıklayarak üyeliğinizi hemen başlatabilirisniz.
 
  • Bu Konuda Son 10
  • Eklenen Son 10
  • Bu Konuda Geçmiş 10
Bu Konuda Yazılmış Yazılmış 10 Makale Yükleniyor
Son Eklenen 10 Makale Yükleniyor
Bu Konuda Yazılmış Geçmiş Makaleler Yükleniyor