CruiseControl

[mfe...@googlemail.com]

Selamlar,

Sürekli entegrasyon pratiği için http://cruisecontrol.sourceforge.net/
adlı aracı kullanmaya karar verdik?

Sizce doğru mu yaptık? Tecrübeleriniz neler?

Selamlar
M. F. Emin

[bahadi...@gmail.com]

Selamlar,

Sürekli entegrasyon'da aracın seçimine karar verirken aslında hangi
adımları CI içerisnde tanımlamayı hedeflediğinizle ilgili çalışmak
ondan sonra bu hedefleri sağlayan aracı seçmek en doğru olanı.
Genelde CI konusunda build işleminin sadece "code compilation" dan
ibaret olduğunu zannedilmesi en çok gördüğüm pratik maalesef. Boyle
düşünülmesinden dolayı da zaten IDe'lerde compile işlemi var niye bir
build mekanizmasına ihtiyac duyalım ki cevabı da kaçınılmaz oluyor.

En basit haliylr CI için gerekli
- Versiyon kontrol sisteminine (ClearCase, SVN,CVS, TFS, JSC vs...)
- build script (ANT, NANT, Make vs..)
- geri bildirim mekanzması (email, sms, rss vs..)
- kod'daki değişikleri izleyecek bir proses..(manuel ya da CI server-
CruiseControl, BuildForge, AntHillPro, Apache Continuum, Hudson vs..)

bu başlangıç için gayet yeterli..Bu gerekleri sağladıktan sonra
bunları kullanarak neler yapabilirize bakmak lazım
dediğim gibi compile işlemlerden sadece bir tanesi. Testlerinizi
çalıştırarak otomatize edebilirsiniz. Testler birim test, bileşen
testleri, fonksiyonel testler, performance veya stres testleri
olabilir.
kod taramaları yapabilirsiniz. Kod taraması derken XP pratiklerinden
kodlama standartlarına uygunluğu denetleyebilirsiniz, dublike kod
parçalarını bulabilirsiniz, kod coverage testlerini yapabilirsiniz,
tasarım kurallarınızı denetletebilirsiniz gibi birçok statik ve
dinamiik denetimi yapabilirsiniz. Veritabani ile ilgili işlemleri
build içinde tanımlayabilirsiniz hem DDL hem DML scriptlerini
çalıştırarak kulllanabilirsiniz..Ve en önemlilerinden bir tanesi de
deployment yapabilirsiniz.

CI'da önemli özellilklerden bir tanesi de build'lerin çok hızlı
çalışabilmesi, çok uzun sürmemesi o yüzden önerilen CI işlemlerinin de
gruplanarak yapılması. Geliştiricilerin kod değişikliğini yapmadan
önce kendi lokalinde build çalıştırması en temel pratiklerden bir
tanesi amaç da ana kod alanına (stream, mainline yada main branch
versiyon araçları farklı isimlendirmeler kullanıyor.) değişikliği
göndermeden problem olup olmadığının denetlenmesi bu sebeple de lokal
build işlemlerinde tüm testlerin, deployment, kod taramaları
yapılmasına gerek olmayabiliyor.

Değişiklik ana kod alanına gönderildikten sonra eğer build'lar çok
uzun sürüyorsa bunu da iki parçaya birincil ve ikincil build olarak
bölerek ikinci ve en kapsamlı işlemi daha uzun periyotlarda yapmak
anlamlı olabiliyor. Burada uzun periyet dediğimde aslında CI için uzun
denebilir.Günde 2-4 kere mesela..Ama birincil build işlemi her kod
değişikliğinin check-in edilmesinden sonra çalışması gerekiyor ki CI
gerçek anlamda kullanılmış olsun..

Tabi dikkat edilmesi gereken durumlarda var CI için


- Her birincil / ikincil build işleminde deployment'ların temiz bir
ortama taşınması
- DDL ve DML scrptleri çalışıyorsa yapılıyorsa test adımalrı
çalıştıktan sonra verilerin eski durumlarına geri döndürülmesinin
unutulmaması
- Geri bildirim mekanizmalarının takip edilmesi
- Build sırasında problem karşılaşıldıysa hatanın hemen düzeltilmesi
yoksa CI'nınn "continuous" kısmı diye birşey olamayacaktır..

Arç seçimi ile ilgili olarak elinizdeki versiyon kontrol sistemiyle
kolay entegre olması, gere besleme mekanizmalarının farkı yöntemleri
de desteklemesi (email, sms ,rss gibi), kolay yönetilebilmesi (yönetim
ekranlaının olması), raporlarının anlaşılır olması, birden fazla
formatta rapor üretebilmesi (html, xml, pdf vs..), birden fazla build
script'ini destekleyebilmesi (ant, nant, make vs..), build scripting
yanında program çalıştırabilmesi ya da komut satırından çalıştırılan
her komutu işleyebilmesi, schedule edilebillmesi, sizin ygulamayla
aynı dilde yazılmış olması gibi özellikleri sunuyor olmasına dikkat
etmek derekebilir.

CruisControl'de yukarıdaki özelliklerin çoğunu sağlaması ve de geniş
br kullanımı olmasından dolayı iyi bir tercih olabilir. open source
olmasından dolayı da maliyet ile ilgili avantajları da var. Fakat
genel open source yaklaşımlarında ki durum destek için elinizdeki
kaynağın "google" olması.

Benim tavsiyem eğer anladığım kadarıyla bu konuda yeni çalışmaya
başlayacaksınız, bu sebeple adımları iteratif olarak devreye almanız.
Zamanla kapsamı genişletmeniz. Compile ve deployment başlangıç için
iyi adımlar olabilir. Birim Test yazıyorsanız bu ilk adıma birim
testleri de ekleyebilirsiniz..

Saygılarımla,



On Jun 2, 5:31 pm, "mfe...@googlemail.com" <mfe...@googlemail.com>
wrote:
> Selamlar,
>
> Sürekli entegrasyon pratiği içinhttp://cruisecontrol.sourceforge.net/

[Mehmet Fahir Emin]

Teşekkürler konuyu açıklayan epostanız için.
Anladığım kadarıyle CI ' i  TDD den ayırmak mümkün değil. Compile yeterli değil.

Benimde Google'dan bulduğum bir kaynak projede uygulamayı anlatmış.
http://cenkcivici.wordpress.com/2007/08/09/surekli-entegrasyon-buyuk-bir-projede-uygulanmasi/

Selamlar
M.F Emin

2008/6/17 <bahadi...@gmail.com>: