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!
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.
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: [email protected]