Team Foundation Build

     Yazılımın kalitesini arttırmak için ilk yol güçlü bir versiyon kontrolü kullanmaktır. Sonraki aşama ise otomatik build işlemi uygulamaktır. Yazılım geliştirme sürecinde müşteriye uygulamanın çalışan halini gösterip geri bildirim almak önemlidir ama yazılımın çalışan parçasını toplayıp göstermek gereğinden fazla zaman harcamanıza neden olur. Bunun için build sürecini otomatikleştirerek ilerleyişi gösterebilir ve geri bildirim alabilirsiniz. [1]

     Build otomasyonu, basit, tek bir işlem ile uygulamanızı birleştirip kullanılabilir ürün haline getirme yeteneğidir. Genellikle build otomasyonu sadece kaynak kodu derlemeyi değil, ayrıca dökümantasyon oluşturma, testleri çalıştırma, derlenen kodu manuel test için bulundurma gibi işlevleri de içerir.[1]

     Visual Studio üzerinde F5 tuşuna basarak kendi uygulamanızı çalıştırabiliyorsunuz. Bu işlem sadece yerel çalışma alanınızdaki kodu derler ve onu çalıştırır. Ancak, bu işlem projenizdeki diğer geliştiricilerin son kodu ile çalışmasını sağlamamaktadır. Ayrıca otomatik testleri çalıştırmak için de izin vermez. [1]

     Build sunucusu tüm uygulamayı derlemeyi neredeyse geliştiricilerin F5'e basması kadar kolay hale getirir. Build sunucusu versiyon kontrol sistemindeki değişiklikleri takip eder ve projenin son sürümünü kullanarak otomatik build yapar. Genellikle build manuel olarak, belirli bir zaman çizelgesine göre ya da her check-in işleminde (Continuous Integration olarak bilinir.) tetiklenir. [1]

     Build işlemini otomatikleştirmek yazılım sürecinde oluşabilecek hataların ortaya çıkmasını sağlamaktadır. Çoğu yazılım uygulaması fazlasıyla karışıktır ve manuel olarak build etmek hem fazla zaman alır hem de hatalara sebep olabilir. Bu yüzden build işlemini otomatikleştirmek olası hataların önüne geçmektedir. [1]

     Team Foundation Build (TFBuild) Team Foundation'ın bir parçasıdır. TFBuild ile uygulamalarınızı otomatik derleyen ve test eden build işlemlerini oluşturabilir ve yönetebilir ve diğer önemli işlevleri gerçekleştirebilirsiniz. Build yöneticileri kaynakları senkronize edebilir, uygulamayı compile edebilir, ilgili unit testleri çalıştırabilir, kod analizi yapabilir, file sever üzerindeki buildleri serbest bırakabilir ve build raporlarını yayınlayabilirler. TFBuild ve TFS Versiyon Kontrol'ün iş birliğinin bir çok faydası bulunmaktadır. TFBuild önceki yazımlarımda bahsettiğim iş öğesi izleme sistemi gibi kolaylıkla vesiyon kontrol bilgilerine erişebilir. Ayrıca TFS tarafından sunulan raporlama yeteneği ile buildlerinizin durumu ile ilgili ayrıntılı bilgi sunulur. [1]

     Otomatik build çalıştırmak için önce build tanımlamanız gerekmektedir. Build tanımı, build için ne gerekiyor ve ne zaman olmadı gibi ayrıntıları açıklar. Build tanımına başlamak için Visual Studio Team Explorer menüsünden Builds linkini seçerek başlanır. Şekil 1'de görülen build sayfası projenizdeki tüm build tanımlamalarını gösterir ve yönetmenize izin verir.

Şekil 1: Build Sayfası

    Team Explorer build sayfasında "New Build Definition" linki ile yeni build tanımlaması yapmak için form açılmaktadır. Burada 6 farklı sekme bulunmaktadır, bunları tek tek açıklamak gerekirse;

     1.General Sekmesi
     Şekil 2'de görülen  general sekmesinde build için isim ve açıklama girilir. Ayrıca queue processing seçenekleri belirlenir.

• Enabled: Default seçenektir. build kuyruğa eklendiği zaman çalıştırılmasını sağlar.
• Paused: Build kuyruğa eklendiği zaman tetiklenir ama aslında başlamaya zorlanmadan çalışmaz.
• Disabled: Bu tanımlama ile hiç bir buildin tetiklenemeyeceği anlamına gelir.

Şekil 2: General Sekmesi

      Burada Enable seçerek ilerliyoruz. 

      2. Trigger Sekmesi
     Şekil 3'te görülen trigger sekmesi buildin ne zaman çalıştırılacağını Team Foundation Server'a bildirir. 5 farklı trigger seçeneği mevcut: 

• Manual: Build sadece açıkça kuyruğa eklendiği zaman çalışır.
• Continuos Integration: Her check-in işleminde build kuyruğa eklenir. 
• Rolling Builds: Continuous Integration'a benzer şekilde ama build sayısını azaltmak için belirli sayıda check-in olduktan sonra build çalıştırılır.        
• Gated Check-in: Check-in sonrasında belirlenen sayıda başarılı merge ve build işleminden sonra çalıştırılır.
• Schedule: Belirlenen bir çizelgeye göre vakti geldiği zaman çalıştırılır.

   

Şekil 3: Trigger Sekmesi

     Continuous integration seçerek devam ediyoruz. 

     3. Source Settings Sekmesi
     Şekil 4'te görülen Source Control Folder sekmesinde build için kullanılacak dosya yolu belirtilir. Bu sayede Team Foundation Server'daki hangi dosyaların build ile ilgili olacağını belirtir ve bu dosyalar build çalıştığı sürece diskte tutulur. Default olarak projenin kökü seçili olur. Bu seçim normalde çok geniş olur ve sadece uygun dosyaları içeren dosya yolu seçilmelidir. 

     Build Agent sekmesi biraz kafa karıştırıcı. Build sırasında controller TFS'den kaynak kod dosyalarını alıp build agent'a gönderir. Build Agent Folder build agent sunucunda bu dosyaların gönderildiği yeri göstermektedir. "$(SourceDir)" TFS tarafından kullanılan başlangıç noktası gösterimidir.

     Dosyalar Cloaked olarak işaretlenirse build makinesine kopyalanmasına gerek olmaz, bu da zaman ve masraf olarak azalma sağlar.
     

Şekil 4: Source Settings Sekmesi

     Sadece tek solution build etmek istediğim için ben default ayarlar ile devam ediyorum fakat birden fazla solution build etmek isterseniz hepsinin ayrı bir source directory'ye ihtiyacı olur. Burada "$(SourceDir)" in sonuna "/proje1" gibi tanımlamalar eklenerek istenilen kadar solution build edilebilir. 

     4. Build Defaults Sekmesi

     Şekil 5'te görülen Build Defaults sekmesinde kullanılacak olan build controller seçilir. Büyük ihtimalle zaten bir tane cotroller bulunur. "Staging Location" altında build output dosyalarının kopyalanma seçenekleri için 3 seçenek mevcut (3. seçenek TFS 11'den sonra gelmiştir.) İkinci seçenekte bir network adresi belirtmek zorundasınız.

Şekil 5: Build Defaults Sekmesi

    

     Eğer ekibinizin bu buildden gelen binarylere ihtiyacı varsa 3. seçeneği seçmelisiniz. Ben ilk seçenek ile ilerliyorum.

     5. Process Sekmesi

     Şekil 6'da görülen process sekmesi build tanımlamasının özünü oluşturmaktadır. Build template burada oluşturulur. Buildin işleyeceği Windows Workflow tabanlı process'in seçimi yapılır. Burada ilk process ekip projenizin process template'ı tarafından belirlenir. Default olanı seçiyorum ama "New" butonu ile yeni process eklenebilir. Burada process seçildikten sonra altında özellikleri listelenir. Input gerektiren özellikler dikkat işareti ile belirtilir. Build sekmesi altında Project kısmına solutionınızı eklemeniz gerekmektedir.

Şekil 6: Process Sekmesi

   

     6. Retention Policy Sekmesi

     Son sekme pek önemli değil. Sadece bazı build tiplerinin ne kadar süreyle tutulacağının tanımını içerir. Normalde default seçenekler herhangi bir proje için yeterlidir. 

    Tüm aşamaları tamamladıktan sonra kaydederek build tanımlamasını tamamlıyoruz. Artık her check-in işleminden sonra otomatik olarak build yapılacaktır.

      İlk yazımda bahsettiğim Application Life Management (ALM) için build otomasyonu çok önemlidir. Ayrıca TFS build otomasyonu etrafında güzel özellikler sunmaktadır. Eğer teslim edeceğiniz yazılımın kalitesini önemsiyorsanız build otomasyonu konusunda ciddi olmalısınız.

      Okuduğunuz için teşekkürler...






Referanslar:

[1] Build Automation, https://visualstudiomagazine.com/articles/2012/03/15/a-primer-on-microsoft-build-automation.aspx, 14.05.2015