ALM in der .NET-Welt: Team Foundation Server oder Freeware?

Inhaltsverzeichnis

Für das Application Lifecycle Management (ALM) in der .NET-Welt stehen Unternehmen oft vor der Frage, ob sie auf kostenfreie (Open-Source-)Produkte oder Microsofts kostenpflichtigen Team Foundation Server (TFS) setzen. Der letzte Beitrag der Artikelserie "10 wichtige Fragen zu .NET" beleuchtet Gründe, die für den Einsatz des Microsoft-Servers sprechen.

Zum Entwicklungsprozess gehört wesentlich mehr als nur ein komfortabler Designer und ein Code-Editor. Zumindest Quellcodeverwaltung, Aufgaben- und Bug-Tracking sind etabliert. Darüber hinaus findet man immer häufiger Unit-Testing und automatisierte Build-Prozesse im Sinne von Continous Integration.

Mehr Infos

10 wichtige Fragen zu .NET

In dieser zehnteiligen Serie liefert .NET-Experte Holger Schwichtenberg Antworten auf die am häufigsten gestellten Fragen, die .NET-Entwickler beschäftigen.

1. .NET 2.0 oder .NET 3.5?
2. VB oder C#?
3. Express oder Professional?
4. Windows Forms oder WPF?
5. LINQ-to-SQL oder ADO.NET Entity Framework?
6. Visual Studio auf Deutsch oder auf Englisch?
7. ASP.NET, Ajax oder Silverlight?
8. DataReader, DataSet oder ORM?
9. Sinn und Unsinn der Windows Communication Foundation
10. ALM in der .NET-Welt: Team Foundation Server oder Freeware?
    

Microsoft hatte ALM viele Jahre nur stiefmütterlich behandelt. Die Quellcodeverwaltung Visual SourceSafe (VSS) war nicht nur funktionsarm, sondern auch für defekte Datenbanken bekannt, die viel Wartungsaufwand erforderten. Für die Modellierung bot der Konzern mit Visio ebenfalls keine adäquate Lösung. Intern verwendete Microsoft schon länger einige selbst entwickelte Werkzeuge, die dann 2005 unter dem Oberbegriff Visual Studio Team System (VSTS) als ein integriertes ALM-Produkt öffentlich erschienen. Zu VSTS gehörten einerseits eine erweiterte Version von Visual Studio als Client-Anwendung, zum anderen der Team Foundation Server (TFS) als zentraler Server zur Verwaltung und Steuerung von Softwareprojekten.

Die Vergangenheitsform ist für den Begriff "VSTS" gerechtfertigt, da Microsoft ihn mit Visual Studio 2010 wieder begraben hat. Es gibt weiterhin Visual Studio und den Team Foundation Server, aber keine eigenständige Produktbezeichnung für die ALM-Produktserie mehr. Anstelle der Visual Studio "Team Suite", die bisher die größte und teuerste Version war, tritt nun "Visual Studio Ultimate". Einige ALM-Funktionen sind insgesamt noch nicht so weit, wie man es von Platzhirschen wie Micro Focus (früher Borland), IBM (früher Rational), Perforce und MKS kennt.

Beispielsweise ist Rationals DOORS viel strukturierter und mächtiger beim Anforderungsmanagement als die Work-Item-Verwaltung im TFS. Micro Focus wiederum bietet mit Together ein Werkzeug für die modellgetriebene Entwicklung, das es in der Form bei Microsoft gar nicht gibt. Die von Perforce in seiner Versionsverwaltung zu findenden Verteilungsmechanismen wie ein lose gekoppeltes Kooperationsmodell, um mehrere Versionsverwaltungsserver zu verbinden, sind in TFS bisher nicht vorhanden. Aber das Microsoft-Produkt ist kostengünstiger. Gartner hat dazu im März 2009 einen Vergleich veröffentlicht.

Bei den Funktionen, die VSTS beziehungsweise Visual Studio 2010 Ultimate bieten, kann man differenzieren in solche, die nur in Verbindung mit dem TFS arbeiten, und solche, die man zudem lokal ohne TFS verwenden kann. Lokal zu nutzende ALM-Funktionen sind etwa:

• Modellierung (ab Visual Studio 2010 auch begrenzte UML-Funktionen)
• Ablaufverfolgung während des Debuggens (IntelliTrace)
• statische Codeanalyse und -metriken (Richtlinien und Codequalität)
• Unit-Tests, Testabdeckung (Code Coverage), Webtests und Desktop-Oberflächentests
• Profiling (Geschwindigkeits- und Speicherverbrauchsmessung)
• Datenbanken (Versionierung und Deployment von Datenbank-Schemata, Testdatengenerator, Unit-Tests in T-SQL)

Neben Visual Studio bietet Microsoft mit dem Test Manager ein spezielles Werkzeug für Tester zur Verwaltung von Testplänen, Ausführung von Tests mit Aufzeichnung von Ablaufdaten und der Option, Videos aufzuzeichnen.

Nur in Verbindung mit einem TFS funktionieren:

• Quellcodeverwaltung (Team Foundation Version Control – TFVC)
• Projektmanagement
• serverseitige Übersetzung/Continous Integration (Build-Server)
• Tätigkeitsverwaltung (Anforderungen, Aufgaben, Fehler), die man hierarchisch anordnen kann
• Berichtswesen
• Team Web Access (Webportal unter anderem zum Melden von Fehlern) und Projektportal mit Dokumentenverwaltung (auf SharePoint-Basis)
• Lab Management (virtualisierte Testsysteme für automatische Tests)

Quellcodeverwaltung und Client-/Server-Integration

Der Wert des TFS-Einsatzes liegt vor allem in der Integration – sowohl zwischen den einzelnen Funktionsbereichen als auch hinsichtlich der Nutzung von Office-Anwendungen wie Excel und Project als Clients.

Ein Entwickler kann beim Bereitstellen von Code im Quellcodeverwaltungssystem (Check-in) nicht nur wie sonst üblich einen Kommentar hinterlegen, sondern den Check-in direkt einer oder mehreren Aufgaben zuordnen, zum Beispiel gemeldeten Fehlern. Zudem kann ein Projektleiter im TFS eine solche Zuordnung durch sogenannte Check-in-Policies als verpflichtend einrichten. Visual Studio beschwert sich dann beim Entwickler, wenn er den Check-in keiner Tätigkeit zuordnet. Ab TFS 2010 kann eine Check-in-Policy auch besagen, dass der eingelagerte Code erst aus einer Liste von definierten Unit-Tests und Codeanalysen bestehen muss. Solange ist der Code nur vorläufig eingecheckt (Gated Check-in). Erst wenn der Code die Tests bestanden hat, können ihn die anderen Entwickler abrufen.

Gated Check-ins sind ein Beispiel, wie clientseitige Funktionen von Visual Studio einen Mehrwert durch die Ausführung auf der Serverseite generieren. Ein zweites ist Continous Integration. Durch Konfiguration eines sogenannten Build-Servers lässt sich erreichen, dass man Projekte serverseitig kompiliert. Das kann entweder periodisch erfolgen oder aber nach jedem Check-in. Das Ergebnis lässt sich in Visual Studio oder dem Webportal abrufen, oder man kann die Entwickler per E-Mail informieren.

Das Erstellen und Abfragen von Tätigkeiten ist nicht nur über die Visual-Studio-Oberfläche (siehe die nebenstehende Abbildung des Team Explorer) und die TFS-Weboberfläche, sondern auch über Excel und Microsoft Project sowie – durch das Zusatzprodukt Team Companion – in Outlook realisierbar. Standardmäßig kennt TFS als Tätigkeitstypen beispielsweise Task, Bug und User Story, jeweils mit zahlreichen Attributen. Sowohl die Tätigkeitstypen als auch die Attribute lassen sich aber umdefinieren. Neu bei TFS 2010 ist das hierarchische Anordnen von Tätigkeiten. Der TFS speichert alles (Aufgaben, Quellcode, Build-Prozesse et cetera) in einer SQL-Server-Datenbank.

Für Projektleiter bietet TFS Berichte, die den Projektfortschritt anzeigen, etwa die Anzahl der implementierten Funktionen und die der gemeldeten Fehler im Zeitablauf. Berichte kann man über Visual Studio, das Webportal oder Excel abrufen. Der TFS integriert sich in das Sicherheitssystem von Windows Server, das heißt, durch die Zuordnung von Benutzern zu Gruppen im Active Directory erhalten Anwender Rechte auf dem TFS.