Ana içeriğe atla

Build Automation and Continuous Integration

Başta XP (eXtreme Programming) olmak üzere, çevik yazılım geliştirme süreçlerinde; set otomasyonu ve sürekli tümleştirme (Build Automation and Continuous Integration) işlemleri önemli bir yer tutmaktadır. Bu işlemlerin temel amacı, set yapımı ve kod entegrasyonu maliyetlerini düşürmektir. Ek olarak, ileride yapılacak geliştirmelere bağlı olarak değişim maliyetlerini düşürmek hedeflenmektedir.
Büyük ve kapsamlı projelerin set yapım süreçleri de aynı derecede karmaşıktır. Farklı birçok kişi ya da grupların çalışmış olduğu projelerin ve dosyaların bir araya getirilmesi, entegre edilmesi ve uygulamaların test edilmesi yüksek maliyetler oluşturmaktadır. Bu işlemlerin süreklileştirilmesi ve otomatikleştirilmesi, ayrıca yazılım geliştirme süreçlerinin bir parçası haline getirilmesi, önemli kazanımlar getirecektir. İşte tam da bu noktada FinalBuilder gibi çeşitli uygulamalar kullanılmaktadır. FinalBuilder, Vsoft Technologies firmasının geliştirmiş olduğu görsel olarak oluşturulabilen scriptleri ile kullanımı oldukça kolay ve güçlü bir “Automated Build & Release Management” aracıdır.

Bu süreçleri özetlemek gerekirse, yazılım ekipleri tamamlamış oldukları geliştirmeler sonucunda, proje ve  dosyalardaki değişikliklerin kaynak kod kontrol sistemine gönderilmesi ile başlayacaktır. Sonrasında;
  1. Set yapımının gerçekleştiği serverda sürecin tetiklenmesi. Bu işlem bir değişiklik algılandığında yada belirli zaman aralıklarında başlayacak şekilde oluşturulabilir. Her gün akşam saatleri çalışacak şekilde yönetilebilir. Optimum yöntemi kendi süreçlerinize göre belirliyebilirsiniz.
  2. Kaynak kodun ve dosyaların son halinin kaynak kontrol sisteminden alınması (TFS yada SourceSafe gibi uygulamadan kodun son halinin yerel klasörlere alınması.)
  3. Set yapımı sırasında değişiklik yapılacak dosyaların check-out’lanması ve tüm projelerin versiyonlanması.
  4. Önceki setlerin sistemden kaldırılması ve derleme öncesi gerekli dosyaların silinmesi.
  5. Tüm kaynak kodların derlenmesi ve farklı projelerde oluşturulan dosyaların kullanılması durumlarında, derleme sırasında gerekli yerlere kopyalanması. Ve derleme işlemlerinin tamamlanması
  6. Set yapımına başlamadan önce sürece olumlu katkıları olacak çeşitli analizlerin ve birim testlerinin yapılması ve raporlanması sürecinin işletilmesi
    • Statik kod analizlerinin çalıştırılması ile kod karmaşıklıklarının tespit edilmesi, kod standartlarının kontrolü işlemleri yapılması ve raporlanması
    • Dinamik kod analizlerinin çalıştırılması ve olası performans sorunlarının tespit edilmesi ve raporlanması
    • Çeşitli tasarım metriklerinin oluşturulması ve raporlanması
    • Birim testlerinin çalıştırılması ve yapılan değişikliklerin, birimlerin kendi başına hatasız görevlerini yerine getirip getirmediğinin tespiti ve sonuçların raporlanması
    • Kod kapsam analizlerinin yapılması ve raporlanması
  7. Set uygulamalarının çalıştırılması ve yeni setlerin oluşturulması
  8. Yeni setlerin sisteme kurulması ve testlerin başlaması için uygun ortamın hazırlanması
  9. TestComplete gibi bir test aracı ile testlerin çalıştırılması
    • Entegrasyon testlerinin çalıştırılması ve raporlanması
    • Fonksiyonel testlerin çalıştırılması ve raporlanması
    • Kabul testlerinin çalıştırılması ve raporlanması
  10. Set ve Test sürecinde kod ve dosyalar üzerindeki değişikliklerin kaynak kontrol uygulamasına gönderşlmesi (Check-in işleminin yapılması)
  11. Yayınlanacak sete ait kaynak kod ve dosyaların “Etiketlenmesi” ve gerektiğinde ilgili kodlara ulaşılabilmesinin sağlanması (TFS Apply Label işleminin yapılması)
  12. Set’in yayınlanması ve ilgili değişikliklerin raporlanması
  13. Sonuç raporların ilgili kişilere mail ile iletilmesi
Bu işlemlerin süreklileştirilmesi kodun her an denetiminin yapılması ve geri bildirim verilmesi anlamına gelecektir. Bu işlemlerin ardından ilgili raporların değerlendirilip gerekli düzelmelerin hemen koda eklenmesi, süreç içersinde mutlaka işletilmelidir. Böylelikle refactoring ve reengineering işlemleri süreklileştirilmiş olacak ve kodun her an yayınlanabilir durumda bulundurulması sağlanabilecektir. Hata oluşma riski azalacak ve hataların yayınlanmadan hatta test edilmeden ortaya çıkması sağlanabilecektir.
Uzun zaman önce yapılan geliştirmelere ait test scriptlerinin sürekli çalıştırılacak olması, yapılan geliştirmelere bağlı hataların tekrar ortaya çıkmasını önleyecektir. Test ekibinin tekrar tekrar aynı testleri yapması sorununu çözecektir. Bu nedenle kod büyüdükçe hem yeni fonksiyonel testlerin hem de hatalara istinaden oluşacak yeni birim testlerinin sürece tekrar dahil edilmesi gerekmektedir.
Set otomasyonu, set yapılması kolaylaşacak ve buradaki zaman kaybını önleyecektir. Test ekibine büyük iş hacmi oluşturan ve sürekli tekrar edilmesi gereken standart testler otomatikleşecek, test ekibinin, gerçek anlamda testlere odaklanabilmesine olanak sağlayacaktır.
Projenin dağıtımı öncesinde testlerde ortaya çıkabilecek büyük değişiklikleri gerektiren geliştirmeler projenin gecikmesinde önemli bir risk oluşturmaktadır. Sürekli tümleştirme yaklaşımları ile bu tip gecikmeler en aza inecektir. Planlanan set dağıtım tarihleri aşılmayacaktır. Sıklıkla teslimatlar yapılabilecektir. Daha hatasız setler ile kolay ve sorunsuz kurulumlar yapılabilecektir.
Ayrıca TFS gibi bir araç yardımı ile kodun minor ve major değişiklikler için sahadaki farklı versiyonlarının farklı branchlerde tutulması sağlanmalıdır. İlgili kod branchlerinde oluşturulan test ve set scriptlerinin de bulundurulması önem kazanacaktır. Her versiyon için bu test sürecinin otomasyonu, eski versiyonlarda da yapılacak değişikliklerin maliyetini düşürecektir.
Uygar MANDUZ

Yorumlar

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara