Team Foundation Server2010 – viel Leistung für wenig Geld

Team Foundation Server 2010 ist kein typisches ALM-Werkzeug, es beschränkt sich auf die Bereiche Quellcode-, Build- und Arbeitsaufgaben-Verwaltung. Dies ist oft aber genau das, was kleine Teams und Individualentwickler benötigen. In der Vergangenheit hatte Team Foundation Server (TFS) zwei kleine Image-Probleme: Er galt als kostspielig und schwierig zu installieren. Während Ersteres nur bedingt zutraf, da TFS oft als fester Bestandteil von Visual Studio Team System gesehen wurde, traf Letzteres mit Sicherheit zu. TFS 2008 konnte nur Windows Server installiert werden und der Server durfte nicht gleichzeitig auch ein Domänenkontroller sein. Mit TFS 2010 hat Microsoft seine ALM-Produktfamilie neu positioniert. Auf der einen Seite gibt es Visual Studio ALM, auf der anderen Seite gibt es TFS 2010. Dieser bringt für Entwickler zwei überaus attraktive Änderungen mit sich. Die Installation kann in der Basic-Konfiguration vollkommen problemlos erledigt werden und ist auch unter Vista und Windows 7 (auch in der Home-Edition) möglich. Preislich bewegt sich das Produkt mit 5 Client-Lizenzen in der Region von Visual Source Safe bzw. ist im Rahmen einer MSDN Professional Subskription bereits fest dabei. Damit bietet Microsoft ein überaus attraktives Paket, das vor allem für kleine Teams und Individualentwickler in Frage kommt, die an einer Alternative zu Visual Source Safe interessiert sind. Installation in 30 Minuten Die Installation hält was im Prospekt versprochen wird. Im Gegensatz zu einer TFS 2008-Installation setzt sie keine Checklisten voraus und ist in der Regel in ca. 30 Minuten erledigt (falls SQL Server Express nachträglich installiert werden muss dauert es etwas länger). Die Installation ist auch unter Vista oder Windows 7 Home Edition ohne Abstriche möglich. Es sollten lediglich knapp 1 GByte Festplattenspeicher frei sein. Am Ende erhält man einen Team Foundation Server, bei dem die Benutzerverwaltung bereits eingerichtet ist, und der für Versionsverwaltung, Build Management und Aufgabenverwaltung zur Verfügung steht. Verwaltet wird der TFS in der Team Foundation Administration Console. Hier werden unter anderem die Collections und das Build-Management konfiguriert. Eine Collection ist dazu da, mehrere Team-Projekte unter einem Hut zusammenzufassen. Für Individualentwickler dürfte es keinen Grund geben, zusätzliche Collections anzulegen (wer die „Default Collection“ umbenennen möchte, kann dies an dieser Stelle tun, muss dazu die Collection aber erst anhalten).

Abbildung 1: Team Foundation Administration Console Alle für den Entwicklungsprozess relevanten Aktivitäten werden in Visual Studio 2010 vorgenommen. Dafür ist der Team Explorer 2010 erforderlich, der ein Teil von Team Foundation Server 2010 ist, aber auch als separater Download zur Verfügung steht. Möchte man ein neues Visual Studio-Projekt von Anfang unter der Versionskontrolle TFS anlegen oder ein vorhandenes Projekt zum TFS hinzufügen, muss dafür in einer TFS-Collection ein Team-Projekt angelegt werden. Ein Team-Projekt basiert auf einem Template, mit dem eine Reihe von Einstellungen verbunden sind. „Out of the box“ bietet TFS 2010 zwei Vorlagen an, deren Namen für Standard-Prozess-Methoden stehen: MSF CMMI und MSF Agile 5.0. Letztere ist voreingestellt und wird auch von Microsoft empfohlen. Steht das Team-Projekt kann ein Visual Studio-Projekt mit seinen Dateien eingecheckt werden. Dabei werden alle Projektdateien in das TFS-Repository übertragen. Kleine Symbole im Projektmappen- Explorer zeigen den aktuellen Status der Dateien an. Soll eine Datei geändert werden, muss sie offiziell ausgecheckt und nach der Änderung wieder eingecheckt werden. Dabei wird ein Changeset angelegt, durch das die Möglichkeit besteht, einen älteren Stand der Anwendung gezielt abzurufen. Alternativ kann dies über ein Datum oder ein vergebenes Label geschehen.

Abbildung 2: Ein Projekt wurde in die TFS-Versionskontrolle eingecheckt Arbeitsaufgaben und Build-Management TFS 2010 hat auch in der Basic-Konfiguration sehr viel mehr zu bieten als eine reine Versionskontrolle. Die zwei weiteren Bereiche, die bei der Installation zur Auswahl stehen, sind Arbeitsaufgaben und Build-Management. Eine Arbeitsaufgabe („Workitem“) ist ein Element, das z.B. einen Bug, einen Änderungsvorschlag oder eine selbstgestellte Aufgabe darstellt. Arbeitsaufgaben begleiten ein Changeset und reichern es mit Metainformationen an, die im Build-Prozess oder im Lebenszyklus der Anwendung auf vielfältige Weise ausgewertet werden können. Arbeitsaufgaben beschreiben den aktuellen Projektzustand für Projektleiter und andere Personen, die in dem Projekt involviert sind, und können im Rahmen einer Query z.B. von Excel oder Microsoft Project ausgewertet werden.

Abbildung 3: Arbeitsaufgaben-Queries können in Excel ausgewertet werden Das Build-Management muss in der Team Foundation Administration Console konfiguriert werden, damit es in Visual Studio 2010 zur Verfügung steht. Es ist immer dann interessant, wenn das Ergebnis des Build-Prozesses an einem zentralen Ort im Netzwerk zur Verfügung stehen soll. Der Build-Prozess wird in diesem Fall nicht von Visual Studio, sondern von einem Agenten gesteuert, der wiederum unter der Kontrolle eines Build-Controllers läuft. Der Build-Prozess kann entweder manuell oder beim Einchecken der Quellen gestartet werden, was einen „Continous Integration“-Entwicklungsprozess ermöglicht. Bei TFS 2010 hat es beim Build-Management eine wichtige Änderung gegeben. Während bei TFS 2008 der Build-Prozess noch von MsBuild gesteuert wurde, ist bei TFS 2010 dafür die Windows Workflow Foundation zuständig. Das hat unter anderem zur Folge, dass der Build-Prozess auf der Basis einer XAML-Definitionsdatei definiert wird und sich mit Hilfe eines komfortablen Designers und zahlreichen vordefinierten Activities abbilden lässt.

Abbildung 4: Eine Arbeitsaufgabe beschreibt einen Bug TFS 2010 als Visual Source-Nachfolger Mit Team Foundation Server 2010 bietet Microsoft eine attraktive Alternative zu Visual Source Safe und anderen Versionskontrollwerkzeugen, die auch für kleine Budgets in Frage kommt. Auch wenn Arbeitsaufgaben und Build-Management eventuell als ein nettes, aber für kleine Projekte überflüssiges Extra empfunden werden könnten, dürften sie schnell zu einem festen Bestandteil des Entwicklungsprozesses werden.