blog'u wordpress'e taşımaya karar verdim.
Yeni ve eski blog yazılarını ...
etoptanci.wordpress.com
...adresinden takip edebilirsiniz.
21 Aralık 2010 Salı
24 Kasım 2010 Çarşamba
TFS Bileşenleri 3/5 - Doküman Yönetimi
TFS ile doküman yönetimi konusunda aslında söylenebilecek çok fazla şey yok. Daha önceden de söylediğimiz gibi TFS bir doküman yönetim aracı DEĞİLDİR.
TFS de "Work Item"ların yanına her türden dosyayı eklemek mümkündür. Bu şekilde WI ile ilgili bir dosyayı direk olarak yanyana koymuş olursunuz. Ama yapabilecekleriniz bununla sınırlıdır. WI'ların yanına iliştirilmiş dosyaların adında ya da içinde arama yapmak, versiyonlamak, dosyaları topluca bir yere kopyalamak hatta listelemek bile mümkün değildir.
TFS doküman yönetimi konusunda daha çok amcaoğlu Sharepoint'e güvenir.
TFS sistemi kurulum sırasında sizi en azından bir Sharepoint Services sistemi kurmaya yönlendirir, Eğer kurumunuzun hazır bir SP sistemi varsa TFS'i bu sistemi kullanacak şekilde ayarlayabilir ve SP'in bu konudaki olanaklarından faydalanabilirsiniz.
Sharepoint zaten tam ve kapsamlı bir doküman yönetim aracı olduğu için burada anlatmaya gerek yok.
Yine TFS açısından bakıldığında tavsiye edilen kullanım; dokümanları WI ların yanına eklemek yerine sistemli bir şekilde SP üzerinde saklamak, WI ile ilişkilendirmek gerektiğinde ise WI ın yanına dosyanın SP linkini eklemektir. Bu şekilde hem WI ile dosya(lar)ı eşlemiş olursunuz, hem de dosyaların adam akıllı yönetebilirsiniz.
Gelelim işin eleştirel tarafına...
CMMI vs gibi süreç sistemleri ile uğraşanlar bilirler projeler sırasında belirli noktalarda dayanak (Baseline) almak icap eder. Bu "dayanak" dediğin şey aslında tüm iş ürünlerinin projenin belirli bir anındaki fotoğrafıdır. Kendi içinde tutarlı bir iş ürünleri kümesidir.
Neye yarar? Projenin belirli bir andaki durumuına dönüp bakmaya yarar. Yani mesela, 2nci faz tamamlandığı zaman alınan dayanağa bakarak gereksinimlerin o andaki durumu neymiş, buna dayanarak nasıl bir çözüm tasarlanmış, ne kadarı gerçeklenmiş ne kadarı test edilmiş vs gibi şeyler görülebilir. Böyle anlatınca çok havalı durmuyor ama aslında oldukça faydalı birşeydir. Neyse...
TFS'in kaynak kod kontrol sistemindeki Label mekanizması bu iş için biçilmiş kaftandır. Kaynak kod kontrolü altındaki dosyaların belirli bir andaki belirli bir versiyon kümesine bir isim verilir ve daha sonra dosyalar bu isim ile çağırılabilir. Gel gelelim Label mekanizması sadece kaynak kod kontrolü altındaki dosyaları kapsar, SP üzerindekileri kapsamaz. Dolayısı ile SP üzerindeki dosyalar Label'lara dahil değildir. Halbuki dayanak alırken tüm iş ürünlerini kapsamak gerekir.
Cingözlük yapıp tüm dosyaları SP de saklamak yerine kaynak kod kontrolü altına almak bir seçenek olabilir ama pek iyi bir fikir değildir. Neticede kaynak kod kontrolü başka birşey, doküman yönetimi başka birşey. SP'in yerini tutmaz.
Uzun lafın kısası kaynak kod kontrol sistemi ile "work item" sistemi arasında çok güçlü bir versiyonlama ve izlenebilirlik mekanizması mevcuttur ancak iş ürünlerinin yine ciddi bir kısmının saklandığı doküman yönetimi ile bu şekilde bir ilişkilendirme yoktur. SP üzerinde saklanan dokümanların kendi içerisinde bir versiyonlaması olmasına rağmen kod dosyaları ya da work item'lar ile versiyona ya da zamana dayalı bir ilişki kurulamaz ve bence bu bir eksiktir. Aynen kod dosyalarında olduğu gibi "work item"'ların ve SP üzerindeki dokümanların da belirli bir zamandaki hallerine ilişkilendirilmiş olarak ulaşabilmek son derece faydalı olabilirdi.
Yine de ezmeyelim, SP zaten kendi başına son derece başarılı bir doküman yönetim aracıdır TFS ile sadece linkler üzerinden kurulacak bir izlenebilirlik ile de çok şey başarılabilir.
TFS de "Work Item"ların yanına her türden dosyayı eklemek mümkündür. Bu şekilde WI ile ilgili bir dosyayı direk olarak yanyana koymuş olursunuz. Ama yapabilecekleriniz bununla sınırlıdır. WI'ların yanına iliştirilmiş dosyaların adında ya da içinde arama yapmak, versiyonlamak, dosyaları topluca bir yere kopyalamak hatta listelemek bile mümkün değildir.
TFS doküman yönetimi konusunda daha çok amcaoğlu Sharepoint'e güvenir.
TFS sistemi kurulum sırasında sizi en azından bir Sharepoint Services sistemi kurmaya yönlendirir, Eğer kurumunuzun hazır bir SP sistemi varsa TFS'i bu sistemi kullanacak şekilde ayarlayabilir ve SP'in bu konudaki olanaklarından faydalanabilirsiniz.
Sharepoint zaten tam ve kapsamlı bir doküman yönetim aracı olduğu için burada anlatmaya gerek yok.
Yine TFS açısından bakıldığında tavsiye edilen kullanım; dokümanları WI ların yanına eklemek yerine sistemli bir şekilde SP üzerinde saklamak, WI ile ilişkilendirmek gerektiğinde ise WI ın yanına dosyanın SP linkini eklemektir. Bu şekilde hem WI ile dosya(lar)ı eşlemiş olursunuz, hem de dosyaların adam akıllı yönetebilirsiniz.
Gelelim işin eleştirel tarafına...
CMMI vs gibi süreç sistemleri ile uğraşanlar bilirler projeler sırasında belirli noktalarda dayanak (Baseline) almak icap eder. Bu "dayanak" dediğin şey aslında tüm iş ürünlerinin projenin belirli bir anındaki fotoğrafıdır. Kendi içinde tutarlı bir iş ürünleri kümesidir.
Neye yarar? Projenin belirli bir andaki durumuına dönüp bakmaya yarar. Yani mesela, 2nci faz tamamlandığı zaman alınan dayanağa bakarak gereksinimlerin o andaki durumu neymiş, buna dayanarak nasıl bir çözüm tasarlanmış, ne kadarı gerçeklenmiş ne kadarı test edilmiş vs gibi şeyler görülebilir. Böyle anlatınca çok havalı durmuyor ama aslında oldukça faydalı birşeydir. Neyse...
TFS'in kaynak kod kontrol sistemindeki Label mekanizması bu iş için biçilmiş kaftandır. Kaynak kod kontrolü altındaki dosyaların belirli bir andaki belirli bir versiyon kümesine bir isim verilir ve daha sonra dosyalar bu isim ile çağırılabilir. Gel gelelim Label mekanizması sadece kaynak kod kontrolü altındaki dosyaları kapsar, SP üzerindekileri kapsamaz. Dolayısı ile SP üzerindeki dosyalar Label'lara dahil değildir. Halbuki dayanak alırken tüm iş ürünlerini kapsamak gerekir.
Cingözlük yapıp tüm dosyaları SP de saklamak yerine kaynak kod kontrolü altına almak bir seçenek olabilir ama pek iyi bir fikir değildir. Neticede kaynak kod kontrolü başka birşey, doküman yönetimi başka birşey. SP'in yerini tutmaz.
Uzun lafın kısası kaynak kod kontrol sistemi ile "work item" sistemi arasında çok güçlü bir versiyonlama ve izlenebilirlik mekanizması mevcuttur ancak iş ürünlerinin yine ciddi bir kısmının saklandığı doküman yönetimi ile bu şekilde bir ilişkilendirme yoktur. SP üzerinde saklanan dokümanların kendi içerisinde bir versiyonlaması olmasına rağmen kod dosyaları ya da work item'lar ile versiyona ya da zamana dayalı bir ilişki kurulamaz ve bence bu bir eksiktir. Aynen kod dosyalarında olduğu gibi "work item"'ların ve SP üzerindeki dokümanların da belirli bir zamandaki hallerine ilişkilendirilmiş olarak ulaşabilmek son derece faydalı olabilirdi.
Yine de ezmeyelim, SP zaten kendi başına son derece başarılı bir doküman yönetim aracıdır TFS ile sadece linkler üzerinden kurulacak bir izlenebilirlik ile de çok şey başarılabilir.
Makine ya da kullanıcı değiştirme
TFS kişilerin kaynak kod kontrolü altındaki dosyalarını; kişi adı, bilgisayar adı ve "workspace" adı üçlüsüyle takip eder. Bilgisayarınızın değişmesi ya da formatlanması muhtemelen bilgisayar adının da değişmesiyle sonuçlanacaktır ve bilgisayarın adı değiştiği zaman bütün dosya ve klasör eşlemelerini kaybettiniz demektir.
Bilgisayar değiştirirken tavsiye edilecek yöntem tüm "workspace" lerdeki dosyaları "Shelve"lere kaldırmaktır. Bu şekilde garantili bir şekilde yeni sisteme taşınabilirsiniz. Dosyalarınız sunucuda yedeklenmiş olur.
Fakat formatın ardından dosyalarınızın bulunduğu klasörlerin yolu değişmediyse ya da dosyalarınızı yeni bilgisayarınıza aynı dosya yolları ile aktardıysanız alternatif ve kolay bir yöntem daha var.
Şanslıyız ki TFS bilgisayar ve "workspace" isimlerini sadece metin olarak takip ediyor ve Team Explorer'i açtığınız zaman sizin kaynak kod kontrol sistemindeki tüm bilgilerinizi TFS sunucusundan indiriyor. Dosyalar sizin bilgisayarınızda olmasına rağmen bilgisayarda kaynak kod sisteminin eşlemeleri ile alakalı hiçbir bilgi tutulmuyor.
Yani, bilgisayarınızda kaç tane "workspace" var. Bunların içinde kaç tane klasör eşlenmiş durumda ve içlerinde hangi dosyalar sizin üzerinize "check-out" edilmiş durumda bilgisi tamamen sunucuda saklanıyor. Dolayısı ile yeni bilgisayara geçildiğinde bu bilgiler kaybedilmemiş oluyor. Sadece TFS'in hatırladığı bilgisayar ismini değiştirmek gerekiyor.
Bunun için kullanılabilecek ...
tf.exe /workspaces /updateComputerName:[eskiBilgisayarAdi] /collection:[TFSProjectCollection]
...şeklinde bir komut var. Bu komutu kullandığınızda size ait olan ve [eskiBilgisayarAdi] üzerinde kayıtlı olan tüm "workspace" ler yeni bilgisayara aktarılıyor. Yeni bilgisayar da o anda kullandığınız bilgisayar oluyor.
Bu komut sayesinde hiçbir detayla uğraşmadan tek bir komutla yeni sisteminize taşınabiliyorsunuz.
Benzer şekilde olur da kullanıcı adını değişirse ya da başka bir kullanıcının "workspace" lerini devralmak gerekirse diye de bir komut var:
tf.exe /workspaces /updateUserName:[eskiKullaniciAdi] /collection:[TFSProjectCollection]
Bu komutla da [eskiKullaniciAdi] adına kayıtlı tüm "workspace" leri yeni bir kullanıcıya aktarabiliyorsunuz, ki bu da komutu çalıştıran kullanıcı oluyor.
e-mre
Bilgisayar değiştirirken tavsiye edilecek yöntem tüm "workspace" lerdeki dosyaları "Shelve"lere kaldırmaktır. Bu şekilde garantili bir şekilde yeni sisteme taşınabilirsiniz. Dosyalarınız sunucuda yedeklenmiş olur.
Fakat formatın ardından dosyalarınızın bulunduğu klasörlerin yolu değişmediyse ya da dosyalarınızı yeni bilgisayarınıza aynı dosya yolları ile aktardıysanız alternatif ve kolay bir yöntem daha var.
Şanslıyız ki TFS bilgisayar ve "workspace" isimlerini sadece metin olarak takip ediyor ve Team Explorer'i açtığınız zaman sizin kaynak kod kontrol sistemindeki tüm bilgilerinizi TFS sunucusundan indiriyor. Dosyalar sizin bilgisayarınızda olmasına rağmen bilgisayarda kaynak kod sisteminin eşlemeleri ile alakalı hiçbir bilgi tutulmuyor.
Yani, bilgisayarınızda kaç tane "workspace" var. Bunların içinde kaç tane klasör eşlenmiş durumda ve içlerinde hangi dosyalar sizin üzerinize "check-out" edilmiş durumda bilgisi tamamen sunucuda saklanıyor. Dolayısı ile yeni bilgisayara geçildiğinde bu bilgiler kaybedilmemiş oluyor. Sadece TFS'in hatırladığı bilgisayar ismini değiştirmek gerekiyor.
Bunun için kullanılabilecek ...
tf.exe /workspaces /updateComputerName:[eskiBilgisayarAdi] /collection:[TFSProjectCollection]
...şeklinde bir komut var. Bu komutu kullandığınızda size ait olan ve [eskiBilgisayarAdi] üzerinde kayıtlı olan tüm "workspace" ler yeni bilgisayara aktarılıyor. Yeni bilgisayar da o anda kullandığınız bilgisayar oluyor.
Bu komut sayesinde hiçbir detayla uğraşmadan tek bir komutla yeni sisteminize taşınabiliyorsunuz.
Benzer şekilde olur da kullanıcı adını değişirse ya da başka bir kullanıcının "workspace" lerini devralmak gerekirse diye de bir komut var:
tf.exe /workspaces /updateUserName:[eskiKullaniciAdi] /collection:[TFSProjectCollection]
Bu komutla da [eskiKullaniciAdi] adına kayıtlı tüm "workspace" leri yeni bir kullanıcıya aktarabiliyorsunuz, ki bu da komutu çalıştıran kullanıcı oluyor.
e-mre
24 Eylül 2010 Cuma
TFS Bileşenleri 2/5 - İş Takibi - Work Item Tracking
İş Takibi diye çevirebileceğimiz Work Item Tracking (WIT) mekanizması temelde bir elektronik form uygulamasıdır. Ancak özelleştirilebilmesi ve sistemin kalanı ile olan entegrasyonu büyük işler başarmasını sağlar.
Konuya dalmadan önce söyleyelim, TFS üzerindeki en büyük yapı bir Takım Projesi (Team Project)'dir. Bir Takım Projesinin kaynak kod kontrol sisteminde kendine ait bir alanı, WIT sisteminde kendine ait form tipleri, sharepoint üzerinde kendi proje sitesi ve kendi rapor tipleri vardır. Tüm bunlar Süreç Şablonu (Process Template) adı verilen bir şablon temel alınarak hazırlanır ama bu da ileride detaylarına gireceğimiz bir başlık.
Ne diyorduk? ... hah... work item...
Dediğim gibi her bir projenin kendi ait form tipleri vardır ve Work Item (WI) bunlara verilen genel isimdir. WI dediğimiz; metin alanlardan, çoktan seçmeli listelerden, sekmelerden vs oluşan elektronik bir formdur. Kullandığınız süreç şablonuna 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 WI tipleri ile karşılaşırsınız. Her birinin kendilerine özgü alanları ve ortak alanları vardır. Kabaca şöyle birşeye benzer...
TFS Power Tools paketini indirirseniz mevcut form tipleri üzerinde değişiklik yapabileceğiniz bir editöre kavuşursunuz. Hatta kendi WI tiplerinizi tanımlayabilirsiniz.
WI'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.
WI'lar kişilerin üzerine atanır. Elden ele gezebilir. TFS üzerine WI atılan kişiye otomatik e-posta gönderir. Kendinize ya da bir başkasına atanmış olan WI'ları listeleyebilirsiniz. Kişilerin üzerindeki işleri takip edebilirsiniz.
Her bir WI'ı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 WI'ı 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 WI 'lar ilişkiler konusunda da yeteneklidir. Bir WI'ın ekine herhangi bir tipte bir dosya iliştirmek mümkündür, Kaynak kod kontrol sisteminden bir changeset ile ilişkilendirmek ya da diğer bir WI ile ilişkilendirmek mümkündür. Hele TFS 2010 ile çalışma şansına erişen mutlu kitleden bir bireyseniz WI lar arasındaki ilişkilere tip bile tanımlayabilir durumdasınız demektir ama bu ağız sulandıran detaya şimdi girmeyelim.
Parça parça anlattıklarımızı toplarlayıp başladığımız yere dönecek olursak, WI 'ları işlerinizi takip etmek için kullanırsınız. Örneğin bir projede yapılacak işleri gereksinim tipinde WI'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 WI 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.
Nasıl ? İyi gidiyor değil mi? Dahası var...
Proje sırasında gelen değişiklik isteklerini de birer WI yapar ve gereksinimler ile ilişkili olarak kaydedersiniz. Neyin değişmesinin istendiğini ve bunun analizini yazarsınız.
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.
En güzelini en sona sakladım.
WI'ları changeset'ler ile ilişkilendirmek mümkün demiştik ya. İşte bunu da herhangi bir changeset'i check-in ederken ilişkili bir WI seçerek yaparsınız.
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 ... gibi ... 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.
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.
Sırada: Doküman Yönetimi ...
Konuya dalmadan önce söyleyelim, TFS üzerindeki en büyük yapı bir Takım Projesi (Team Project)'dir. Bir Takım Projesinin kaynak kod kontrol sisteminde kendine ait bir alanı, WIT sisteminde kendine ait form tipleri, sharepoint üzerinde kendi proje sitesi ve kendi rapor tipleri vardır. Tüm bunlar Süreç Şablonu (Process Template) adı verilen bir şablon temel alınarak hazırlanır ama bu da ileride detaylarına gireceğimiz bir başlık.
Ne diyorduk? ... hah... work item...
Dediğim gibi her bir projenin kendi ait form tipleri vardır ve Work Item (WI) bunlara verilen genel isimdir. WI dediğimiz; metin alanlardan, çoktan seçmeli listelerden, sekmelerden vs oluşan elektronik bir formdur. Kullandığınız süreç şablonuna 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 WI tipleri ile karşılaşırsınız. Her birinin kendilerine özgü alanları ve ortak alanları vardır. Kabaca şöyle birşeye benzer...
TFS Power Tools paketini indirirseniz mevcut form tipleri üzerinde değişiklik yapabileceğiniz bir editöre kavuşursunuz. Hatta kendi WI tiplerinizi tanımlayabilirsiniz.
WI'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.
WI'lar kişilerin üzerine atanır. Elden ele gezebilir. TFS üzerine WI atılan kişiye otomatik e-posta gönderir. Kendinize ya da bir başkasına atanmış olan WI'ları listeleyebilirsiniz. Kişilerin üzerindeki işleri takip edebilirsiniz.
Her bir WI'ı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 WI'ı 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 WI 'lar ilişkiler konusunda da yeteneklidir. Bir WI'ın ekine herhangi bir tipte bir dosya iliştirmek mümkündür, Kaynak kod kontrol sisteminden bir changeset ile ilişkilendirmek ya da diğer bir WI ile ilişkilendirmek mümkündür. Hele TFS 2010 ile çalışma şansına erişen mutlu kitleden bir bireyseniz WI lar arasındaki ilişkilere tip bile tanımlayabilir durumdasınız demektir ama bu ağız sulandıran detaya şimdi girmeyelim.
Parça parça anlattıklarımızı toplarlayıp başladığımız yere dönecek olursak, WI 'ları işlerinizi takip etmek için kullanırsınız. Örneğin bir projede yapılacak işleri gereksinim tipinde WI'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 WI 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.
Nasıl ? İyi gidiyor değil mi? Dahası var...
Proje sırasında gelen değişiklik isteklerini de birer WI yapar ve gereksinimler ile ilişkili olarak kaydedersiniz. Neyin değişmesinin istendiğini ve bunun analizini yazarsınız.
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.
En güzelini en sona sakladım.
WI'ları changeset'ler ile ilişkilendirmek mümkün demiştik ya. İşte bunu da herhangi bir changeset'i check-in ederken ilişkili bir WI seçerek yaparsınız.
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 ... gibi ... 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.
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.
Sırada: Doküman Yönetimi ...
15 Eylül 2010 Çarşamba
TFS Bileşenleri 1/5 - Kaynak Kod Kontrolü
TFS'in pek çokları tarafından kullanılmaya başlayan ilk bileşeni muhtemelen kaynak kod kontrol sistemidir. Küçük kardeşi Visual Source Safe (VSS)'in aksine oldukça maharetli bir sistemdir.
Peki ne özellikleri var? VSS den çok mu farklı yani ?
Evet çok farklı...
VSS paylaşılan bir klasör üzerinde dosya olarak çalışır. Bu nedenle oldukça yavaştır. Özellikle çok kullanıcılı durumlarda ya da ağ üzerinde uzak bir noktadan erişilmeye çalışıldığında saç baş yoldurur.
TFS kaynak kod kontrol sistemi ise dosyaları VSS'in aksine, SQL veritabanı içerisinde saklar. Dolayısı ile gerektiği kadar güçlendirmek ve ölçeklendirmek mümkündür. Ayrıca istemcilerle iletişimi de tamemen web servisleri üzerinden olduğu için ağ üzerindeki uzaklıktan bağımsız olarak son derece hızlı çalışır. Zaten yüksek kullanıcı sayısı için tasarlanmıştır. Altına yeterli güçte bir donanım koyduğunuzda milyonlarca dosyayı, binlerde kullanıcyı duymaz bile.
Tüm işlemler atomik yapıda çalışır. Yani 100 dosyayı sunucuya iade ederken 99ncu dosyada çakışma çıkarsa tüm yapılan işlem geri alınır. Sunucudaki dosyalar yarı pişmiş halde bırakılmaz.
TFS aynı dosyayı aynı anda birden fazla kullanıcının üzerine almasına izin verir. Oluşacak muhtemel çakışmaları da oldukça iyi yönetir. İstenildiğinde dosyaların sadece bir kullanıcı üzerinde olmasına imkan sağlar (Lock) Otomatik birleştirme (auto-merge) algoritmaları son derece başarılıdır. Genelde kullanıclar sisteme çamur atma eğiliminde olsa da günün sonunda TFS'in işini doğru yaptığı ortaya çıkar. Kodların başına birşey geldiyse hata muhtemelen sizdedir.
Dosyalar TFS üzerinde aynen windows'un klasör yapısına benzer sanal bir ağaç yapısında saklanır. TFS açısından dosyaların içeriği önemli değildir. Onun açısından hepsi birer metin dosyasıdır. VB, C# ya da başka birşey olmasıyla pek ilgilenmez. Hatta daha önceden adı Teamprise olan, daha sonradan Microsoft'un satınalmasıyla Team Explorer Everywhere adını alan eklenti sayesinde Eclipse ortamı üzerinde Java dünyasına da girer, Java kodlarını sa memnuniyetle saklar.
TFS dosyaların tüm tarihçelerini saklar. Herhangi bir dosyanın herhangi bir zamandaki haline ulaşmak. Tüm geçmiş sürümlerini görmek ya da herhengi iki sürümünün arasındaki farkları görmek mümkündür.
(File History) Hatta bunun bir adım da ötesine geçerek bir dosyanın üzerindeki her bir satırın hangi tarihte kim tarafından neden yazıldığını görmek mümkündür (Annotate).
Çok güçlü bir branch mekanizması vardır. Kaynak kod ağacının herhangi bir noktasına aşağı farklı ve çok kademeli dallar oluşturmaya izin verir. (Branch). Farklı dalların üzerindeki değişiklikleri çift yönlü olarak birleştirebilir (Merge). Farklı dallar üzerindeki dosyaların ilişkilerini takip etmeye devam eder ve özellikle TFS 2010'da gelen yeni özellikler sayesinde herhangi bir dalda yapılan bir değişikliğin "Merge" işlemleri ile adım adım hangi dallara aktarıldığını takip etmek mümkündür.
TFS'in rafları vardır. Yani bir kullanıcıya üzerindeki tüm değişiklikleri sunucu üzerinde bir rafa kaldırma (Shelve), daha sonra başka bir noktada raftan tekrar bilgisayara indirme (Unshelve) şansı verir. Bu mekanizma kod gözden geçirme çalışamalarında ve özellikle check-in edilmeye hazır olmayan kodları saklamada ya da makinadan makinaya taşımada çok kullanışlıdır.
Son olarak gelişmiş bir yetkilendirme sistemi vardır. Kaynak kod ağacının herhangi bir noktasında, branch'ler üzerinde, ya da dosya bazında kişilere ya da gruplara ayrıntılı yetkiler tanımlanmasına olanak tanır.
Kaynak kod sistemi özellikle Work Item sistemi ile olan entegre çalışması sayesinde müthiş olanaklar sağlar ama bu konuya Work Item sistemini anlatırken geleceğiz.
Sırada: Work Item Tracking...
Peki ne özellikleri var? VSS den çok mu farklı yani ?
Evet çok farklı...
VSS paylaşılan bir klasör üzerinde dosya olarak çalışır. Bu nedenle oldukça yavaştır. Özellikle çok kullanıcılı durumlarda ya da ağ üzerinde uzak bir noktadan erişilmeye çalışıldığında saç baş yoldurur.
TFS kaynak kod kontrol sistemi ise dosyaları VSS'in aksine, SQL veritabanı içerisinde saklar. Dolayısı ile gerektiği kadar güçlendirmek ve ölçeklendirmek mümkündür. Ayrıca istemcilerle iletişimi de tamemen web servisleri üzerinden olduğu için ağ üzerindeki uzaklıktan bağımsız olarak son derece hızlı çalışır. Zaten yüksek kullanıcı sayısı için tasarlanmıştır. Altına yeterli güçte bir donanım koyduğunuzda milyonlarca dosyayı, binlerde kullanıcyı duymaz bile.
Tüm işlemler atomik yapıda çalışır. Yani 100 dosyayı sunucuya iade ederken 99ncu dosyada çakışma çıkarsa tüm yapılan işlem geri alınır. Sunucudaki dosyalar yarı pişmiş halde bırakılmaz.
TFS aynı dosyayı aynı anda birden fazla kullanıcının üzerine almasına izin verir. Oluşacak muhtemel çakışmaları da oldukça iyi yönetir. İstenildiğinde dosyaların sadece bir kullanıcı üzerinde olmasına imkan sağlar (Lock) Otomatik birleştirme (auto-merge) algoritmaları son derece başarılıdır. Genelde kullanıclar sisteme çamur atma eğiliminde olsa da günün sonunda TFS'in işini doğru yaptığı ortaya çıkar. Kodların başına birşey geldiyse hata muhtemelen sizdedir.
Dosyalar TFS üzerinde aynen windows'un klasör yapısına benzer sanal bir ağaç yapısında saklanır. TFS açısından dosyaların içeriği önemli değildir. Onun açısından hepsi birer metin dosyasıdır. VB, C# ya da başka birşey olmasıyla pek ilgilenmez. Hatta daha önceden adı Teamprise olan, daha sonradan Microsoft'un satınalmasıyla Team Explorer Everywhere adını alan eklenti sayesinde Eclipse ortamı üzerinde Java dünyasına da girer, Java kodlarını sa memnuniyetle saklar.
TFS dosyaların tüm tarihçelerini saklar. Herhangi bir dosyanın herhangi bir zamandaki haline ulaşmak. Tüm geçmiş sürümlerini görmek ya da herhengi iki sürümünün arasındaki farkları görmek mümkündür.
(File History) Hatta bunun bir adım da ötesine geçerek bir dosyanın üzerindeki her bir satırın hangi tarihte kim tarafından neden yazıldığını görmek mümkündür (Annotate).
Çok güçlü bir branch mekanizması vardır. Kaynak kod ağacının herhangi bir noktasına aşağı farklı ve çok kademeli dallar oluşturmaya izin verir. (Branch). Farklı dalların üzerindeki değişiklikleri çift yönlü olarak birleştirebilir (Merge). Farklı dallar üzerindeki dosyaların ilişkilerini takip etmeye devam eder ve özellikle TFS 2010'da gelen yeni özellikler sayesinde herhangi bir dalda yapılan bir değişikliğin "Merge" işlemleri ile adım adım hangi dallara aktarıldığını takip etmek mümkündür.
TFS'in rafları vardır. Yani bir kullanıcıya üzerindeki tüm değişiklikleri sunucu üzerinde bir rafa kaldırma (Shelve), daha sonra başka bir noktada raftan tekrar bilgisayara indirme (Unshelve) şansı verir. Bu mekanizma kod gözden geçirme çalışamalarında ve özellikle check-in edilmeye hazır olmayan kodları saklamada ya da makinadan makinaya taşımada çok kullanışlıdır.
Son olarak gelişmiş bir yetkilendirme sistemi vardır. Kaynak kod ağacının herhangi bir noktasında, branch'ler üzerinde, ya da dosya bazında kişilere ya da gruplara ayrıntılı yetkiler tanımlanmasına olanak tanır.
Kaynak kod sistemi özellikle Work Item sistemi ile olan entegre çalışması sayesinde müthiş olanaklar sağlar ama bu konuya Work Item sistemini anlatırken geleceğiz.
Sırada: Work Item Tracking...
2 Eylül 2010 Perşembe
TFS nedir?
Team Foundation Server, Microsoft'un kendi deyimiyle "Team Collaboration Server"dır.
Türkçe bir karşılık bulsak iyi olur diyorsanız, "Birlikte Çalışma Sunucusu" olarak Türkçe ye çevirmek mümkündür.
Aslında çok farklı faaliyetlerde kullanılabilme potansiyeli olmakla birlikte temelde yazılım geliştirme üzerine çalışan ekiplerin birlikte çalışmalarını sağlamak, kolaylaştırmak, takip etmek, işlerin bir kısmını otomatik hale getirmek, vs... vs...
Microsoft'un kendi ihtiyaçlarından dolayı MS'in içinde doğmuş, büyümüş, kullanılmış, yeterince palazlandığı zaman ürün haline getirilip jelatinli kutuya koyulmuş bir yazılımdır.
Team Foundation Server yazılım geliştirme sırasında ihtiyaç duyulacak bir çok alt sistemi bünyesinde barındırır. Bu alt sistemlerin entegre olarak çalışması sayesine izlenebilirlik imkânı çok artar ve parça parça küçük araçların bir araya getirilmesi ile oluşan bir sisteme göre çok daha fazla katma değer üretir.
TFS'in içinde ne var?
TFS, ana olarak 5 alt bileşenden oluşur diyebiliriz.
TFS ne değildir?
-Proje Yönetim aracı değildir.
Her ne kadar içinde proje yöneticisi zevatın işini kolaylaştıracak bol miktarda özellik barındırsa ve ilk bakışta olacakmış gibi gözükse de işin aslında TFS tam teşekküllü bir proje yönetim aracı değildir. İşin bu kısmını MS Project ya da onun amca oğlu MS Project Server'a devreder. Bu ikisi ile son derece yakın ikili ilişkilerini sürdürmektedir ama ne bileyim, başka bir PM aracı da olabilir.
TFS "work item tracking" mekanizması ile işleri takip eder, gruplandırır, raporlar felan ama kendi içinde takvimlendirme ( scheduling ) ile ilgili birşey bulundurmaz. İşleri sıraya sokayım, birinin başını diğerinin sonuna bağlayayım, "Kritik Yol" hesaplayayım gibi konular mıntıka dışında kalır.
Ayrıca zaman/efor takibi ( timesheet girişi ) ve maliyetlendirme gibi konulara da kalkışmaz. ( TeamExpand timesheet konusu için birşeyler yazdı ama o sonraki bir mesele. )
-Doküman Yönetimi aracı değildir.
Her ne kadar work item'ların yanına herhangi bir tipte dosya iliştirebiliyor olsak da bu TFS'i bir doküman yönetim aracı yapmaya yetmez. Tüm dokümanları topluca alayım, ya da dokümanların içinde arama yaptırayım diyenler hüsrana uğrar, boyunları bükülür.
Bu noktada da topu Sharepoint'e atar. "Kardeşim benim sharepoint'im yok" diyenlere de TFS yanında doküman yönetimi yapmaya yetecek kadar bir sharepoint ile birlikte gelir.
Sırada : TFS'in alt bileşenlerinin detayları...
Team Foundation Server, Microsoft'un kendi deyimiyle "Team Collaboration Server"dır.
Türkçe bir karşılık bulsak iyi olur diyorsanız, "Birlikte Çalışma Sunucusu" olarak Türkçe ye çevirmek mümkündür.
Aslında çok farklı faaliyetlerde kullanılabilme potansiyeli olmakla birlikte temelde yazılım geliştirme üzerine çalışan ekiplerin birlikte çalışmalarını sağlamak, kolaylaştırmak, takip etmek, işlerin bir kısmını otomatik hale getirmek, vs... vs...
Microsoft'un kendi ihtiyaçlarından dolayı MS'in içinde doğmuş, büyümüş, kullanılmış, yeterince palazlandığı zaman ürün haline getirilip jelatinli kutuya koyulmuş bir yazılımdır.
Team Foundation Server yazılım geliştirme sırasında ihtiyaç duyulacak bir çok alt sistemi bünyesinde barındırır. Bu alt sistemlerin entegre olarak çalışması sayesine izlenebilirlik imkânı çok artar ve parça parça küçük araçların bir araya getirilmesi ile oluşan bir sisteme göre çok daha fazla katma değer üretir.
TFS'in içinde ne var?
TFS, ana olarak 5 alt bileşenden oluşur diyebiliriz.
- Source Control
- Work Item Tracking
- Document Management
- Reporting
- Build
TFS ne değildir?
-Proje Yönetim aracı değildir.
Her ne kadar içinde proje yöneticisi zevatın işini kolaylaştıracak bol miktarda özellik barındırsa ve ilk bakışta olacakmış gibi gözükse de işin aslında TFS tam teşekküllü bir proje yönetim aracı değildir. İşin bu kısmını MS Project ya da onun amca oğlu MS Project Server'a devreder. Bu ikisi ile son derece yakın ikili ilişkilerini sürdürmektedir ama ne bileyim, başka bir PM aracı da olabilir.
TFS "work item tracking" mekanizması ile işleri takip eder, gruplandırır, raporlar felan ama kendi içinde takvimlendirme ( scheduling ) ile ilgili birşey bulundurmaz. İşleri sıraya sokayım, birinin başını diğerinin sonuna bağlayayım, "Kritik Yol" hesaplayayım gibi konular mıntıka dışında kalır.
Ayrıca zaman/efor takibi ( timesheet girişi ) ve maliyetlendirme gibi konulara da kalkışmaz. ( TeamExpand timesheet konusu için birşeyler yazdı ama o sonraki bir mesele. )
-Doküman Yönetimi aracı değildir.
Her ne kadar work item'ların yanına herhangi bir tipte dosya iliştirebiliyor olsak da bu TFS'i bir doküman yönetim aracı yapmaya yetmez. Tüm dokümanları topluca alayım, ya da dokümanların içinde arama yaptırayım diyenler hüsrana uğrar, boyunları bükülür.
Bu noktada da topu Sharepoint'e atar. "Kardeşim benim sharepoint'im yok" diyenlere de TFS yanında doküman yönetimi yapmaya yetecek kadar bir sharepoint ile birlikte gelir.
Sırada : TFS'in alt bileşenlerinin detayları...
Kaydol:
Kayıtlar (Atom)