zurück zum Artikel

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.

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 [1] 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.

Arbeiten

Arbeiten mit dem Team Foundation Service

Die gute Nachricht: Mit dem Team Foundation Service arbeiten Anwender exakt wie in der lokalen Variante. Allerdings enthält der Dienst derzeit kein SharePoint-Projektportal oder umfassendes Reporting. Anwender können daher vom lokalen TFS gewohnte Funktionen wie die Dokumentenbibliothek, Wikis und Projekt-Dashboards nicht nutzen.

Wie bei der lokalen Variante lässt sich der Sourcecode automatisch durch den Team Build bauen. Die Build Infrastruktur stellt Microsoft in Form eines Hosted Build Controller bereit – ebenfalls über Windows Azure. Die Anwender müssen für diesen Zweck keine eigene Hardware aufsetzen. Wie vom lokalen TFS gewohnt, können Anpassungen an den Build Process Templates erfolgen und mit eigenen Aktivitäten erweitert werden. Zu beachten ist hierbei allerdings, dass die Anwender keinen direkten Zugriff auf die gehostete Build Infrastruktur haben. Unter bestimmten Voraussetzungen lassen sich Tools dennoch in einer solchen Infrastruktur nutzen. Der zentral bereitgestellte Build-Server ist ein fast blankes Windows-Server-System, das lediglich über eine Installation von Visual Studio Ultimate verfügt und gestattet, via VSIX oder XCopy-Deployment weitere für den Build notwendige Module zu installieren.

Zusätzlich zu den drei Standard-Build-Prozess-Templates DefaultTemplate.11.1.xaml, LabDefaultTemplate.11.xaml und UpgradeTemplate.xaml stellt Microsoft bei der gehosteten Build Infrastruktur ein viertes Template in Form von AzureContinousDeployment.xaml bereit. Mit ihm lassen sich im Team Foundation Service entwickelte Webseiten automatisch nach dem Bau in die Azure-Umgebung ausrollen.

Erfordert der Build-Prozess darüber hinaus gehende Änderungen wie die Registrierung von Komponenten, lässt sich innerhalb des Unternehmensnetzwerks eine eigenständige Build-Infrastruktur aufbauen und statt des Hosted Build Controller nutzen. Über den Microsoft Test Manager (MTM) lassen sich gewohnte Funktionen wie manuelles, exploratives und automatisches Testen mit Coded-UI-Tests nutzen. Beim Testen stehen die aus dem TFS gewohnten Diagnoseadapter bereit. Eine automatische Bereitstellung virtueller Maschinen über Microsofts System Center Virtual Machine Manager (SCVMM) ist nicht möglich. Die Weboberfläche unterstützt die Anwender beim Erstellen und Verwalten von Testfällen und Testplänen (siehe Abb. 4).

Projekt-Management, Reporting und Controlling

Als einen essenziellen Teil der durchgängigen Werkzeugkette betrachten viele TFS-Anwender die von Haus aus integrierten Berichtsfunktionen: Sie unterstützen den Entwickler in seiner täglichen Arbeit ebenso wie das Management beim kontinuierlichen Projekt-Controlling. Das Fehlen der Berichte direkt aus dem TFS-Datenbestand bedeutet in vielen Fällen die Rückkehr zum aufwendigen Arbeiten mit Excel-Tabellen und Drittanbietersystemen. Zu den Aufgaben im Alltag eines Projektleiters gehören die fortwährende Kontrolle, Auswertung des Soll- und Ist-Stands des Projekts und das Erkennen von Risiken und Komplikationen, die zu einem Projektverzug und Mehrkosten führen können.

In der lokalen TFS-Installation erfolgt die Berichtgenerierung mit den SQL Server Reporting Services (SSRS). Diese stellen über das relationale Warehouse und den OLAP-Cube aktuelle und historische Daten zur Lage des Projekts zur Verfügung. Der Team Foundation Service enthält in der aktuellen Version weder ein Warehouse noch Reporting Services. Detaillierte Auswertungen auf Basis des OLAP-Cubes sind daher nicht möglich. In der Weboberfläche steht aber ein vordefiniertes Burn-down-Chart für Releases und Sprints zur Verfügung (siehe Abb. 5).

Der Projektleiter kann sich analog zum lokalen TFS über Client-Tools wie Visual Studio, Excel und Microsoft Project einen Überblick über den Fortschritt des Teams in der aktuellen Iteration verschaffen und die nächsten planen. Im Bereich der Iterationsplanung steht ein Task Board zur Verfügung (siehe Abb. 6). Das Team kann über die Weboberfläche mit dem Task Board die Feinplanung für die aktuelle Iteration durchführen. Die Kapazitätsplanung für einen Sprint kann außerdem auf Basis der in TFS 2012 neu hinzugekommenen Teams Feature ebenfalls direkt in der Weboberfläche erfolgen.

Fazit

Pro und Contra auf einen Blick

Neben den Vorzügen gibt es einige Nachteile. Die folgende Tabelle stellt die wichtigsten Punkte gegenüber.

Fazit

Trotz der Unterschiede im Funktionsumfang und in der Anpassbarkeit zwischen lokalem TFS und Team Foundation Service ist das Angebot eine echte Alternative. Besonders wenn ein kleines Team ein Projekt nach Standardprozessvorlagen wie Scrum, CMMI oder Agile entwickelt. Problematisch wird es, sobald ein unternehmenseigener Entwicklungsprozess abgebildet werden soll. Des Weiteren ist die Realisierung mehrjähriger Großprojekte mit vielen Mitarbeitern nur schwer vorstellbar.

Die Autoren nutzen den Team Foundation Service in eigenen Projekten, um mit verteilten Teams auf einfache Weise in Forschungs- und Pilotprojekten zum Beispiel zu Windows-8-Apps und Windows Azure Services zusammenzuarbeiten. Besonders faszinierend ist die volle Unterstützung im Bereich der Softwareentwicklung, ohne gleichzeitig externe Teammitglieder auf die eigene Infrastruktur freischalten zu müssen. Neben den Features wie Storyboarding, Task Board und Teamplanung bildet das System eine geeignete Plattform für dezentral organisierte Teams. Auf diese Art wurden bei der Firma der Autoren bis dato zwei agile Projekte erfolgreich zum Abschluss gebracht.

Microsoft hat mit dem TFS 2012 das Release-Intervall auf vierteljährlich erscheinende Updates verkürzt. Mit ihnen werden nicht nur Hotfixes, sondern auch Features bereitgestellt, die den TFS um nützliche Funktionen erweitern. Man darf gespannt sein, welche Features Microsoft in den kommenden Monaten veröffentlicht.

Stefan Mieth und Michael Ring
sind TFS-Berater im TeamSystemPro-Team der AIT GmbH & Co. KG. Sie unterstützten Unternehmen bei der Einführung und Anpassung von Microsofts ALM-Plattform sowie der zielorientierten Abbildung und Optimierung bestehender Entwicklungsprozesse. (ane [2])

URL dieses Artikels:
https://www.heise.de/-1767817

Links in diesem Artikel:
[1] http://tfs.visualstudio.com
[2] mailto:ane@heise.de

Copyright © 2012 Heise Medien