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...

Team Foundation Server ile İş Öğesi Sorguları (Work Item Query)

     Sorgular (query) gözden geçirmek, güncellemek, rapor oluşturmak gibi işlemler için bulmak istediğiniz iş öğelerinizi bulmanıza yardımcı olur. İş öğelerini bulmak için search box'ı da kullanabilirsiniz ama iş öğelerinin düz listesini, hiyerarşik listesini veya bağımlılıkları gösteren listesini istiyorsanız filtre ölçütünü ayarlamak için sorgu düzenleyici (query editor) kullanmanız gerekmektedir. Sorguları Web Access ve Team Explorer üzerinden oluşturabilirsiniz. Ayrıca toplu değişiklikleri uygulamak için Excel veya Project içinde bir sorgu açabilirsiniz.
   
     1. İş Öğelerini Bulmak için Search Box Kullanma 
     Şekil 1'de görüldüğü gibi Team Explorer üzerindeki search box ile iş öğelerini bulmak mümkün. İster iş öğesinin ID yada adını girerek ister yandaki menüsü sayesinde filtre uygulayarak istenilen iş öğeleri bulunabilir.

Şekil 1: Search Box

     Filtre kısmındaki kısayolların örnekleri;

• A = Assigned To (Örneğin, bana atanmış işler için A:@me) 
• C = Created By (Örneğin, Ali tarafından oluşturulmuş iş öğeleri için C:Ali)
• S = State (Örneğin, durumu yeni olarak belirtilmiş iş öğeleri için S=New)
• T = Work Item Type (Örneğin, task tipinde olan iş öğelerini bulmak için T=Task) [1]

     Filtre için eşittir (= , tam eşleşme gerektirir.), içerir (: , bir kısmının eşleşmesi yeterlidir.), değildir (- , sadece alan isimlerinde kullanılır, belirtilen text dışındakiler için geçerlidir.)  operatörlerini de kullanabiliriz. Örnek vermek gerekirse;

Ali'ye atanan ve aktif olmayan iş öğeleri                                         >>>>>   A:Ali -S=Active
Activity alanı Development olmayan iş öğeleri                               >>>>>   -Activity = Development
Bug tipinde aktif olan ve başlığında new geçmeyen iş öğeleri     >>>>>   S=Active T=bug -Title:new

     2. Düz Liste Sorgusunu Açma ve Düzenleme
     Sorgu tanımlamanın en kolay yolu her süreç şablonu için önceden tasarlanmış olan sorgularla (shared query) başlamaktır. Şekiller ile göstereceğim örnekte Agile süreç şablonu tarafından sağlanan Active Bugs shared query'yi değiştirerek tüm kapalı hataların nasıl bulunacağını anlatacağım. Şekilleri Web Access üzerinden göstereceğim fakat Team Explorer üzerinde Work Items menüsünden de aynı adımlarla yapabilirsiniz.

     İlk olarak şekil 2'de adım adım gösterildiği yerden shared query açılır. Örnek olarak Active Bugs seçiyorum.
   

Şekil 2: Shared Query

     Burada state kısmı default olarak Active gelmektedir. Ben kapalı olanları bulmak istediğim için Closed olarak düzenliyorum ve istediğim düzenlemeleri yaptıktan sonra  5. adım ile gösterilen yerden sorgumuzu çalıştırıyoruz.   ile gösterilen yerden yeni bir filtre ekleyebiliyoruz ve  ile gösterilen yerden istenilen filtreyi silebiliyoruz.

     Düzenlediğimiz sorguyu kaydetmek için şekil 3'te gösterildiği gibi farklı kaydet butonundan istenilen kayıt seçilerek kaydediyoruz. Ben My Queries klasörüne kaydediyorum. 

     

Şekil 3: Shared Query Kaydetme 

     Kayıt işlemini tamamladıktan sonra sorgumuzu My Queries klasörü altında görebiliriz. Sorguyu Shared Queries klasörü altına kaydedebilmek için takım yöneticisi, proje yönetici grubu üyesi ya da katkıda bulunma izinlerinizin klasörde izin ver olarak ayarlanmış olması gerekmektedir. 

     3. Sorgu Oluşturma

     Şekil 4'te gösterilen Web Access üzerindeki yeni menüsünden ya da Team Explorer üzerindeki New Query linkinden istediğiniz filtreleri kullanarak sorgu oluşturabilirsiniz. Sorgular My Queries klasörü altına kaydedilir.

Şekil 4: Yeni Sorgu

     4. Sorgularda İzinleri Ayarlama

     TFS'de çoğu nesnede olduğu gibi shared query'leri düzenlemeye veya oluşturmaya kimlerin erişebileceğini kontrol edebilirsiniz. Default olarak sadece proje yönetici grubunun üyesi olanların yetkisi bulunmaktadır. Her kullanıcı kendine ait sorguları oluşturup düzenleyebilir ve kendi My Queries klasörü altına kaydedebilir. 

     

     İzinleri Web Access, Team Explorer ( Visual Studio 2013.2 Update gereklidir) üzerinden ayarlayabilirsiniz. Eğer Eclipse üzerinde Team Explorer kullanıyorsanız izinleri buradan değil Web Access ile yapmanız gerekmektedir. Default olarak sadece proje yönetici grubunun üyesi olanlar izinleri düzenleyebilirler. 

     İzinleri bir örnek ile göstermek gerekirse, şekil 5 'te gösterildiği gibi Shared Queries linkine sağ tıklayarak yeni bir klasör oluşturup buraya olan izinleri ayarlayacağız. 

Şekil 5: Yeni Sorgu Klasörü

     Kaydettikten sonra oluşturduğunuz klasör Shared Queries altında görülmektedir. İzinleri ayarlamak için bu klasöre sağ tıklayıp Güvenlik seçeneği ile şekil 6'daki pencereyi açıyoruz. 

Şekil 6: İzin Penceresi [2]

      Add menüsü ile yeni bir kimlik ya da TFS grubu ekleyerek bunların da izinlerini ayarlayabilirsiniz. 

     Contribute, takım üyelerine belirtilen klasördeki sorguları düzenleme ve oluşturma yetkisi vermektedir. Manage Permission, belirtilen klasördeki sorgu ve alt klasör yönetimi için yetki vermektedir. 

     5. Hiyerarşik Listeyi Görüntülemek için Tree Query ( Ağaç Sorgusu) Kullanımı

     Çok katmanlı, iç içe geçmiş çalışma öğelerinin listesini görüntülemek için sorgu düzenleyicideki  tree query ( Çalışma Öğeleri Ağacı) kullanabilirsiniz. Şekil 7'deki tüm biriktirme listesi öğelerini ve bunların bağlı görevlerini görüntüleyen bir örnek görülmektedir. Burada ağacın farklı kısımlarını incelemek için genişletip () , daraltabilirsiniz ().

Şekil 7: Bir Tree Query Sorgu Sonucu [1]

     Alt ve üst (parent, child) iş öğeleri için filtre kriterleri tanımlayabilirsiniz. Şekil 8'de sorgu düzenleme ekranında görüntülenen bu filtre seçenekleri görülmektedir.

Şekil 8: Çalışma Öğeleri Ağacı

     Bağlı alt öğeleri bulmak için, Match top-level work items first (Önce üst düzey çalışma öğelerini eşleştir) seçebilirsiniz. Bağlı üst öğeleri bulmak için Match linked work items first (Önce bağlantılı çalışma öğelerini eşleştir) seçebilirsiniz. 

     6. Bağımlılıkları Görüntülemek için Doğrudan Bağlantı Sorgusu ( Direct Link Query) Kullanımı
     Task, bug, issue ya da feature gibi diğer iş öğelerine bağlı iş öğelerini izlemek için doğrudan bağlantı sorgusu ( Direct Link Query) kullanabilirsiniz. Şekil 9'da düzeltilmekte olan hataya göre ya da diğer öğelere uygulanmakta olan biriktirme listesi öğelerini görüntüleyen bir örnek görülmektedir.

Şekil 9: Doğrudan Bağlantı Sorgu Sonucu

     Diğer ekiplerin üzerinde çalıştığı ekibinize ait bağımlılıkları izlemek ya da ekibinizin diğer ekiplere verdiği taahhütleri yönetmek için doğrudan bağlantı sorgusunu kullanabilirsiniz. Şekil 10'da görüldüğü gibi sorgu düzenleme penceresinden hem üst hem de bağlı iş öğeleri için filtreleme kriteri belirtebilir ve bağımlılıkları filtrelemek için kullanılan bağlantı türlerini seçebilirsiniz. 

Şekil 10: Doğrudan Bağlantı Sorgusu

     İş öğelerinin ilk katman listesini aşağıdaki seçeneklerden birini seçerek filtreleyebilirsiniz:

• Only return work items that have the specified links (Yalnızca belirtilen bağlantıları olan iş öğelerini döndürün): Yalnızca, bağlı iş öğeleri filtreleme ölçütleri tarafından belirtilen iş öğelerine bağlantılara sahip olan ilk katman iş öğeleri döndürülür.
• Return all top level work items (Bütün tepe seviye iş öğelerini döndürün): Bütün birinci katman iş öğeleri, bağlı iş öğeleri filtreleme ölçütlerine bakılmaksızın, döndürülür. İlk katmana bağlanan ikinci katman iş öğeleri, bağlı iş öğeleri filtreleme ölçütleri ile eşleşirlerse döndürülürler.
• Only return work items that do not have the specified links (Yalnızca belirtilen bağlantıları olmayan dönen iş öğeleri): Yalnızca, bağlı iş öğeleri filtreleme ölçütleri tarafından belirtilen iş öğelerine bağlantılara sahip olmayan ilk katman iş öğeleri döndürülür. [1]

     7. Check-in'leri İş Öğeleri ile İlişkilendirme
     Kod tabanınızdaki dosyaları değiştirdiğinizde, bunu genellikle bir görevi tamamlamak, hata ayıklamak veya bir iş öğesi talebini karşılamak için yaparsınız. Değişiklikleri check-in yaptığınızda, check-in yaptığınız değişikliklerle iş öğelerini ilişkilendirmeniz gerekir. Bu sayede:

• Çalışma öğesine bakan bir takım üyesi yaptığınız işi görmek için değişiklik kümesine doğrudan bağlanabilir.
• Değiştirdiğiniz dosyanın geçmişini gözden geçiren bir takım üyesi değişiklik kümesini görüntüleyebilir ve değişiklik için gerekçe olan iş öğelerini görebilir.
• Yaptığınız değişiklikleri otomatik build sisteminizde build ediyorsanız, ekip üyeleriniz hangi tamamlanmış build içerisinde görevin tamamlandığını veya hatanın giderildiğini görüntüleyebilir.

      İş öğelerini check-in'lerinizde ilişkilendirmek için iki seçenek mevcut. İster iş öğesinin ID'si ile ister kayıtlı sorgularınız üzerinden ilişkilendirebilirsiniz. 

     ID ile yapmak için check-in yapmadan önce Team Explorer'da şekil 11'de görüldüğü gibi "Related Work Items" kısmında "Add Work Item by ID" seçilerek, ilgili iş öğesinin ID'si girilerek eklenir. 

Şekil 11: Add Work Item by ID

     Sorgu ile yapmak için yine check-in yapmadan önce Team Explorer'da şekil 12'de görüldüğü gibi "Queries" kısmında My Queries klasörü altındaki iş öğeleriniz listelenir. İlgili iş öğesinin bulunduğu sorgu seçilir ve açılan sonuç sayfasında ilgili iş öğesini sürükleyip Team Explorer'da "Related Work Items" kısmına bırakılır. 

Şekil 12: Query Listesi

     Her iş öğesinin yanında, check-in işleminizle ilgisinin nasıl olacağını belirtmeniz gerekmektedir. İlişkilendir (Associate) veya Çözümle (Resolve) (yalnızca iş öğesi bu ilişkiyi engelleyen çözümlendi, tamamlandı, kapatıldı gibi durumlarda değilse kullanılabilir) seçeneklerinden uygun olan seçilierek check-in yapılır.

     Bu haftalık yazımı burada bitiriyorum. Haftaya Team Foundation Build konusundan bahsedeceğim.
Okuduğunuz için teşekkürler...