|
Sürekli Tümleştirme (Continuous Integration)
Yazılım Mimarisi kategorisi içerisinden Sürekli Tümleştirme (Continuous Integration) konusunu görüntülemektesiniz, Aşağıdaki gibi bir eviniz olmasını ister misiniz ? Frmhigh.Com - Sürekli Tümleştirme (Continuous Integration) Evet seslerini duyar gibiyim. Yanlız bir sorun var, bu ev legolardan yapılmış. Biliyorum hayal de olsa …
 |
| | LinkBack | Seçenekler | Stil |
11-20-2008, 22:32
| #1 (permalink) |
 Sürekli Tümleştirme (Continuous Integration) 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 [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] 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 ([Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*, [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın],[Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]), Ø Oluşturma scripti geliştirecek araç ([Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*, [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]), Ø Uygulamanın fonksiyonalitesini testlerini ,birim testlerine, kabul testlerine, fonksiyonalite testlerine vb, çalıştıracak araç ([Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*, [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*), Ø Kodun statik analizini yapacak araç ([Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*) Ø 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ç ([Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın], [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*,[Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın]*) 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: [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] [Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] <------------------------------------------------------------------------------------------->[Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] ecza & tavuk_kavurma.................... ölümüne kankayız  | |
 |
|
11-21-2008, 00:01
| #2 (permalink) |
| 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... Paylaşım için teşekkürler <-------------------------------------------------------------------------------------------> Alametifarika  Dark@ngeL  | |
| |
amç yazmak olsun 
|
11-21-2008, 01:39
| #4 (permalink) |
| rica ederim <------------------------------------------------------------------------------------------->[Üye Olmayanlar Forumdaki Linkleri Göremezler.Ücretsiz Üye Olmak İçin Tıklayın] ecza & tavuk_kavurma.................... ölümüne kankayız | |
| |
|
« Önceki Konu
|
Sonraki Konu »
| Seçenekler | |
| Stil | |
Normal
| |
| ||||
| Konu | Konuyu Başlatan | Forum | Cevaplar | Son Mesaj |
| Sürekli PC basinda olanlar iyi okusun!!! | carizm@ | Sağlık | 0 | 11-03-2008 23:43 |
| sürekli kapanmasına sebep olan virüs | **ÖzGE** | Msn, Icq, IRC, Yahoo Messenger, Skype, Trillian | 1 | 09-30-2008 18:12 |
| Hamilelikte Sürekli Yorgunluk Hissi | NeMeSiS | Gebelik | 0 | 08-28-2008 14:42 |
| Yasin sürekli kaleye geçiyormuş | d3li35-5 | Fenerbahçe | 0 | 02-29-2008 11:00 |
| Dosya Upload Siteleri (Sürekli Eklenecek !) | NonStop | Bookmark | 1 | 01-18-2008 20:40 |
Bütün Zaman Ayarları WEZ +3 olarak düzenlenmiştir. Şu Anki Saat: 04:33 .
