Team Foundation Server 2010 11.03.2011, 23:32 Uhr

Microsofts ALM-Lösung

Tools für das Application Life Cycle Management kosten oft so viel wie ein Mittelklasseauto. Microsoft machte in diesem Punkt bislang keine Ausnahme. Mit Team Foundation Server 2010 soll sich das ändern.
Team Foundation Server 2010 ist kein typisches Werkzeug für das Application Life Cycle Management (ALM). Es beschränkt sich vielmehr auf die Bereiche Quellcode-, Build- und Arbeitsaufgaben-Verwaltung. Dies ist oft aber genau das, was kleine Teams und Individualentwickler benötigen. In Vergangenheit hatte Team Foundation Server (TFS) zwei kleine Image-Probleme: Er galt als kostspielig und schwierig zu installieren. Während Ersteres bedingt zutraf, da der Server oft als fester Bestandteil von Visual Studio Team System gesehen wurde, traf Letzteres mit Sicherheit zu. Team Foundation Server 2008 konnte nur Windows Server installiert werden und der Windows Server durfte nicht gleichzeitig auch ein Domänenkontroller sein. Mit Team Foundation Server 2010 hat Microsoft seine ALM-Produktfamilie neu positioniert. Auf der einen Seite gibt es Visual Studio ALM, auf der anderen Seite Team Foundation Server 2010. Dieser bringt für Entwickler zwei überaus attraktive Änderungen mit sich. Die Installation kann in der Basic-Konfiguration problemlos erledigt werden und ist auch unter Vista und ab der Home-Edition Windows 7 möglich. Preislich bewegt sich das Produkt mit fünf Client-Lizenzen in der Region von Visual Source Safe beziehungsweise ist im Rahmen eines MSDN-Professional-Abos bereits 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 circa 30 Minuten erledigt – falls SQL Server Express nachträglich installiert werden muss, dauert es etwas länger. Es sollten 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 Versionskontrolle, Build Management und Aufgabenverwaltung zur Verfügung steht. Verwaltet wird das Tool auf 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 in der Administration Console tun, muss dazu aber die Collection vorübergehend anhalten. 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. Team Foundation Server 2010 bringt zwei Vorlagen mit, deren Namen für Standard-Prozess-Methoden stehen: MSF CMMI und MSF Agile 5.0. Letztere ist voreingestellt und wird von Microsoft empfohlen. Ist das Team-Projekt eingerichtet, 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 nicht ausgecheckt werden, da dies mit dem Bearbeiten automatisch geschieht. Mit dem erneuten Einchecken wird ein Changeset angelegt, so dass ein älterer Stand der Anwendung gezielt abgerufen werden kann. Alternativ lässt sich dies über ein Datum oder ein vergebenes Label realisieren.  Arbeitsaufgaben und Build-Management Team Foundation Server 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 – ein «Workitem» – ist ein Element, das zum Beispiel 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 zum Beispiel Projektverantwortliche und können im Rahmen einer Query beispielsweise mithilfe von Excel oder Microsoft Project 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 Team Foundation Server 2010 hat es beim Build-Management eine entscheidende Änderung gegeben: Während bei der Vorversion der Build-Prozess noch von MsBuild gesteuert wurde, ist bei Version 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. 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.Peter Monadjemi


Das könnte Sie auch interessieren