Microsofts neuer Team Foundation Service unter der Lupe

Inhaltsverzeichnis

Microsoft bietet mit Azure eine Cloud-Plattform an, in der sich nicht nur virtuelle Maschinen, sondern auch Webseiten und insbesondere Services betreiben lassen. Das beeinflusst die Art der Softwareentwicklung. Für verteilte Teams und zur Umsetzung agiler Vorgehensmodelle haben die Redmonder den neuen Team Foundation Service ins Spiel gebracht.

Sich ändernde Projektkonstellationen und der Entwicklungszeitgeist forderten bereits in der Vergangenheit oft ein teilweise radikales Umdenken im Bereich der Entwicklungsplattformen. Heute sind es die verteilten Teams und agilen Vorgehensmodelle, die erneut die Sicht auf die Softwareentwicklung neu definieren. Genau für die bietet Microsoft mit Team Foundation Service eine Entwicklungsplattform in den Wolken: Doch was steckt hinter dem Dienst und für wen eignet er sich? Wie flexibel lässt sich der Team Foundation Service an die eigene Softwareentwicklung anpassen? Und braucht der Entwickler überhaupt noch den lokalen Team Foundation Server?

Wie es anfing

Team Foundation Server (TFS) und Team Foundation Service bilden Microsofts ALM-Plattform (Application Lifecycle Management) für die Verwaltung und Ablage von Entwicklungsprojekten. Sie bestehen aus Versionskontrolle für den Quellcode, Build-System, Test-Management, Ticket- und Anforderungssystem, agilen Planungstools und einem übergreifenden Reporting. Mit den bisherigen Versionen des Team Foundation Server bot Microsoft bisher zwei Wege an, den TFS zu betreiben: Die Basisinstallation ohne SharePoint und Reporting für kleine Teams (TFS on Desktop) und die Standardinstallation mit SharePoint Server und SQL Server Reporting Services (TFS Cluster) für mittlere und große Teams und Unternehmen. Mit dem im Sommer freigegebenen TFS 2012 fügt der Hersteller dem Produktportfolio zwei neue Varianten in Form einer kostenlosen Express-Version für maximal fünf Anwender und den Team Foundation Service hinzu (Abb. 1).

Microsoft hatte den Team Foundation Service auf der Build-Konferenz im September 2011 vorgestellt. Ab Juni 2012 konnten Anwender eine Vorschau in Form der TFS Preview nutzen, und seit November 2012 lässt sich der Team Foundation Service produktiv einsetzen. Für die Nutzung benötigt der Anwender lediglich einen Windows-Live-Account, einen Browser der Wahl und eine lokale Installation des Team Explorer. Im Gegensatz zu den anderen Varianten wird keine Hardware für den Server benötigt, da Microsoft das Hosting des Team Foundation Service auf Windows Azure als Software as a Service (SaaS) selbst betreibt. Die Kommunikation zwischen den Client-Tools und der TFS-Instanz erfolgt über HTTPS.

Anwender können sich derzeit für die Nutzung des Team Foundation Service registrieren. Es wird hierbei in drei Gruppen unterschieden. Freuen dürfen sich Teams mit bis zu fünf Anwendern: Die Nutzung bleibt auch in Zukunft kostenfrei. Für die MSDN-Abonnenten ist die Nutzung sogar mit beliebig vielen Anwendern kostenfrei. Lediglich die dritte Gruppe mit mehr als fünf Entwicklern und ohne MSDN-Abonnement muss einen derzeit noch unbekannten monatlichen Beitrag je Anwender entrichten. Microsoft sichert zum aktuellen Zeitpunkt noch keine garantierte Verfügbarkeit zu. Derzeit ist aber davon auszugehen, dass sich die Verfügbarkeit im Rahmen der für Windows Azure garantierten 99,9 bis 99,95 Prozent bewegen wird. Microsoft möchte 2013 weitere Details zur Nutzung und Verfügbarkeit bekannt geben.

Der Schlüssel (zum Erfolg)

Mit dem Team Foundation Service wird Anwendern die Einrichtung eines Entwicklungsprojekts erleichtert: Der Administrator legt über die spezielle Webseite einen neuen Account an (siehe Abb. 2).

Der Account-Name ist zugleich die Adresse, über die die Anwender später auf Team Foundation Service zugreifen. Im Hintergrund konfiguriert Microsoft automatisch eine neue Instanz und legt eine neue Team Project Collection mit dem Namen DefaultCollection an. Das Anlegen und Einrichten des Team Foundation Service erfolgt automatisch und ermöglicht den Anwendern, nach weniger als fünf Minuten mit dem Projekt zu beginnen. Ein Anlegen weiterer Collections auf der Cloud-Instanz, um zum Beispiel Unternehmensbereiche oder Kundenprojekte zu isolieren, wird nicht unterstützt und lässt sich nur durch einen zweiten Account erreichen.

Sobald die Instanz bereitgestellt ist, kann der Administrator über ihre Webseite oder über Visual Studio neue Team-Projekte anlegen (siehe Abb. 3). Beim Aufsetzen des Projekts kann er aktuell zwischen den drei Prozessvorlagen "Microsoft Visual Studio Scrum 2.1", "MSF for Agile Software Development 6.1" und "MSF for CMMI Process Improvement 6.1" auswählen.

Das aus der lokalen TFS-Version gewohnte Verwenden angepasster Prozessvorlagen mit eigenen Work-Item-Typen und angepassten Formularen ist beim Team Foundation Service allerdings nicht möglich. Mit den vorgegebenen Vorlagen zu leben stellt aus Sicht der Autoren für agil arbeitende Teams mit dem Visual Studio Scrum Template allerdings auch kein Problem dar.

Microsoft übernimmt neben dem Aufsetzen die Wartung der TFS-Instanzen, indem es die Windows-Azure-Infrastruktur administriert, die Aktualisierung der Instanzen sicherstellt und alle drei Wochen neue Features bereitstellt. Anwender können sich somit vollkommen auf die Entwicklung ihrer Produkte konzentrieren.

Ein Nachteil der zentralen Wartung durch Microsoft ist die Tatsache, dass der Administrator keinen physischen Zugriff auf die TFS-Instanz hat und somit keine Einstellungen anpassen kann. Einen direkten Zugriff auf die SQL-Datenbanken gibt es beim Team Foundation Service nicht, und damit entfällt ebenfalls die Möglichkeit des Backups auf Datenbankebene. Je nach interner Firmenpolitik kann es notwendig sein, Patches nicht sofort auf den TFS auszurollen, sondern erst zu einem späteren Zeitpunkt. Beim Team Foundation Service bestimmt Microsoft zentral, wann es zum Patch der TFS-Instanzen kommt – der Administrator hat dadurch für seine Instanz keine Hoheit.

Derzeit bietet Microsoft keine Mittel zur revisionssicheren Migration einer Instanz auf eine lokale TFS-Installation an. Der empfohlene Weg über den Datenbank-Ex- und -(Re-)Import auf dem Zielsystem ist nicht möglich. Für eine Migration lassen sich aber die TFS-Integrations-Tools nutzen, um die Daten in eine eigene TFS-Installation zu übertragen.