Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Für wen ist was das Richtige? Git, Team Foundation Server oder TF Service?

Dienstag, 19. Februar 2013

Zu einem erfolgreichen Software-Entwicklungsprojekt gehören mindestens eine Versionskontrolle und ein Build-System. Das sind die notwendigen Voraussetzungen, um Code-Änderungen eines Teams versionieren und zu einem Gesamtsystem integrieren zu können. Bei der Auswahl könnte man z.B. auf Git stoßen. Doch halt, welches Build-System soll es dann sein und wie werden eigentlich die Anforderungen und Testfälle verwaltet und wo werden Fehlermeldungen eingetragen und Änderungen verfolgt? Eine Versionskontrolle reicht also bei Weitem nicht aus. Abhilfe bieten komplette ALM-Plattformen wie zum Beispiel Team Foundation Server (TFS) oder Team Foundation Service (TF Service) von Microsoft. Wir wollen erklären, für wen welche der Optionen das Richtige ist.

Team Foundation Server ist die ALM-Plattform von Microsoft. TFS ist in verschiedenen Ausbaustufen einsetzbar. Von einer Desktop-Installation bzw. in der Express-Variante für bis zu 5 Team-Mitglieder bis hin zur Server-Farm für mehrere tausend Benutzer. Neben der lokalen Installation bietet Microsoft seit Kurzem auch eine gehostete Variante an: Team Foundation Service. Dieser Cloud-Dienst unterscheidet sich von der lokalen Installation, weshalb wir an dieser Stelle beleuchten wollen, welche Variante zu welchem Projekt passt. Entscheiden Sie selbst!

TFSScalability

Abbildung 1: Die Skalierungsoptionen von Team Foundation Server

Was steckt drin und was nicht?

Die lokale Variante von TFS unterscheidet sich hinsichtlich des Funktionsumfang von Team Foundation Service. Die gehostete Variante ist weniger anpassbar an eigene Prozesse und Vorgehensweisen als die lokale Installation. Das betrifft auch den Build-Prozess. In TF Service lassen sich auf den bereitgestellten virtuellen Build-Systemen nur eingeschränkt Tools installieren. Gleichzeitig werden die Maschinen aber bei jedem Build neu erzeugt und beinhalten nur ein VS Ultimate und wenige Zusatztools. Immerhin lassen sich auch lokale Build-Server an TF Service anbinden.

Die folgende Übersicht zeigt Ihnen den Umfang und allgemeine Einschränkungen der beiden Versionen.

TFS Lokal

TF Service

Versionskontrolle

Ja, TF VC

Ja, wahlweise TF VC oder Git

Issue und Task Tracking

Ja

Ja

Agile Planung & Kollaborationswerkzeuge

Ja, mit höherer Visual Studio Lizenz

Ja, wahrscheinlich mit höherer Visual Studio Lizenz

Feedback Request

Ja, mit höherer Visual Studio Lizenz

Ja, wahrscheinlich mit höherer Visual Studio Lizenz

Continuous Integration Builds

Ja, eigene Build-Farm

Ja, eingeschränkt auf Azure-VMs, lokale Build-Server möglich

Benutzerverwaltung

Ja, Active Directory

Ja, Microsoft Live ID

Test Case Management

Ja, mit höherer Visual Studio Lizenz

Ja, wahrscheinlich mit höherer Visual Studio Lizenz

Test Lab Management

Ja, vollständig mit HyperV oder tw. mit VMWare u.a. (höhere Visual Studio Lizenz)

Nein

Detailliertes Berichtswesen und Analytics

Ja, umfangreiche SQL und Excel Reports

Nein, nur OData Service

Integration mit SharePoint

Ja, SharePoint 2007 – 2013

Nein

Anpassungen der Prozessvorlage

Ja Nein

Tabelle 1: Funktionsvergleich von TFS und TF Service

Wie man in der ersten Zeile erkennt, ist es nicht wichtig, welches Versionskontrollsystem man einsetzen möchte. Ob TF Version Control oder Git ist bei Team Foundation Service egal. Man wählt beim Anlegen des Projektes aus, womit es weitergehen soll. Die Integration der Work Items, Bugs und Issues sowie Builds und Tests funktioniert in beiden Welten.

TFService

Abbildung 2: Einstieg in Team Foundation Service – To Git or not to Git

Weitere Details zu TF Service finden Sie hier: heise developer: Microsofts neuer Team Foundation Service unter der Lupe

Und wann nehme ich was?

Den lokalen Team Foundation Server benötigt man, sobald man:

  • Volle Kontrolle über Daten und Server benötig
  • Active Direcory User und Windows Authentifizierung nutzen möchte
  • Umfangreiche Reports und SharePoint-Integration verwenden will
  • Prozessanpassungen machen möchte

TF Service kann man in Betracht ziehen wenn man:

  • Kein Setup oder Wartung möchte
  • mit dem Login über Live Id leben kann
  • Azure Continuous Deployment Integration nutzen möchte
  • Einen Standard-Build-Prozess für .NET-Lösungen verwenden kann

Der Einstieg

Wer direkt loslegen möchte, den möchten wir nicht aufhalten. Ein Account für Team Foundation Service kann direkt unter http://tfs.visualstudio.com angelegt werden. Alles was benötigt wird ist eine LiveId mit der Account erzeugt wird. Diese LiveId ist künftig der “Owner” des TF Service-Kontos und damit höchster Administrator.

Den lokalen TFS kann man in einer virtuellen Demo-Maschine für Testzwecke komplett mit Beispieldaten und Schritt-für-Schritt-Anleitung hier herunterladen: http://blogs.msdn.com/b/briankel/archive/2011/09/16/visual-studio-11-application-lifecycle-management-virtual-machine-and-hands-on-labs-demo-scripts.aspx

Wer ihn lieber selbst installieren möchte, kann sich das Installationsmedium aus seiner MSDN oder Online (Achtung: zeitlich begrenzte Testversion) herunterladen: http://www.microsoft.com/visualstudio/eng/downloads#d-2012-editions (Wählen Sie als Sprache bitte unbedingt “English”, da die Sprache eines einmal installierter TFS sich nicht mehr ohne weiteres umstellen lässt!)

Die Express-Variante für bis zu 5 Benutzer gibt es unter: http://www.microsoft.com/visualstudio/eng/downloads#d-2012-express (Wählen Sie als Sprache bitte unbedingt “English”, da die Sprache eines einmal installierter TFS sich nicht mehr ohne weiteres umstellen lässt!)

Beachten Sie bitte bei der Installation unbedingt die Installationsanleitung (jeden Schritt), da sich das System ansonsten nicht für den Produktivbetrieb eignet.

Und wenn ich mich mal anders entscheide?

Vorsicht! Ein Wechsel zwischen Team Foundation Service und einer lokalen Installation – ob Express oder “richtiger” Server – ist nicht ohne weiteres möglich. Microsoft’s empfohlener Weg ist die Verwendung der Integration Platform: . Dabei kommt der sogenannte TFS-to-TFS-Adapter zum Einsatz mit dem die Daten aus einem TFS in den anderen überführt (dupliziert) werden. Hierbei werden allerdings neue Ids vergeben und die Berechtigungen müssen auf Windows- bzw. Active Directory-User umgestellt werden. Neben der komplizierten Konfiguration ist das eine größere Hürde, sodass viele unserer TFS-Kunden die Migration durch AIT ausführen lassen bzw. nur die letzte Version des Source-Code und der Anforderungen übernehmen.

Fazit

Beide Varianten der Microsoft ALM-Plattform sind eine valide Option für Software-Entwicklungsprojekte, die viel mit den Microsoft-Technologien zu tun haben. Ein eindeutiges Entscheidungskriterium wann man nun welche Variante nutzt gibt es nicht. Die Entscheidung wird individuell getroffen werden müssen. Wir helfen gerne dabei! Kontaktieren Sie uns, falls Sie Fragen haben oder Hilfe bei Installation, Upgrade und Benutzung haben: info@aitgmbh.de

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , ,

Hinterlasse eine Antwort