Team Fondation Server (TFS); farklı disiplinler gerektiren Yazılım, Test, Destek, Proje Yönetimi gibi tüm yazılım süreçlerinde kullanılmak üzere tasarlanmış, Microsoft’un geliştirmiş olduğu yazılım süreç yönetimi uygulamasıdır. Team Foundation’ın ilk amacı, takım içerisindeki işbirliğini arttırarak ürün gelişimini kolaylaştırmak ve verimlilik sağlamaktır.
Genel olarak TFS, kurumsal projeler için tasarlanmıştır. Takım içerisindeki iletişimi ve buna bağlı olarak verimi arttırmayı hedeflemiştir. İş durumunu izleme, takım rollerini yönetme, iş süreçlerini çıkartma ve sundugu bir çok araçla proje yönetimini kolaylaştırmada etkin rol oynar
TFS’in Mimari Yapısı
Uygulama Katmanı
TFS; Service oriented bir mimariye sahiptir. Temel uygulamalar için oldukça geniş bir service seti sunmaktadır. Build, Services, VersionControl, Warehouse, WorkItemTracking gibi bir çok web service kütüphanesini barındırmaktadır. Ayrıca SharePoint alt yapısı üzerine inşa edildiğinden bir çok web ve Windows service leri uygulama katmanının tamamını oluşturmaktadır.
Veri Katmanı
TFS, Sql Server üzerinde dosya ve bilgileri depolamaktadır. Bu sayede Transaction yönetimi ve bilgilerin yedeklenebilmesi gibi güçlü özellikler sunmaktadır. Ayrıca Sql Server Reporting Service aracılığı ile basit raporlardan çeşitli veri madenciliği tekniklerinin uygulanıp proje yönetiminde kullanılmak üzere karmaşık analizler yapılabilmesine olanak sağlar.
İstemci Katmanı
TFS'e erişim sağlayarak kullanıcı ile etkileşim sağlayan herhangi bir uygulama TFS'in istemci katmanı olarak gruplandırılabilir. Yaygın olarak kullanılan araçlar Visual Studio Team Suite, Team Explorer, Microsoft Office, Web Access ve diğer bir çok uygulama sayılabilir
TFS’e Geçiş Süreci
1. Team Project Oluşturulması
TFS içersinde yazılım süreçlerini nasıl yöneteceğinize göre belirlemeniz gereken süreç şablonları bulunmaktadır. TFS kurulumları ile birlikte CMMI ve Agile süreç şablonları gelmektedir. İstenildiği taktirde internetten farklı süreç şablonları bulunabileceği gibi kendi süreçlerinize göre yeni bir süreç şablonu tanımlayabilirsiniz. Yada yazılım süreçlerinizi kullanmaya karar verdiğiniz sürece uygun olarak revize etmeniz gerekmektedir.
2. Branch Merge Modelin Oluşturulması
TFS içersinde gerekli görüldüğü durumlarda kodun bir kopyasını alabilmenize olanak sağlayan Branch işlemi bulunmaktadır. Ayrıca farklı kopyalardan kodun diğer bir brange’e taşınabilmesi için de Merge işlemi.
İhtiyaçlarınıza göre bir çok branch merge model oluşturulabilir. Ancak çok fazla branching yapılması Merge maliyetlerini çok arttıracağından gerçekten gerekli değilse tercih edilmemelidir.
Farklı branch oluşturulmasının 2 farklı amacı vardır. Birincisi geliştirme yapmakta olduğunuz kaynak kod ile yayınlamış olduğunuz set’e ait kaynak kodun ayrılması. Bu amaca uygun olarak Dev, Main ve Release olmak üzere en az 3 farklı branch açılması önerilir. Bir diğeri de aynı projede farklı takımların bir birini etkilemeksizin çalışabilmesi.
Kullanılan bazı branch merge modeller aşağıda gösterilmiştir.
- Basic Branch Plan
3. Assembly Reference yaklaşımı belirlenmeli;
- Öncelikle team project içersinde her bir branch için solution seviyesi oluşturulmalıdır.
- Aynı team project ve aynı solution içersindeki projeler bir birini proje referansı olarak göstermelidir.
- Aynı team project ve farklı solution’daki projeler dosya referansı olarak yada proje referansı olarak eklenebilir. Ancak proje referansı tercih edilmesi önerilir.
- Farklı team project içersindeki bir projenin assembly’si için dosya referasnı önerilir. İki yaklaşım vardır.
- Branch yaklaşımı; tüm solution’lar için tek bir kütüpane eklenmesi ve buradan dosya referansı olarak eklenmesi.
- Workspace mapping yaklaşımı; her bilgisayara ortak bir klasör oluşturulup mapping oluşturulması. Bu yöntem tüm bilgisayarlara kurulum yapılmasını yada manuel yönetilmesini gerektirdiğinden önerilmemektedir.
- 3. Şahıs assembly lerin dosya referansı olarak eklenmesi önerilir. Bir önceki maddedeki yaklaşımlar tercih edilebilir.
- Web Service ve Database bağlantıları kod içersinden static olarak belirlenmesi önerilmez. Dinamik referans kullanılması önerilir.
- App.Config’ten alınmalı.
- User.Config’ten alınmalı.
- Projelerin output dizininin ortaklaştırılması önerilir.
4. Team project içersindeki tüm solution’lar gerekli şekilde düzenlendikten sonra Main Branch oluşturulur, Main ve Dev Branchleri içersinde Source isminde yeni bir klasör daha oluşturulur bunun temel nedeni Releases Branch’i içersindeki farklı kaynak kodlarla aynı derinlikte olmasıdır. Bu bağıl referans eklemelerinde önemli olacaktır. Sonrasında Main Branch’ten Dev ve Releases branchler oluşturulur. Releaeses branch altında sahada yaşayan version sayısı kadar branch oluşacaktır.
Uygar MANDUZ
Birde son halini "source control explorer" dan gösterseniz daha anlaşılabilir olurdu. Main Branch tam olarak hangisi olacak anlayamadım. İlk açılan mı Main kabul ediliyor. Teşekkürler.
YanıtlaSil