26.08.07 tarihinde sabah 10:00 – 13:00 arasi brunch esliginde Agile ve
XP pratikleri tanitimi yapmayi ve sizlerle tanismayi planliyoruz.
Katilim ucreti sadece brunch ucretinden ibarettir.
Ilgilenen arkadaslar lutfen info@mentor.com.tr adresine email atip
kayitlarini yaptirsinlar.
Katilim ucreti: 20-40 YTL arasinda
Yildiz Unv. Hisar Tesisleri
Bu yazıda kısaca yineleme kapsamında geliştirilecek kartlarla ilgili tahminlerin nasıl alındığını ve kartların nasıl seçildiğini anlatmaya çalışacağım.
Yineleme başlamadan 2 hafta önce bir ön toplantı yapılıyor. Bu toplantıya analistler ve müşteri katılıyor. Daha önce adı konan ve birkaç cümleyle ifade edilmiş halde duran kullanıcı hikayesinin bir sonraki yineleme kapsamına alınıp alınmayacağı belirleniyor. Müşteri öncelikleri ve yayım planlaması sırasında verilen tahmin kullanılarak kapsam belirleniyor.
Kartlar belirlendikten sonra analist bir hafta boyunca detay çalışmayı yapıyor ve kabul kriterleri , arayüz kesitleri gibi bilgileri topluyor. Bu haftanın sonunda tüm kartlar bir panoya asılıyor ve her geliştirici bir kart alarak kart için ne gibi geliştirme faaliyetlerinin gerekeceğini buluyor
Mevcut yineleme bitiminden sonraki yineleme için planlama toplantısı yapılıyor ve ön toplantıda belirlenen tüm kartlar analist tarafından tüm ekip üyelerine açıklanıyor. Sonraki adımda kartı geliştirme bakış açısından inceleyen kişi kart için ne gibi çalışmaların yapılması gerektiğini diğer ekip üyeleri ile paylaşıyor. Herkesin kafasında soru işaretleri giderildikten sonra planlama pokeri pratiği ile tahminler alınıyor.
Bu tahminler alındıktan sonra ekibin bir önceki yinelemede kaç puanlık iş bitirdiği ve sonraki yinelemede kaç kişinin kartlar üstünde çalışacaği gibi faktörler gözönüne alınarak ne kadarlık iş yapılabileceği tahmin ediliyor. Örneğin bir önceki yinelemede 20 puanlık iş bitmiş olsun ve tatile giden bir geliştirici dönüyor olsun, bu durumda 24 lük iş bitiririz gibi bir tahmin verilebilir.
Sonraki aşamada müşteri kartları öncelik sırasına koyuyor. Kritik öneme sahip olanları en başa koyuyor. Son olarak ekibe bu kartları yapabiliriz diyor musunuz diye bir soru soruluyor ve yineleme içeriği herkes rahat hissedecek şekilde değiştirilebiliyor. Toplantı sonunda kısa bir ara veriliyor ve yeni kartlar ile ilgili geliştirme çalışmaları ayakta yapılan bir toplantı sonucunda başlatılıyor.
Bu yazıda kısaca sürekli entegrasyon sürecini büyük kod tabanına ve yaklaşık 80 yazılımcının çalıştığı bir projede nasıl uygulandığını aktarmaya çalışacağım.
Bu tür büyük projelerde entegrasyon problemlerinin ortaya çıkma riski daha fazla. Hergün yüzlerce satır yeni kod ekleniyor . Bu eklenen kodların mevcut özelliklerde hiçbirşeyi bozmadığını ve problemlerin ortaya çıkmadığını maliyetsiz biçimde doğrulamak gerekiyor. Bu nedenle sürekli entegrasyon süreci daha fazla önem kazanıyor. Fakat bu konuda yaşanan ana sıkıntılardan biri sürekli entegrasyon kurulumlarının kod tabanının büyüklüğünden dolayı uzun sürmesi. Prensip olarak bu kurulumun azami 10 dk sınırında tutulması gerekiyor. Aksi halde insanlar kurulumun durumuna bakmadan kodları versiyon kontrole ekleyip entegrasyon problemlerine neden olabiliyorlar. Bizim projede uyguladığımız yöntem şu şekilde işliyor.
Sürekli entegrasyon kurulumunu 3 seviyede yapıyoruz.
Hızlı kurulum:
Herhangi bir kod değişikliği yapıp versiyon kontrole eklediğimizde bu değişiklik Hızlı kurulum sunucusu tarafından tespit ediliyor ve Ant script vasıtasıyla hızlı kurulum başlatılıyor. Bu kurulumun kapsamı tüm kodların derlenmesi, veritabanına değişikliklerin uygulanması(dbdeploy) ve yaklaşık 40 bin birim testinin çalıştırılması olarak özetlenebilir. Bu kurulum yaklaşık 7 dk sürüyor. Yeni bir Checkin işlemi yapmadan önce mutlaka son hızlı kurulumun sonucunun başarılı olmuş olması gerekiyor.
Eğer Hızlı kurulum başarısız olursa herkesin bilgisayarında Windows Taskbar da çalışan CCTray uygulamasındaki ikon kırmızıya dönüyor ve tüm ekip bir problem olduğunu anlıyor. Başarısız kuruluma neden olan checkin işlemini yapan kişi yaptığı değişikliği geri alıyor ve bir önceki başarılı kuruluma dönülüyor. Bu sayede diğer insanlarin checkin işlemlerini bloke etmekten kaçınılıyor.
Hızlı kurulum sonucu başarılı ise Entegrasyon kurulumu tetikleniyor.
Entegrasyon kurulumu:
Entegrasyon kurulumu Hızlı kurulumun başarılı olduğu durumda çalışmaya başlıyor.
Entegrasyon kurulumunun en büyük özelliği projenin uygulama sunucularına deploy edilmesi ve QA grubu tarafından hazırlanan bir listedeki Kabul Senaryosu testlerini çalıştırması. Bu kabul testleri uygulamayı Selenium aracını kullanarak arayüz düzeyinde test ediyor. Bu listede bulunan kabul senaryoları projenin önemli ve riskli bazı özelliklerini test ediyor.
Entegrasyon kurulumu başarısız ise buna neden olan kod değişikliği analiz edilip düzeltilmeye çalışılıyor . Hızlı kurulumdakinin aksine ekiptekiler checkin işlemi yapılabiliyor. Fakat checkin yapmadan önce başarısızlığı düzeltmeye çalışan kişilere gidip izin almak gerekiyor. Versiyon kontrole eklenecek kod değişikliğinin kurulumu bozan değişiklikten tamamen ayrı olması gerekiyor.
Gecelik kurulum
Her gece yarısı tüm ekip uyurken CruiseControl boş durmuyor. Bu kurulum tüm kodları sıfırdan derliyor, veritabanını sıfırdan oluşturuyor,birim testlerini çalıştırıyor ve uygulamayı deploy ederek binlerce kabul testi senaryosunu çalıştırıyor. Bu kurulum yaklaşık 40 dk kadar sürüyor. Kabul testlerinin çalışması sırasında arayüzde alınan hatalar o anda Desktop un resimlerini alarak kaydediliyor.
Buna ek olarak Sürekli performans denetimi için performans testleri çalıştırılıyor ve rapor oluşturuluyor. Bu sayede uygulamanın saniyede kaç sayfa sunabildiği gibi önemli metrikler güncelleniyor.
Bu pratiğin uygulanması sonucu baş ağrıtan ve çözülmesi zaman alan problemlerin önüne geçilmiş oluyor. Proje her an gerçek ortama kurulmaya hazır halde tutulabiliyor. Bu tür pratikleri uygulamayan projelerde gerçek ortama kurulumlar günler alabilirken , sürekli entegrasyon sayesinde bu süre dakikalarla ölçülüyor.
Konuya ilgi duyanlar için Martin Fowler ‘ in makalesi
http://www.martinfowler.com/articles/continuousIntegration.html
TDD eğitiminin içeriğini aşağıda bulabilirsiniz. Eğitimin süresi 2 gündür. Daha detaylı bilgi için benimle bağlantıya geçebilirsiniz.
İçerik :
·Overview of TDD
o Theory
o Principles
o Mechanics
· xUnit tools
· Practice 1 : Stack implementation.
· Topdown TDD with Mock objects and Dependency Injection
o Improving testability of designs
o Mocks vs Stubs
o Dynamic Mock Libraries
· Practice 2: Sending emails to Overdraft accounts.
· Unit test quality
o Fine grained ,Simple, Isolated,Fast, Readable
· Unit Test patterns
o Naming conventions.
o Testing for behaviour.
o Using ObjectBuilders in test preparation.
o Custom Constraints for Assertions
o Testing abstract classes
o Testing with Database
· Common test smells
o Long tests
o Using mocks instead of stubs
o Testing implementation
o Too many assertions
o Intermittent failures
· Automating test suites.
o Ant integration
· Executing tests during continuous integration
o Sample CI implementation with CruiseControl
· Test Coverage and Analysis
o Configuring and executing Emma coverage tool.
· Levels of testing in Enterprise Projects
o Examples from Real World Projects
· Story test driven development using Fit
· Behaviour Driven Development(BDD)
o Example Specifications using Jbehave
· TDD approach in legacy applications
· Group exercise : TDD Coding Workshop
o Sales Tax problem
