Ana içeriğe atla

Team Foundation Server – Genel Bakış

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ı
image
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ılabilirimage

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
image
    • Standard Branch Planimage
    • Advanced Branch Plan
image
    • Concurrent Branch Planimage 
3. Assembly Reference yaklaşımı belirlenmeli;
    1. Öncelikle team project içersinde her bir branch için solution seviyesi oluşturulmalıdır.
    2. Aynı team project ve aynı solution içersindeki projeler bir birini proje referansı olarak göstermelidir.
    3. Aynı team project ve farklı solution’daki projeler dosya referansı olarak yada proje referansı olarak eklenebilir. Ancak proje referansı tercih edilmesi önerilir.
    4. Farklı team project içersindeki bir projenin assembly’si için dosya referasnı önerilir. İki yaklaşım vardır.
      1. Branch yaklaşımı; tüm solution’lar için tek bir kütüpane eklenmesi ve buradan dosya referansı olarak eklenmesi.
      2. 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.
    5. 3. Şahıs assembly lerin dosya referansı olarak eklenmesi önerilir. Bir önceki maddedeki yaklaşımlar tercih edilebilir.
    6. Web Service ve Database bağlantıları kod içersinden static olarak belirlenmesi önerilmez. Dinamik referans kullanılması önerilir.
      1. App.Config’ten alınmalı.
      2. User.Config’ten alınmalı.
    7. 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

Yorumlar

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

Yorum Gönder

Bu blogdaki popüler yayınlar

UML ve Modelleme – Bölüm 4 (Class (Sınıf) Diyagramları)

Bir önceki makalemizde UML modellemede kullanılan ilk diyagram olan Use Case diyagramını incelemiştik. Bu makalemizde nesne tabanlı programlamada kullanılan sınıflar ve sınıfların arasındaki ilişkileri modelleyebileceğimiz diyagramlar olan Class(Sınıf) diyagramlarını inceleyeceğiz. UML’de sınıflar, nesne tabanlı programlama mantığı ile tasarlanmıştır. Sınıf diyagramının amacı bir model içerisinde sınıfların tasvir edilmesidir. Nesne tabanlı uygulamada, sınıfların kendi özellikleri (üye değişkenler), işlevleri (üye fonksiyonlar) ve diğer sınıflarla ilişkileri bulunmaktadır. UML’de sınıf diyagramlarının genel gösterimi aşağıdaki gibidir. Şekil 1. Class Diyagram Şekil1’de görüldüğü üzere bir dikdörtgeni 3 parçaya bölüyoruz. En üst bölüm sınıf adını, orta kısım özellik listesini (üye değişkenler) ve en son kısım, işlev listesini (üye fonksiyonlar) göstermektedir. Çoğu diyagramlarda alt iki bölüm çıkarılır. Genelde tüm özellik ve işlevler gösterilmemektedir. Ama

Yazılım Maliyet Tahmineleme Tecrübeleri

Yazılım mühendisliğinde maliyet hesabı her zaman problem olmuştur. "Bu iş kaç Adam/Gün tutar?" sorusuyla sıkça karşılaşıyoruz. Adam/gün veya Adam/ay ölçütleri bir kaynağın/kişinin belirtilen zaman dilimindeki iş gücü anlamına gelir. Tabi bu noktada yine kafa karışıklıkları başlar. 6 A/G'lik bir işi hızlandıralım diye 2 kişi ile yapmaya çalışsak ve kaynak/kod, modül, altyapı, insan vb. her bir şeyi bir kenara bıraksak, matematiksel basit formülle 6/2=3 A/G'de biter? Gerçek hayat böyle değil, öncelikle bunu anlamamız lazım. Hep şu örnek verilir; "Aynı bebeği 2 kadın birlikte daha kısa sürede doğurur mu?" Eğer bunun cevabı "Evet" ise (veya bir gün böyle bir durum ortaya çıkarsa), yazımı değiştirmem gerekecek:) Mevzu gerçekten derin...Maliyet hesabı; bulunduğunuz firmanın yazılım süreçlerini hangi methodlarla uyguladığına, ilgili işin o dönemdeki aciliyetine, (şirket yönetiminin baskısına:)) vb. bir çok duruma bağlı olabilir. Örneğin; bizim firmada e

UML ve Modelleme – Bölüm 3 (Use Case Diyagramlar)

Önceki iki makalemizde ( 1 , 2 ) UML’e genel olarak değinip ve modellemede kullanacağımız dokuz diyagram hakkında bilgiler vermiştik. Bu makalemizde Use Case diyagramından detaylı bahsedeceğiz. Öncelikle, genel Use case diyagramının tanımını hatırlayalım. “Bir kullanıcı ve bir sistem arasındaki etkileşimi anlatan senaryo topluluğudur.” Ivar Jacobson Senaryo tanımı için der ki: “Aktörle sistem arasında gerçekleştirilen, sonucunda aktöre farkedilir getirisi/ faydası oluşan etkileşimli diyalogdur. ” UML Use Case Diyagramları  sistemin işlevselliğini açıklamak amacıyla kullanılır. Sistemin birbirinden ayrı özelliklerinin detaylarını göstermekten ziyade, Use Case Diyagramlar, tüm mevcut işlevselliği göstermek için kullanılabilir. Buradaki en önemli noktalardan biri,   Use Case Diyagramlar temelde sequence diyagram ve akış diyagramlarından farklıdır. Use Case diyagramlar dört ana elemandan oluşmaktadır. Aktörler , Sistem (Proje kapsamını belirtir) , Use Caseler ve bunlar ara