 SİTE
İÇİ ARAMA |
|
|
 Blogroll |
|
|
|
|
|
|
Sürekli Tümleştirme (Continuous Integration) |
|
| Gönderiliyor lütfen bekleyin... |
|
|
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
|
|
|
|
|
-
-
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
|
|
|
|