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

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

     Merhaba arkadaşlar, ilk yazımda bahsettiğim gibi Team Foundation Server, küçük projelerden tutun yüzlerce yazılım uzmanının yer aldığı çok geniş projelere kadar yazılım geliştirme sırasında ihtiyaç duyulacak bir çok alt sistemi bünyesinde barındırır. Bu alt sistemlerden Versiyon Kontrol özelliğinden bahsettim şimdiye kadar. Sıra geldi Work Item Tracking (İş Öğesi Takibi) konusuna değinmeye.

     TFS üzerindeki en büyük yapı bir Takım Projesi (Team Project)'dir. Önceki yazılarımda anlattığım gibi bir Takım Projesinin kaynak kod kontrol sisteminde kendine ait bir alanı (work space), Work Item Tracking sisteminde kendine ait form tipleri vardır ve Work Item (iş öğesi) bunlara verilen genel isimdir. Work Item dediğimiz; metin alanlardan, çoktan seçmeli listelerden, sekmelerden vs oluşan elektronik bir formdur. Kullandığınız süreç şablonuna (process template) göre tipleri farklılık gösterir. Örneğin TFS içerisinde hazır olarak gelen CMMI şablonunu kullanırsanız Gereksinim (Requirement), Değişiklik İsteği (Change Request), Hata (Bug), Görev (Task) gibi Work Item tipleri ile karşılaşırsınız. Her birinin kendilerine özgü alanları ve ortak alanları vardır. [1]

     Work Item'ları işlerinizi takip etmek için kullanırsınız. Örneğin bir projede yapılacak işleri gereksinim tipinde Work Item'lar olarak sisteme alırsınız. Bunlarla ilgili açıklamaları üzerine yazarsınız. Analizi derinleştirecek detaylı dosyaları bunların ekine iliştirirsiniz.Daha sonra bunları ekibinize paylaştırmak için alt görevlere böler ve her bir görev için bir Work Item açıp ilgili kişinin üzerine atarsınız. Tabii ki alt görevleri ana gereksinim maddesiyle eşlersiniz. Onlar da görevlerini bitirdikçe bu kayıtları kapatırlar. [1]

     Proje sırasında gelen değişiklik isteklerini de birer Wrok Item yapar ve gereksinimler ile ilişkili olarak kaydedersiniz. Neyin değişmesinin istendiğini ve bunun analizini yazarsınız.[1]

     Yazılım teste çıktığında dönen hataları da bu gereksinimle ya da değişiklik isteğiyle ya da görevlerle ilişkili olarak sisteme girersiniz. Hata mesajını, tanımını, varsa ekran görüntülerini hata kaydına girersiniz.[1]

     Bütün bunları yaptığınız zaman projenin herhangi bir anında proje kapsamında neler varmış, kimlere paylaştırılmış, ne kadarı bitmiş, daha yapılacak kimin üzerinde ne kadar iş var, hangi işler için ne değişiklik istenmiş, ne için ne kadar kod yazılmış, nasıl test edilmiş, hangi koddan ne kadar hata çıkmış, hataları düzeltmek için ne değişiklikler yapılmış gibi daha bir çok soruya cevap verebilir durumda olursunuz. Bu sayede proje ilerleme raporundan tutun da gereksinim toplama sürecinin etkinliğine, modüllere göre hata yoğunluğundan gereksinim/test kapsama raporuna kadar her raporu hazırlayacak altyapınız olur.[1]

     Ya da tam ters yönden bakacak olursak kodlara altan üstten bakıp da neden yazıldığını anlayamadığınız o iki satırın başında saçlarınızı yolarken TFS'in "Annotate" komutunu kullanarak her bir dosyadaki her bir satır kodun hangi tarihte kim tarafından ne için yazıldığını, neden değiştiğini, nasıl test edildiğini vs. görebilirsiniz.[1]

     Work Item'lar AreaPath ve IterationPath alanlarını kullanarak alt gruplara ayırılabilir. Örneğin projelerin, modüllerin, versiyonların vs işlerini ayrı takip etmek için bu alanlar kullanılabilir. Bu alanlara ağaç yapısında tanım yapmak mümkündür.[1]

     Work Item'lar kişilerin üzerine atanır. Elden ele gezebilir. TFS üzerine Work Item atılan kişiye otomatik e-posta gönderir. Kendinize ya da bir başkasına atanmış olan Work Item'ları listeleyebilirsiniz. Kişilerin üzerindeki işleri takip edebilirsiniz.[1]

     Her bir Work Item'ın oluşturulduğu günden son haline kadar olan tarihçesi TFS tarafından saklanır ve görüntülenir. Bu sayede herhangi bir Work Item'ı hangi tarihte kim oluşturmuş, kime atanmış, hangi alanlarına neler yazmış, kimler ne değişiklikler yapmış vs. gibi bilgilere ulaşmak mümkündür.

      Ayrıca Work Item 'lar ilişkiler konusunda da yeteneklidir. Bir Work Item'ın ekine herhangi bir tipte bir dosya iliştirmek mümkündür, Kaynak kod kontrol sisteminden bir changeset (değişiklik kümesi) ile ilişkilendirip (Bunu da herhangi bir changeset'i check-in ederken ilişkili bir Work Item seçerek yaparsınız.) ya da diğer bir Work Item ile ilişkilendirip tip bile tanımlayabilirsiniz.[1]

     Work Item'ın ne olduğundan, ne için kullanıldığından bahsettik, şimdi pratik kısmına gelirsek Work Item oluşturmak için Visual Studio Online, Team Web Access ve Team Explorer kullanabilirsiniz. 

     1. Web Browser ile Work Item Oluşturma 

     Team Project veya Team Home sayfasından her hangi bir tipte Work Item oluşturabilirsiniz. Bunun için ilk yazılarımda bahsettiğim TFS yüklerken oluşturulan bağlantıyı açıyoruz. Hatırlamıyorsanız, Visual Studio'da Team Explorer penceresinden Web Portal linkine tıklayarak ulaşabilirsiniz. Açılan sayfada şekil 1'de görüldüğü gibi yazımın başında bahsettiğim Work Item tipleri listelenmektedir. Buradan istenilen tip seçilerek oluşturulur. 

Şekil 1: Web ile Work Item 

      Ben önceki yazılarımda Team Project'imi oluştururken şablon olarak CMMI şablonunu kullandığım için Gereksinim (Requirement), Değişiklik İsteği (Change Request), Hata (Bug), Görev (Task) gibi iş öğesi tipleri ile karşılaşıyorum. Bunlardan biri olan  Task (Görev) tipini seçerek ilerliyorum ve şekil 2'de görülen form karşıma çıkıyor. 

Şekil 2: Task Oluşturma 

     Burada oluşturacağınız göreve bir başlık girmek zorundasınız, ben başlık olarak New Task yazdım. "Status" kısmında bu görevi kim için açtığınızı, işin durumunu ve nedenini belirtebiliyosunuz. "State" kısmı her tip iş öğesi için iş akışına göre farklı seçenekler sunmaktadır. "Planning" kısmında Priority olarak önem derecesini belirleyebilirsiniz. Blocked kısmında evet, hayır seçeneklerinde eğer kimsenin work item üzerinde izninin olmaması isteniyorsa evet seçeneği seçilebilir. Alttaki Other sekmesinden işin başlangıç ve bitiş tarihlerini ayarlabilirsiniz. Attachments ve sekmelesinden iş ile ilgili ek ve bağlantı ekleyebilirsiniz. All Links sekmesinden ilişkili başka bir iş öğesi, değişiklik kümesi, bug vs gibi şeyleri iş öğesine bağlayabilirsiniz. 

     Listeleri kategorize etmek ve filtrelemek için etiket ekleyebilirsiniz. "Etiketler" kısmında "Ekle..." diyerek bir ya da daha fazla etiket ekleyebilirsiniz. Bu etiketler, bir iş öğesine atanmış olarak etiket çubuğunda listelenir. Bu atanmayı kaldırmak için etiketin yanındaki "x" ya tıklamanız yeterlidir. TFS'den bir etiketi kendiniz silemezsiniz, TFS kullnılmayan atanmamış olan etiketleri 3 gün sonra otomatik olarak siler.
     Her alan ve görev tipi hakkında daha ayrıntılı bilgi almak için team project'i oluştururken kullanılan şablonları inceleyebilirsiniz: Scrum iş öğesi türleri (ürün biriktirme listesi öğesi ve diğerleri), Agile iş öğesi türleri (kullanıcı hikayesi ve diğerleri) ve CMMI İş öğesi türleri (gereksinimve diğerleri). Yazımın başında da bahsettiğim gibi her şablon için farklı iş öğesi tipleri bulunmaktadır. [3]

     Alanlar istenilen gibi doldurulduktan sonra kaydedip kapatıyoruz ve New Task adında yeni bir Work Item oluşturmuş oluyoruz. 

     2. Team Explorer ile Work Item Oluşturma 

     Visual Studio eklentisi olan Team Explorer ile iş öğesi oluşturmak için Team Explorer ana menüsünden "Work Items" seçilir. Şekil 3'te görülüğü gibi açılan pencereden "New Work Item" linki seçilip iş öğesi tipi seçilir. Bundan sonraki adımlar web browser üzerinde yapılan işlemlerin aynısı olmaktadır.

Şekil 3: Work Item Oluşturma

     3. Work Item Silme

     Bir iş öğesini silmek için komut ekranını kullanabiliriz çünkü Team Explorer ya da Web Access ile silmek mümkün değil. Bunun için komut ekranına aşağıdaki komutu girerek çalıştırıyoruz.

      C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDEwitadmin destroywi /collection:http://koleksiyon url adresini/ /id:17,16,15 [2]

     Burada koyu belirttiğim id kısmı silmek istediğiniz iş öğelerinin id lerini göstermektedir. Bu id lere ulaşmak için  Web Access ya da Team Explorer ana menüsündeki "My Work" kısmından bakabilirsiniz.
     Ekranda, İş öğelerini silmek istediğinizi doğrulamanız için (y: Evet /n: Hayır) cevabını girmeniz beklenir. Silme işlemini gerçekleştirmek için y yazarak enter tuşuna basıp tamamlayabilirsiniz. Artık My Work sayfasında o iş öğelerinin bulunmadığını görebilirsiniz.[2]

     4. İş Öğesini Güncelleme
     Her takım üyesi iş öğesinin durumunu güncelleyebilir ya da iş öğesi formundaki geçmiş hariç her hangi bir yazılabilir alanın değerini değiştirebilir. İş öğesi üzerinde yapılan değişiklikler geçmiş (history) alanında saklanır. Ayrıca bir iş öğesinin ID'sini değiştiremezsiniz.
     Bir iş öğesini güncellemek için Web Access ile göstermek gerekirse şekil 4'te görüldüğü gibi İŞ sekmesi altındaki Sorgular sekmesinde "Bana Atanmış" (My Work) alanındaki güncellenilmek istenen iş öğesine çift tıklayarak iş öğesi formu güncellemek için açılıyor. [3]

Şekil 4: Bana Atanmış İş Öğeleri

      Bir iş öğesinin durumunu (state) değiştirmek için listede olanlardan biri seçilir. Örneğin yukarıda Task tipi bir iş öğesi açtığımızda durumu için sadece proposed seçeneği ve sebep (reason) olarak sadece new seçeneklerini sunmaktaydı. Ama güncellemek için iş formunu açtığımızda Active, Closed, Proposed seçenekleri bulunmaktadır. Bu alan güncellendiği zaman bir sebep girilmesi zorunludur. Seçilen duruma göre sebep seçenekleri değişiklik göstermektedir bunlardan uygun olan seçilir. Bir iş öğesinin saatini (Hours) güncellemek için Remaining Work kısmına ekibin işi tamamlamak için kalan zamanı sayısal olarak girilir. Bunlar gibi form üzerinde bir çok yerde oluşturduktan sonra değişiklik yapabilirsiniz. [3]

    5. İş Öğesinin Değişiklik Geçmişini Görüntüleme
    İş öğesi formundaki "History" sekmesinden iş öğesi üzerinde yapılan her değişikliği görüntüleyebilirsiniz. Şekil 5'te History sekmesi görülmektedir.

Şekil 5: History Sekmesi

     Yalnızca Tartışma (Discussion Only) sekmesinde eklenen açıklamaları, yorumları görebilirsiniz. Tüm değişiklikler sekmesindeki bir değişikliğin üzerine tıklayarak hangi alanda kim tarafından ne değişiklik yapılmış ayrıntılı görüntüleyebilirsiniz.[3]


     Bu haftalık yazımı burada bitiriyorum. Haftaya İş Öğesi Sorguları üzerinden devam edeceğim. Okuduğunuz için teşekkürler...  

Team Foundation Server'da Conflict (Çakışma) Türleri ve Çözümleri

     Team Foundation sürüm denetimi kullanmanın bir avantajı, bir çok kişinin aynı anda çalışabildiği dosyaları yönetebilmektir. Bir eksisi ise bazen get, check-in, unshelve, merge ya da geri alma işlemlerinden önce çakışmaları çözmeniz gerekmektedir. Conflict ( Çakışma) ile karşılaşmak can sıkıcı olabilir, ancak sistem, çakışmaları anlamanıza ve çözümlemenize yardımcı olacak bilgi ve araçları sağlar.[1]

     Peki nedir bu çakışma, neden oluşur, genel olarak açıklamak gerekirse;
     Eğer check-out yapmadan önce get latest ile son sürümü aldıysanız, dosyaları check-in edeceğiniz zaman server sizin değişikliklerinizin eski versiyon üzerinde kaldığını bilir ve sizin müdahele ettiğiniz satırlarda yeni versiyonda değişiklik varsa sizi çakışma olduğu doğrultusunda uyarır ve check-in yapmadan önce bunları düzeltmeniz gerektiğini belirtir. Şekil 1'de görsel olarak özetlemek gerekirse;

Şekil 1: Conflict[2]

     Çakışma aşağıdaki operasyonlar sırasında oluşabilir:

• Branchlar arasındaki değişikleri merge ederken
• Kendi çalışma alanınıza (workspace) dosyaları alırken (get işlemleri)
• Dosyanın yeni sürümünü check-in yaparken [3]

     1. Çakışma Türleri     1.1 - Versiyon Çakışması
     Versiyon çakışmaları chech-in, get ya da merge işlemleri sırasında oluşabilir. Her durum çakışma için farklı sonuçlar oluşturmaktadır.

• Check-in: İki kullanıcı dosyanın son sürümlerini check-out eder. İlk kullanıcı değişikliklerini check-in eder; bu durum dosyanın yeni sürümünü yaratmış olur. İkinci kullanıcı check-in yapmaya çalıştığında versiyon çakışması olur çünkü ikinci kullanıcının değişiklikleri dosyanın son sürümü üzerinde yapılmamıştır.
• Get: İki kullanıcı dosyanın son sürümlerini check-out eder. İlk kullanıcı değişikliklerini check-in eder; bu durum dosyanın yeni sürümünü yaratmış olur. İkinci kullanıcı get latest işlemi yaptığı zaman versiyon çakışmasına neden olur çünkü get latest işlemi workspacedeki check-out edilmiş dosyayı update etmeye çalışır.
• Merge: Branch edilmiş dosya iki branchta da değiştirilirse oluşur. Yani kullanıcı değişiklikleri bir branchtan diğerine merge etmeye çalıştığında versiyon conflict oluşur çünkü dosya iki branch üzerinde de değiştirilmiştir.

     Tablo 1'de versiyon çakışması için çözüm olarak hangi durumlarda neler yapılacağı kısaca gösterilmektedir.

Tablo 1: Versiyon Çakışması Çözüm Seçenekleri [3]

     1.2 -  Dosya Adı Çakışması
     Dosya adı çakışmaları chech-in, get ya da merge işlemleri sırasında oluşabilir.  Bu 3 durumda da, Source Control Server'da iki ya da daha fazla öğe aynı yolu işgal ederse conflict ile sonuçlanır.

• Check-in: İki kullanıcı aynı uygulamaya dosya ekler. Tesadüfen iki kullanıcı da yeni dosyaları için aynı ismi seçerler. Bir kullanıcı kendi dosyasını check-in eder. Bu durumda diğer kullanıcı check-in yapmaya çalışırsa dosya adı çakışması meydana gelir.
• Get: İki kullanıcı aynı uygulamaya aynı isimli dosya eklerler. Bir kullanıcı kendi dosyasını check-in eder. Diğer kullanıcı get latest işlemini yapmaya çalıştığında dosya adı çakışması meydana gelir çünkü ilk kullanıcının eklediği dosya ikinci kullanıcının eklediği yere alınamaz.
• Merge: Uygulama branch edilmiş ve iki branchta da çalışılıyorsa bu iki brancha aynı isimli dosya eklendiğinde kullanıcı iki branchı merge etmek istediğinde dosya adı çakışması oluşur. Çünkü kaynak brancha eklenen dosya hedef branchta zaten olduğu için branch edilemez.

     Dosya adı çakışmaları server path namespace'e öğe ekleme ya da taşıma işlemleri sırasında da oluşabilir. Bunlar add, rename, branch undelete, merge işlemleri olabilir.
     

    Tablo 2'de dosya adı çakışması için çözüm olarak hangi durumlarda neler yapılacağı kısaca gösterilmektedir.

Tablo 2: Dosya Adı Çakışması Çözüm Seçenekleri [3]

     1.3 - Yerel Dosya Üzerine Yazma Çakışması
     Sadece get işlemleri sırasında oluşur. Bu çakışma get işlemi kendi çalışma alanınızdaki yazılabilir dosyanın üzerine yazmaya çalıştığında oluşur. Yerel dosya üzerine yazma çakışmaları dosyanın üzerine yazma ya da dosyayı check-out etme ve değişiklikleri merge etmeyi içerir.

     2. Çakışmaları Giderme
     Şekil 2'de görüldüğü gibi conflict oluştuğu zaman Team Explorer'da çıkan "Resolve Conflicts" linkine tıklayınca açılan şekil 3'teki pencereyi çakışmaları gidermek için kullanabilirsiniz.

Şekil 2: Resolve Conflicts

   

Şekil 3: Resolve Conflicts Penceresi

     Resolve Conflict penceresi default olarak sadece en son denediğiniz işlemin neden olduğu çakışmaları gösterir. Şekil 3'te sol üstte görüldüğü gibi "Path Filter applied" yazısı bunu belirtmektedir. Tüm çakışmaları göstermek için "Get All Conflicts" yazısına tıklayarak "Path Filter applied" yazısı yerinde çalışma alanımızdaki tüm çakışmaların sayısını ve neler olduklarını görebiliriz.

     Çalışma alanınızdaki dosyalarda değişiklik yaptığınızdan bu yana uzun zaman geçtiyse, yeni çakışmalar oluşmuş olabilir. Bu yüzden işlem yapmadan önce "Refresh" butonu ile Resolve Conflict penceresini yenilemeniz daha iyi olacaktır.

     Her çakışma bilgileri ve bazen çözümlemenize yardımcı olabilecek bağlantıları içerir. Conflict hakkında daha fazla bilgi almak için üzerine sağ tıkladığınızda çıkan menüde History, Compare ve Annonate seçenekleri mevcut.

     History, dosyanın geçmişini görüntüler. Çakışmaya neden olan işlem Merge ya da Rollback (Geri Alma) ise, Source History (Kaynak Geçmiş) ya da Target History'yi (Hedef Geçmiş) seçip çakışmaya neden olan dosyanın geçmişine bakabilirsiniz.

     Annonate, dosyanın en son sürümünde yapılan tüm değişiklikler hakkında, her değişikliği kimin ve ne zaman yaptığı gibi, ayrıntıları görüntülemek için kullanabilirsiniz.

     Compare, karşılaştırma penceresini açarak kodunuzdaki farklılıkları listeler ve buradan rahatlıkla çakışmaya neden olan satırları görebilirsiniz.

     2.1 - Çakışmalar için AutoResolve All

     Söz konusu seçeneği kapatmadığınız sürece varsayılan olarak sistem otomatik olarak çakışmalara "AutoResolve All" işlemini yapmaya çalışır. Resolve Conflicts penceresinde, AutoResolve All'u el ile seçtikten sonra iki seçeneğiniz oluyor:

     All Conflict Types; Sistemin çakışmaları tüm sezgisel yöntemlerini kullanarak otomatik olarak çözümlemeyi denemesini istiyorsanız bu seçeneği kullanabilirsiniz.

     Specific Conflict Types; Sistemin çakışmaları çözümlemeyi denemesini, ama bazı sezgisel yöntemleri dışlamayı istiyorsanız  bu seçeneği kullanabilirsiniz. Bunu seçtikten sonra şekil 4'te görülen Choose Conflicts To Resolve (Çözümlenecek Çakışmaları Seç) iletişim kutusu belirir. Etkinleştirmek ya da devre dışı bırakmak istediğiniz seçenekleri işaretleyip ya da temizleyip  AutoResolve'e (Otomatik Çöz) tıklayarak tamamlayabilirsiniz.

 

Şekil 4: Çözümlenecek Çakışmaları Seç

     Sistem Pending Changes (Bekleyen Değişiklikler) penceresinde görüntülenen çakışmaları otomatik olarak çözümleme girişiminde bulunur.Ancak sistemin otomatik olarak çözümleyemediği çakışmalar pencerede kalmaya devam eder. Bu çakışmaları manuel olarak çözümlemeniz gerekmektedir. 

     Eğer bu seçeneğin default olarak kalmasını istemiyorsanız, menü çubuğundan Araçlar, Seçenekler'i seçin ve ardından Seçenekler iletişim kutusunda Kaynağı Denetle, Visual Studio Team Foundation Server'a gidip "Attempt to automatically resolve conflicts when they are generated" (Oluştukları anda çakışmaları otomatik olarak çözümlemeyi dene) onay kutusunun işaretini kaldırın.

     2.2 - Otomatik Seçenekleri Anlama

     Şekil 4'teki penceredeki seçenekleri anlamak için tablo 3'ü inceleyebilirsiniz.

Tablo 3: Otomatik Seçenekleri Anlama [3]

     2.3 - AutoMerge

     Yukarıdaki otomatik seçenekleri anlama bölümünde açıklanan tüm AutoMerge seçeneklerini kullanarak seçilen çakışmaları çözümlemeyi denemek istiyorsanız bunu seçebilirsiniz. 

     CONTROL ve SHIFT tuşlarını basılı tutup ve birden çok çakışma seçebilirsiniz.

     AutoMerge devre dışıysa, bu çakışma manuel olarak çözümlenmelidir.

     2.4 - Çakışmayı El ile (Manuel) Çözümleme

     Sistem otomatik olarak bir çakışmayı çözümleyemezse veya neyin değiştiğini anladığınızdan emin olmak istiyorsanız, çakışmayı el ile çözümlemeniz gerekir. Her bir çakışma içinde, sistem çakışmaları çözümlemek için gerçekleştirebileceğiniz eylemleri görüntüler. Görüntülenen eylemler çakışma türüne ve çakışmaya neden olan işleme bağlıdır.

     Merge aracı ile değişiklikleri birleştirme;

     Çakışan içerik değişiklikleri nedeniyle bir çakışma oluştuğunda Resolve Conflict penceresindeki "Merge Changes in Merge Tool" seçeneğini seçebilirsiniz. Daha sonra şekil 5'te görüldüğü gibi farklılıkları gösteren merge penceresi açılmaktadır.

Şekil 5: Merge Penceresi

     Çakışmayı çözmek için yapmanız gereken alttaki Result bölmesinde gösterilmiştir. Bu pencerede, aşağıdakileri yapabilirsiniz:

• Pencere yerleşimini seçebilirsiniz: Dikey Görünüm, Yatay Görünüm, Karışık Görünüm.
• Farklar ve çakışmalar arasında gezinebilirsiniz.
• Resultta içerilecek dosyayı sol ve sağ sürümlerinden (source yada target) yanlarındaki check box ile seçebilirsiniz. 
• Reasult bölmesindeki dosyaya ek içerik yazabilirsiniz.
• Üst menüden dosyanın geçmişini görüntüleyebilirsiniz.
• Dosyanın çeşitli sürümlerini karşılaştırabilirsiniz.
• Kimin neyi değiştirdiğini görmek için dosyaya açıklama ekleyebilirsiniz.

     Result bölmesinin içeriğinden memnun olduğunuzda, sol üstteki "Accept Merge" (Birleştirmeyi Kabul Et) seçerek işlemi tamamlayabilirsiniz. 

     Böylece çakışma olması halinde düzeltme yollarını tamamlamış oluyoruz. Bu haftalık yazımı burada bitiriyorum. Haftaya Work Item konusu üzerinden devam edeceğim.  

 

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

Team Foundation Server ile Merge Yapımı ve Kod Karşılaştırma

     1. Merge
     Team Foundation Server (TFS)'de oluşturduğumuz branchlar arasında kodları çift yönlü aktarabilmemize olanak sağlayan merge (birleştirme) işlemi bulunmaktadır.[1]  Merge, kaynak branchta yapılan isim değişikliklerini alma, dosya düzenleme, ekleme, silme veya yapılan değişiklikleri geri alma gibi işlemleri hedeflenen branch ile birleştirir. Merge işlemi, özel sürümleri veya tüm değişiklikleri birleştirme gibi seçenekler sunmaktadır. Klasörler arası dallandırma ve birleştirme yapabilseniz de, takımınız için en iyi deneyim sadece dallar arası dallandırma ve birleştirme yapmaktır.

     "Team Foundation Server ile Folder, Branch ve Label Oluşturma" adlı yazımda açıkladığım çeşitli sebeplerden dolayı, çoğu yazılım geliştirme takımı birçok brancha ayrılmış kod temelinde çalışır. Branch kullanılıyorsa, takım en sonunda projenin belirli aşamalarında farklı branchlarda tamamlanan işleri tümleştirmelidir. [2] Örneğin, Release 1 kodunuz teste taşındığında, kodunuzu Release 2 olarak branch edip yazılım geliştiricilerin bu Release üzerinde çalışmasına izin verirsiniz. Release 1 test edilirken hatalar bulunup Release 1 branchında düzeltirsiniz ve bu değişiklikleri yeni sürüm (Release 2) ile birleştirmeniz (merge) gerekecektir.

     Merge işleminin ne olduğunu anladıysak, şimdi sıra nasıl yapılacağının öğrenilmesinde. Branchlar arasında kod merge etmeyi adım adım göstereceğim . En son yazımda Main Branch'ı içerisine projemizi atmıştık. Bunu Dev Branch'ı ile merge etmek istersek, Source Control Explorer'da Main Branch'ına sağ tıkladığımızda "Branching and Merging" menüsünden Merge'e tıkladığımızda şekil 1'de görüldüğü gibi "Merge Wizard" ile karşılaşıyoruz.

Şekil 1: Merge Wizard

     Burada, Source branch kısmı yukarıda da bahsettiğim gibi kodları alacağımız kaynak branchımızdır. Hedeflenen branch (Target branch) ise kopyalamak istediğimiz yeri göstermektedir.
"All changes up to a specific version", "Selected changesets" kısmı ise belirli bir sürüme kadar tüm değişiklikleri mi yoksa belirli değişiklikleri mi merge edeceğimizi seçme fırsatı sunmaktadır. Mümkünse, All changes up to a specific version'a tıklayın, böylece gelecek birleştirmelerde çakışma riski azalır. All changes up to a specific version'u seçersek, şekil 2'de görülen kaynak öğelerin sürümlerini seçme ekranı ile karşılaşıyoruz.

Şekil 2: Sürüm Seçimi

     Burada Latest Version, Changeset, Date, Label, Latest Version, Workspace Version seçeneklerini sunmaktadır. Kaynak branchta hangi sürüm merge edilmek isteniyorsa seçildikten sonra ilerliyoruz ve Perform the merge operation (Birleştirme işlemini gerçekleştir) sayfasında , Finish diyerek işlemi sonlandırıyoruz.
     Eğer kod hem kaynak branch hem de hedef branchta değiştirilmiş ise merge ederken conflict (çakışma) düzeltmek zorunda kalırsınız. Bir sonraki yazımda bu konuya ayrıntılı değineceğim.

     2. Kaynak Kod Karşılaştırma
     İki kod veya aynı kodun iki sürümü arasındaki farkı görmek için kod karşılaştırma penceresini kullanabilirsiniz. Kodun sürümlerinden biri çalışma alanınızda kullanıma alındıysa karşılaştırmayı çalıştırırken kodu değiştirebilirsiniz.
   
    Kod karşılaştırma penceresini açmak için ilk olarak Source Control Explorer'da karşılaştırmak istediğimiz kod dosyasının üzerine sağ tıklayarak "Compare" menüsü seçiyoruz ve şekil 3'te görülen pencere ile karşılaşıyoruz.

Şekil 3: Kod Karşılaştırma Penceresi

     Burada Target Path kısmında karşılaştırmak istediğimiz kod dosyasını seçerek alttaki View Options kısmında karşılaştırma penceresinde nelerin görünmesini istediğimizi seçip tamamlıyoruz ve sekil 4'te görülen pencere ile karşılaşıyoruz.

Şekil 4: Dosya Farklılıkları Penceresi

     Burada farklılık bulduğu dosyaları kırmızı ile belirtiyor ve üzerine tıkladığımız zaman şekil 5'te görülen farklılık penceresini açıyor.

Şekil 5: Kod Karşılaştırma

 

     Burada koda yeni eklenen yerler yeşil, silinen yerler ise kırmızı olarak belirtilmektedir.

     3. Değişiklikleri İzleme
     Takım üyeleri branchlar halindeki bir kod temelinde çalışıyorsa, hangi branchların değiştirildiği ve bu değişikliklerin ne zaman birleştirildiği hakkında bilgi bulmakta zorlanabilirler. TFS ile farklı branchlar üzerindeki dosyaların ilişkilerini takip etmek ve herhangi bir branchta yapılan bir değişikliğin Merge işlemleri ile adım adım hangi branchlara aktarıldığını takip etmek mümkündür.[3]  Nerede yapıldığı, nerede birleştirildiği ve bu olayların ne zaman gerçekleştiği gibi bilgileri görüntülemek için Tracking Changeset (Değişiklik Kümesini İzleme) penceresini kullanabilirsiniz. Tracking Changeset penceresi değişiklik kümesiyle birleştirilen branchları gösterir. Örneğin, şekil 6'da Tracking Changeset penceresi değişiklik kümesi 38'in nasıl Dev branchından bir alt branch ile merge edildiğini ve sonrasında temelsiz olarak farklı iki branch ile merge edildiğini gösterir.

   

Şekil 6: Tracking Changeset[4]

     Merge işleminin uygulandığı branchlar değişiklik kümesi numaralarıyla birlikte yeşil renkte gösterilmiştir. Bu branchlardan birine (örneğin, şekil 6'daki Version2) tıklayarak o brancha ulaşmak için değişiklik kümesinin ihtiyaç duyduğu tüm merge işlemlerini vurgulayabilirsiniz. 

     Merge işlemi standart ise gri düz çizgi ile, temelsiz merge ise noktalı çizgi ile gösterilmektedir.

     Branch değişiklikliklerin hepsini değil de bir kısmını aldıysa branch bir desenle doldurulur ve bu branchtaki değişiklik kümesi numaralarının sonuna yıldız eklenir. Örneğin şekil 6'da değişiklik kümesi 38'deki değişikliklerin yalnızca bazılarının, Test Branch'ıyla merge edildiğini gösterir.

     Değişiklik kümesinin merge edilmediği branchlar mavi ile gösterilir.[4]

     Tracking Changeset penceresini açmak için ilk olarak Source Control Explorer'da bir branchın içerdiği branch, klasör ya da dosyaya sağ tıklayarak "View History" menüsü seçiyoruz ve şekil 7'de görülen pencere ile karşılaşıyoruz. 

Şekil 7: History

     Burada hangi değişikliğin kim tarafından ne zaman yapıldığını, commentini gibi ayrıntıları görüntüleyebiliyoruz. Burada istediğimiz değişiklik kümesi üzerine sağ tıklayarak "Tracking Changeset" menüsünü seçiyoruz ve çıkan pencerede "Visualize" diyerek şekil 6'daki gibi görsel olarak ifadesini elde edebiliyoruz. 

    

     Tracking Changeset penceresindeki menüden Timeline Tracking (Zaman Çizelgesi Görünümü)'ne geçerek değişiklik kümesinin bir ya da daha fazla branch ile ne zaman merge edildiği hakkında bilgi alabilirsiniz. Bu görünüm sadece her merge işleminin kaynak ve hedeflerini değil, ayrıca merge işleminin ne zaman olduğunu da gösterir.

Şekil 8: Timeline Tracking[4]

     Şekil 8'deki örnek şekil 6'daki Tracking Changeset penceresinin merge sırasını gösteren bir görünümdür.

    Değişiklik kümesini alan branchlar görünümün en üstünde belirir. Merge edilmeyen branchlar en altta beyaz olarak gösterilmektedir.

     Bu haftalık yazımı burada bitiriyorum. Haftaya merge işlemi sırasında oluşabilen conflict (çakışma) olayına değineceğim. Okuduğunuz için teşekkürler.

Team Foundation Server'da Check-in, Check-out

     Team Foundation Server, projemizi düzen içerisinde, sağlıklı bir ortam sunarak geliştirmemizi sağlar. Program her zaman proje geliştiricilerine en güncel hali sunar ve istediğimiz taktirde önceki sürümlere ulaşabilme imkanı sağlar.[1]

     Bir çok dosyanın bulunduğu proje üzerinde değişiklik yapmak isteyen geliştirici "Check Out" ismi verilen işlemle istediği değişiklikleri yapmak için çalışmak istediği dosya üzerinde bir bakıma çalışma izni alır. Bunu yapmaya başladığı andan itibaren diğer tüm geliştiriciler arkadaşlarının o dosya üzerinde çalıştığını görecektir. Ekip arkadaşları da bu duruma göre kendi yollarını izleyebilirler. Aynı şekilde dosya üzerinde çalışan kişi tüm işlerini bitirdikten sonra "Check İn" işlemi ile dosyayı tekrar server ortamına geri bıraktığını bildirir ve dosyanın son hali ekibe sunulur. Bu aşamadan sonra ekip arkadaşları geliştiricinin yaptığı değişiklikleri gözlemleyebilirler.[1]

     Source Control Explorer'dan server üzerindeki tüm kayıtlı dosyalara ulaşabiliyoruz ve buradan çalışmak istediğimiz tüm dosyaları kendi ortamımıza aktarabiliyoruz. Bunu yapmak için şekil 1'de gösterildiği gibi seçtiğimiz dosyaya sağ tıklayarak "Get Latest Version" dedikten sonra proje dosyalarımızın, kodlarımızın en güncel halini geliştirme ortamımıza yüklemiş oluyoruz.[1] Ayrıca şekil 1'de görüldüğü gibi bazı branchların siyah iken bazılarının gri olmasının sebebi, Get Latest Version ile son sürümünün alınmamış olmasıdır. Bu komut ile sunucu üzerindeki dosyanın son hali geliştirme ortamımıza alınmış olur. Bu işlemden sonra onun da siyah olduğunu görüyoruz bu sayede bu işlemi unutmamak için TFS belirtmiş oluyor.

Şekil 1: Get Latest Version

    1. Versiyon Kontrol Sistemine Dosya veya Proje Ekleme
    Team Project-Source Control Explorer'a eklenen dosyaların bir proje olması yada bir projeye dahil olması gerekmemektedir. Doğrudan bir metin dosyası yada resim dosyası gibi bir dosya da eklenebilmektedir.
    Bir önceki yazımda bahsettiğim gibi uygun branchlar oluşturarak bunların altına proje kodlarımı eklemeyi adım adım göstereceğim. İlk olarak şekil 2'de gösterildiği gibi branch yapımızı oluşturuyoruz.

Şekil 2: Branch Yapısı

    Daha sonra sıra proje eklemeye geliyor. İsterseniz yeni bir proje oluşturarak ya da varolan bir projeyi ekleyerek devam edebilirsiniz. İlk olarak yeni bir proje oluşturarak ilerlemeyi göstermek gerekirse, normal bir şekilde Visual Studio menüsünden yeni bir proje, web sitesi vs istediğimizi seçerek şekil 3'te görüldüğü gibi "Add to Source Control" kısmını seçerek oluşturuyoruz.

Şekil 3: Proje Ekleme

      Proje oluşturduktan sonra şekil 4'te görüldüğü gibi hangi vesiyon kontrol sistemi kullanmak istediğimizi soruyor. Team Foundation Version Control'ü seçerek ilerliyoruz.

Şekil 4: Versiyon Kontrol Sistemi Seçimi

      Daha sonra, şekil 5'te görüldüğü gibi Team Projemiz altında oluşturduğumuz branchlardan birini seçerek ya da yeni bir klasör oluşturarak proje dosyalarımızın nereye ekleneceğini seçiyoruz. Ben Main branchını seçerek tamamlıyorum.

Şekil 5: Solution Ekleme

    Projemizi eklemeyi tamamladıktan sonra Souce Control Explorer'da Main branchı altında proje dosyamızı görebiliriz.

    Bu şekilde yeni bir proje oluşturup eklemeyi tamamlamış oluyoruz. Eğer varolan bir projeyi eklemek istersek şekil 6'da görüldüğü gibi Solution Explorer'da projemize sağ tıklayarak "Source Control" menüsü altından "Add Solution to Source Control" diyerek yine aynı aşamalar ile ekleyebiliriz.

                                                                                                   Şekil 6: Varolan bir Proje Ekleme

     2. Kodu Check-In, Check-Out Yapma

     Projeyi Source Control'a ekledikten sonra dosyalarımızın yanında + işaretleri oluşmaktadır. Bunun nedeni o dosyaların henüz Check-in olmamasıdır. Check-in olarak dosyaları server ortamına bırakırız ve daha sonra Check-out yaparak kullanıma alabiliriz. 

     Şekil 7'de görüldüğü gibi Source Control Explorer'da dosyamıza sağ tıklayarak "Check-In Pending Changes" diyerek sağda açılacak Team Explorer menüsündeki istenirse Commit yazılarak (Her check-in olayında yaptığınız değişiklikle ilgili açıklayıcı bir yorum yazmanız neler yaptığınızı takip etmeniz açısından faydalı olacaktır.) Check-In butonuyla işlemi tamamlıyoruz ve projemiz Team Foundation Server altında tutulmuş oluyor.

 Şekil 7: Check-In

     

     Yazımın başında da değindiğim gibi Team Foundation Server altında tutulan herhangi bir projeyi açıp değişiklik yapmaya çalıştığımızda Visual Studio dosyayı Check-out etmemiz konusunda bizi uyarır. Yani dosyayı değiştirmeden önce kullanıma alınması gerektiğini belirtmektedir. Bunun için projemize sağ tıklayarak "Check-Out for Edit..." diyerek şekil 8'de görülen ekranda hangi dosyaların check-out edileceği liste olarak verilmiş ve seçme şansı tanınmıştır. Bunun yanında dosya check-out edilirken uygulanacak kilit seçeneği de seçenekler olarak listelenmiştir.

     Şekil 8: Check-Out

     

    İlk seçenekte, var olan kilitleri koruyarak diğer kullanıcıların dosyayı check-out etmesini kısıtlayarak aynı anda bir dosyayı sadece bir kullanıcının düzenleyebilmesini sağlamış olur.

    İkinci seçenekte, diğer kullanıcıların dosyayı check-out edebilmesini ancak dosya bizim tarafımızdan checkout edilmiş durumda iken diğer kullancıların check-in yapabilmesini yasaklar.

    Burada ilk seçeneği seçerek check-out işlemini tamamlıyoruz ve şekil 9'da görüldüğü gibi dosyamızın yanında bunu belirten kırmızı tik işaretini görüyoruz.Bu işlemden sonra dosyamız üzerinde değişiklik yapıp tekrar check-in yapabiliriz.

                                 Şekil 9: Check-out

    Bir proje dosyasına "Check-Out" olup yeni bir item eklemek istediğimiz zaman Merge sağlığı açısından eklediğimiz item ile uğraşmaya başlamadan bunu diğer tüm geliştiricilere hemen aksettirmek doğru olacaktır. Bu yüzden hemen "Check-In" olunmalı ve ondan sonra kendimizi tekrar değişiklik yapabiliyor duruma getirmeliyiz. Aksi halde bu durumdan ekibin haberi olmazsa Merge aşamasında TFS'nin halledemeyeceği durumlarla karşılaşabiliriz.[1] Bir sonraki yazımda Merge konusunda ayrıntılı olarak bu duruma değineceğim.

     3. Dosya Geçmişini Görüntüleme

      Geliştiricilerin proje üzerindeki yaptığı değişiklikler tüm ayrıntılarıyla kayıt edilmektedir. Öyle ki geliştiren herkes bir klasöre kim, ne zaman erişmiş, ne kadar süre geçirmiş, neler değiştirmiş, açıklamalarıyla beraber erişme fırsatına sahiptir. TFS ayrıca işin içinden çıkamadığınız durumlarda en son çalışan haline de erişebilme imkanı sunabilmektedir. Bunun yanında uğraşıp bitiremediğiniz projeleri kimse ile paylaşmadan server üzerinde sonradan tekrar erişmek üzere ayrı bir şekilde tutabilirsiniz.[1] Bunun için Source Control Explorer'da istenilen dosyanın üzerine sağ tıklayarak "View History" diyoruz ve şekil 10'da görülen History penceresi açılıyor.

Şekil 10: View History 

      Burada istediğimiz versiyona sağ tıklayarak çıkan menüden istersek o versiyonu çalışma alanımıza alma, karşılaştırma gibi işlemleri yapabiliyoruz.

   
     Bu haftalık yazımı burada bitiriyorum. Haftaya merge ve kod karşılaştırma konularına değineceğim. Okuduğunuz için teşekkürler...