Surekli entegrasyon pratiginin buyuk projelere olceklenmesi
1 view
Skip to first unread message
cenkcivici
Apr 3, 2008, 2:39:44 AM4/3/08
to AgileTurk
Bu yazıda kısaca sürekli entegrasyon sürecini büyük kod tabanına ve
ekip buyuklugu 100 kisiye yaklasan 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.
1. Hızlı kurulum
2. Entegrasyon kurulumu
3. Gecelik kurulum
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
Iyi calismalar
Cenk Civici
Thoughtworks London
Senior Consultant
ekip buyuklugu 100 kisiye yaklasan 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.
1. Hızlı kurulum
2. Entegrasyon kurulumu
3. Gecelik kurulum
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
Iyi calismalar
Cenk Civici
Thoughtworks London
Senior Consultant
Halil Bahadır
Apr 3, 2008, 5:19:32 PM4/3/08
to agil...@googlegroups.com
Selamlar,
Cenk Bey'in bahsettiği gece çalışma senaryosunun benzerini fakat Agile bir yöntem kullanmayan bir firmada (POC durumunda olduğu için isim veremiyorum maalesef) pilot uygulamaya başlandı,
senaryoda su sekilde işliyor, versiyon control için ClearCase hali hazırda kullanılıyor burada integrasyon/uat/ prod ortamına alınmak istenen kod geliştirici tarafından etiketleniyor (talep boyle yoksa her check-in içinde bu sistem çalıştırılabilir), Build yönetimi için BuildForge ile etiketlenen kodlar ant scriptleri ile derleniyor, yine ant'la Junit'de birim testleri çalıştırılıyor, database scriptleri çalıştırılııyor hersey basarili olursa, Fonksiyonel test için yine firmanın kullandığı hp mercury test araçının fonk test senaryoları çalıştırııyor. Bu da problem yaratmazsa eğer build senaryosunda işaretlendi ise performans test sctipltleri calistiriliyor, bu da beklenen threshold değerlerinin altında olursa bir sonraki deploy adımına geçiliyor. Deploy'da pilot için su an UAT ortamına JBoss server'a gönderiliyor. Eğer birim, fonk veya performans testte bir problem olursa, hata kaydı olarak Test Directory'de otomatik kayıt açlılıyor.Ekran kod log dosyası vs ile birlikte açılıyor kayıt. Hatta su an tam bitmedi ama birim testlerde hata alınan kodu en son kim check-in eetmişse hata kaydı o kişiye otomatik olarak atanacak gibi bir çalışma da var. En son adımda operasyondaki ilgili kişiye sonuc email veya SMS atma durumu olacak diye talep de var.. Hata alındı ise o ana kadar olan adımlar rollback ediliyor ki bu daha cok DB scriptleri için geçerli oluyor..İşin sonunda da yine ant ile Javadoc oluşturma adımı olacak ama kodlarda hic kimse comment yazmadığı için şimdilik boş cıkıyor :)
Bu akışı yoneten buildforge.ama kapsamdaki araçlar ibm var hp var oracle var jboss var...farklı firmalar + open source araçların yönetildiği bir poc...
saygılarımla..
Halil Bahadır
2008/4/3 cenkcivici <cenk....@gmail.com>:
cenkcivici
Apr 3, 2008, 7:27:52 PM4/3/08
to AgileTurk
Merhaba,
Surekli entegrasyon surecinde her gelistiricininde soyle bir
sorumlulugu var.
Herhangi bir kod degisikligini versiyon kontrole eklemeden once
Checkin Dansi dedigimiz bir surec izleniyor. Bu surece gore
1. Once Versiyon kontrolden ekibin yaptigi tum degisiklikler
aliniyor.
2. Gelistirici kendi makinesinde bir kurulum gerceklestiriyor. Bu
kurulum kodlari derliyor, birim testlerini calistiriyor.
3. Eger hata yoksa bundan sonra kod versiyon kontrole eklenebiliyor.
Bu sureci uygulamadan kodu checkinlemek Surekli entegrasyon etigine
uymaz.
Checkin sonrasi surekli entegrasyon sunucusu bu degisikligi gorup ayni
kurulumu tekrarliyor.
1. Amac benim makinamda calisiyordu burada niye calismiyor durumunun
olmamasi ve birden fazla gelistiricinin yaptigi degisikliklerin
birseyi bozmadigindan emin olabilmek
Surekli entegrasyonun "surekli" kismi aslinda tam olarak surekli
degil. Her degisiklikte bir entegrasyon anlaminda kullaniliyor.
Bu acidan en onemli kurulum her kod degisikliginde(her checkinde)
calisacak olan kurulum.
Bu kurulumun ideal suresi 10 dk nin altinda tutulmali. 10 dk yi
gectigi zaman ekip uyelerinin islerini yavaslatmaya basliyor. 10 dk
altinda olmasi prensibinin nedeni hizli geri beslenim alabilmek cunku
gelistirici son kurulumun durumuna bakmadan checkin yapamiyor ve
yaptigi degisikligin entegrasyonda da calistigi geri beslenimini
almasi gerekiyor. Kurulum suresi ne kadar uzarsa bu pratigin
uygulanmasi da zorlasiyor. Bu nedenle araclari secerken
optimizasyonlara gidebileceginiz, esnek araclar secmenizi tavsiye
ederim.
Eger bu sureyi asagiya cekmek mumkun degilse ornegin proje buyuklugu
buna izin vermiyorsa daha onceki emailde bahsettigim hizli kurulum,
entegrasyon, gecelik kurulum gibi bir gruplamaya gitmek cozumlerden
biri.
Ekibin teknik liderinin gorevlerinden biri bu kurulumun suresini
izlemesi ve uzama egilimi gosterdiginde kurulum suresini kisaltacak
mudahalelerde bulunmasi.Kurulum suresi Agile projelerde surekli dikkat
edilen metriklerden biri.
Anahtar teslim bu ortami kurmaniza yarayacak Thoughtworks un Buildix
adli bir ortami var.
http://buildix.thoughtworks.com/
Buildix ustunde Subversion, CruiseControl, Trac gibi araclarin kurulu
ve konfigure edilmis oldugu bir Fedora image i .
Testler , kurulum vs konularinda da kullandigimiz araclarin bazilari
su adreste.
http://opensource.thoughtworks.com/projects/index.html
> 2008/4/3 cenkcivici <cenk.civ...@gmail.com>:
> --
> Halil Bahadir
Surekli entegrasyon surecinde her gelistiricininde soyle bir
sorumlulugu var.
Herhangi bir kod degisikligini versiyon kontrole eklemeden once
Checkin Dansi dedigimiz bir surec izleniyor. Bu surece gore
1. Once Versiyon kontrolden ekibin yaptigi tum degisiklikler
aliniyor.
2. Gelistirici kendi makinesinde bir kurulum gerceklestiriyor. Bu
kurulum kodlari derliyor, birim testlerini calistiriyor.
3. Eger hata yoksa bundan sonra kod versiyon kontrole eklenebiliyor.
Bu sureci uygulamadan kodu checkinlemek Surekli entegrasyon etigine
uymaz.
Checkin sonrasi surekli entegrasyon sunucusu bu degisikligi gorup ayni
kurulumu tekrarliyor.
1. Amac benim makinamda calisiyordu burada niye calismiyor durumunun
olmamasi ve birden fazla gelistiricinin yaptigi degisikliklerin
birseyi bozmadigindan emin olabilmek
Surekli entegrasyonun "surekli" kismi aslinda tam olarak surekli
degil. Her degisiklikte bir entegrasyon anlaminda kullaniliyor.
Bu acidan en onemli kurulum her kod degisikliginde(her checkinde)
calisacak olan kurulum.
Bu kurulumun ideal suresi 10 dk nin altinda tutulmali. 10 dk yi
gectigi zaman ekip uyelerinin islerini yavaslatmaya basliyor. 10 dk
altinda olmasi prensibinin nedeni hizli geri beslenim alabilmek cunku
gelistirici son kurulumun durumuna bakmadan checkin yapamiyor ve
yaptigi degisikligin entegrasyonda da calistigi geri beslenimini
almasi gerekiyor. Kurulum suresi ne kadar uzarsa bu pratigin
uygulanmasi da zorlasiyor. Bu nedenle araclari secerken
optimizasyonlara gidebileceginiz, esnek araclar secmenizi tavsiye
ederim.
Eger bu sureyi asagiya cekmek mumkun degilse ornegin proje buyuklugu
buna izin vermiyorsa daha onceki emailde bahsettigim hizli kurulum,
entegrasyon, gecelik kurulum gibi bir gruplamaya gitmek cozumlerden
biri.
Ekibin teknik liderinin gorevlerinden biri bu kurulumun suresini
izlemesi ve uzama egilimi gosterdiginde kurulum suresini kisaltacak
mudahalelerde bulunmasi.Kurulum suresi Agile projelerde surekli dikkat
edilen metriklerden biri.
Anahtar teslim bu ortami kurmaniza yarayacak Thoughtworks un Buildix
adli bir ortami var.
http://buildix.thoughtworks.com/
Buildix ustunde Subversion, CruiseControl, Trac gibi araclarin kurulu
ve konfigure edilmis oldugu bir Fedora image i .
Testler , kurulum vs konularinda da kullandigimiz araclarin bazilari
su adreste.
http://opensource.thoughtworks.com/projects/index.html
> Halil Bahadir
cenkcivici
Apr 4, 2008, 9:33:26 AM4/4/08
to AgileTurk
Gecmisteki deneyimlerime dayanarak kurulumuzun zamani 10 dk nin ustune
cikmaya basladikca alinabilecek onlemlerden ilk aklima gelenler soyle
1. Kurulumun hangi asamada cok zaman harcadigini kurulum araciniz
(Ant,Nant, Maven ornegin) verbose modunda calistirarak ve logu analiz
ederek incelemek.
2. Bu analiz sonucu yavas calisan testler gordugunuzde bunlari
refactor edilmesi ve hizlandirilmasi.
3. Entegrasyon problemlerinin cokca yasandigi kurulum asamalarinin ilk
adimlara gerceklestirilmesi.
4. Makineniz guclu ise birbirinden bagimsiz test gruplarini paralel
calistirilmasi
5.Gelistirici semalarina datalarin yuklenmesi icin sql dosyalari
calistirmaktan ziyade oracle in datapump i gibi binary olarak datanin
alinmasini saglayan yontemlerle islemlerin hizlandirilmasi
6. Dbdeploy gibi araclar kullanarak veritabaninda yapisal
degisikliklerini incremental olarak gerceklestirilmesi.
7. Entegrasyon ortaminda CruiseControl un sorumlulugu birden fazla
makineye dagitmasi. Web Farm gibi Build Farm kurulmasi.
8. Build Farm yapisinini avantaji kullanacak ornegin SeleniumGrid gibi
eklentilerin kullanima alinmasi.
9. Lokal kurulumlarda gercek db yerine Hsqldb gibi in memory calisan
hizli db engine lerinin test amacli kullanimi.
10. Testlerde birim, entegrasyon, kabul testi ayrimina dikkat
edilmesi.
> adli bir ortami var.http://buildix.thoughtworks.com/
cikmaya basladikca alinabilecek onlemlerden ilk aklima gelenler soyle
1. Kurulumun hangi asamada cok zaman harcadigini kurulum araciniz
(Ant,Nant, Maven ornegin) verbose modunda calistirarak ve logu analiz
ederek incelemek.
2. Bu analiz sonucu yavas calisan testler gordugunuzde bunlari
refactor edilmesi ve hizlandirilmasi.
3. Entegrasyon problemlerinin cokca yasandigi kurulum asamalarinin ilk
adimlara gerceklestirilmesi.
4. Makineniz guclu ise birbirinden bagimsiz test gruplarini paralel
calistirilmasi
5.Gelistirici semalarina datalarin yuklenmesi icin sql dosyalari
calistirmaktan ziyade oracle in datapump i gibi binary olarak datanin
alinmasini saglayan yontemlerle islemlerin hizlandirilmasi
6. Dbdeploy gibi araclar kullanarak veritabaninda yapisal
degisikliklerini incremental olarak gerceklestirilmesi.
7. Entegrasyon ortaminda CruiseControl un sorumlulugu birden fazla
makineye dagitmasi. Web Farm gibi Build Farm kurulmasi.
8. Build Farm yapisinini avantaji kullanacak ornegin SeleniumGrid gibi
eklentilerin kullanima alinmasi.
9. Lokal kurulumlarda gercek db yerine Hsqldb gibi in memory calisan
hizli db engine lerinin test amacli kullanimi.
10. Testlerde birim, entegrasyon, kabul testi ayrimina dikkat
edilmesi.
>
> Buildix ustunde Subversion, CruiseControl, Trac gibi araclarin kurulu
> ve konfigure edilmis oldugu bir Fedora image i .
>
> Testler , kurulum vs konularinda da kullandigimiz araclarin bazilari
> su adreste.http://opensource.thoughtworks.com/projects/index.html
> Buildix ustunde Subversion, CruiseControl, Trac gibi araclarin kurulu
> ve konfigure edilmis oldugu bir Fedora image i .
>
> Testler , kurulum vs konularinda da kullandigimiz araclarin bazilari
Reply all
Reply to author
Forward
0 new messages