Gestern war ich im Rahmen der .NET Developers Group München bei einem Vortrag über den Einsatz von TFS in der Praxis. Ich muss zu allererst loswerden, dass der Vortrag und die Stimmung recht gut waren. Es wurde eine Funktionsübersicht geboten, praktische Beispiele an Hand eines kleinen Demo-Projektes aufgezeigt und der Betriebsalltag diskutiert.

Dabei wurden nahezu alle Aspekte des Team Foundation Server durchleuchtet: Source Code Control, Work Item Management, Process Management & Communication, Build Management sowie Reporting Services. Kurz davor wurde noch auf den Aufbau des TFS, die unterstützten Prozesse und die verschiedenen Benutzergruppen (Projektrollen) oberflächlich eingegangen.

Source Control
Beim Source Control Management wurde die konzeptionelle Änderung der “Concurrency” gegenüber VSS deutlich gemacht. Bei einem solchen „Key Feature“ kann man einem User von Subversion nur ein müdes Lächeln abringen. Fakt ist allerdings auch, dass TFS die von z.B. SVN gewohnten Funktionen mitbringt: Check-in/-out, History, Tagging (unter TFS Labels), Branching, Merging – das gewohnte Repertoire. Elegant gelöst, aber bei weitem nicht neu sind die Check-in Policies. So kann man z. B. Kommentare, Code Analysis, Builds oder Test Runs vor dem Check-in erzwingen. Ein nettes Gimmick ist auch das sog. „Shelving“. Dabei werden die Source Code Files an den Server gesendet, allerdings nicht in einem Changeset (Revision) committed. Praktisch also nur am Server zur freien Verfügung abgelegt. Der praktische Einsatz in größeren Teams ist aus meiner Sicht für so etwas doch relativ begrenzt. Allenfalls lässt sich das Feature für Prototypisierung und Easy Change anwenden.

Work Items
Als nächstes Stand das berüchtigte Work Item Management an. An und für sich bietet hier der TFS eine art Issue Tracking System. Natürlich wurde die Integration in Visual Studio, Excel, Project und Sharepoint nicht unerwähnt gelassen. Interessant dabei war, dass man – sozusagen als Workaround – Work Items mit Hilfe von Excel auch offline bearbeiten und anlegen kann. Ein weiterer Aspekt bei Work Items ist die Flexibilität. Praktisch jedes Feld eines Items kann definiert werden – auch wie letztendlich dann das Formular für die Eingabe auszusehen hat.

Zusätzlich zu dieser Indiviualität des Work Items gibt es bestimmte, feste „Anhaltspunkte“ für Work Items. So kann man z.B. Items thematisch mit Hilfe von sog. „Areas“ – ähnlich Themengebieten kategorisieren. Dies kann übrigens – entgegen weitläufiger Meinung – auch hierarchisch gegliedert sein. Eine weitere Kategorisierungsmöglichkeit – diesmal mit Zeitbezug – beiten die Iterationsdefinitionen.

Besonders hervorheben möchte ich auch das integrierte „Workflow-Management“ für Work Items. Im weitesten Sinne arbeitet eine stark vereinfachte Workflow-Engine nach jeder Änderung eines Items definierbare Regeln und State-Transitions ab. Der Witz dabei ist die sehr bequeme Definition des Workflows mit Hilfe eines visuellen Editors. So kann man z.B. einfach und schnell den Workflow für den Work Item Typ „Bug“ an seine Bedürfnisse anpassen.

Apropos Anpassungsfähigkeit – der Team Foundation Server ist im Großen und Ganzen sehr flexibel und lässt sich in sehr vielen einzelnen Punkten anpassen. Angefangen bei Work Items über Process Guidance, Check-In Policies, Process Templates bis hin zur Sharepoint-Modifikation ist alles möglich. Allerdings bringt diese große Flexibilität auch Fallstricke mit sich. Anpassungen sind mit einem relativ hoen Zeitaufwand verbunden und greifen zum Teil Tief in das TFS-System ein. Dabei ist die Wahrscheinlichkeit einer Fehlkonfiguration deutlich höher als mit anderen etablierten Tools.

Das Thema Work Items bei TFS hat seit dem Release des TFS immer wieder eine Frage mit sich gezogen: Warum kann man Work Items nicht im Sharepoint editieren? Diese Frage ist mittlerweile mit „Verwende einfach TeamPlain“ zu beantworten. TeamPlain ist ein inzwischen von Microsoft aufgekauftes Drittprodukt zu TFS, welches für Work Items und einiges mehr eine Web-Oberfläche bietet. Das Tool funktioniert gut, ist stabil und freundlich zu bedienen. Im Übrigen ist der TFS von Haus aus sowieso „nahezu unverwendbar“ (O-Ton Sprecher des Vortrages). Erst das „Power Tool“ für TFS und weitere Add-Ons wie z.B. TeamPlain machen TFS für den Alltag richtig fit.

Testing
In diesem Zusammenhang möchte ich auch ein wenig in die Test-Thematik eingehen. TFS sieht von Haus aus eine „Tester-Rolle“ innerhalb des Entwicklungsprozesses vor. Dieser wird mit Hilfe der Tester-Edition von VSTS in die TFS-Familie eingebunden. Das einzig herausragende hierbei ist die Verknüpfungsfähigkeit von Tests zu Work Items und Builds. Für Automation stehen dem Tester „Test-Lists“ zur Verfügung, die z.B. nach einem Build automatisch durchgeführt werden können. Alle Test-Projekte werden auch in die Versionsverwealtung des TFS aufgenommen.

Schade ist nur, dass Team Foundation Server nur die eigenen – also von Visual Studio angebotenen – Test-Typen und –Projekte akzeptiert. Eine werksmäßige Unterstützung für andere Test-Frameworks sucht man leider vergeblich.

Es ist wohl eine Art von Brauch bei Microsoft, Produkte zu entwickeln die die Integration von bestehenden Systemen bzw. Dritt-Systemen schwerlich unterstützen. Generell ist bei TFS – bis auf das SDK – die mangelnde Zahl an offenen Schnittstellen ein Minuspunkt. Hoffentlich wird dies im Laufe der Evolution des TFS verbessert werden.

Build-Management
Beim Build Management wurde der Vortrag lebendiger; die Praxiserfahrungen wurden offen ausgetauscht. TFS unterstützt hiebei eine Reihe von Funktionen, die helfen sollen, bessere Releases und Roll-Outs durchzuführen. Das aus meiner Sicht wichtigste allerdings wird sträflich vernachlässigt: Automated Builds und Continious Integration. Vergeblich sucht man im Standardumfang des TFS Möglichkeiten für automatische Buildprozesse. Zwar kann man mit einigem Aufwand und ein paar Hilfswerkzeugen sich eine automatisierte Build-Umgebung zusammenschustern, aber bei einem System, welches den Anspruch hat den Software-Entwicklungsprozess optimal zu unterstützen ist diese Tatsache schon fast ein Armutszeugnis.

Ein weiterer Minuspunkt ist der mangelhafte Komfort beim Editieren der Buildscripts. Wenn man z. B. den TFS – welcher intern MSBuild verwendet – dazu bewegen möchte ein .NET 1.1-Projekt zu bauen, hat man außer der Installation von MSBee noch viele Stunden Scriptarbeit vor sich.

Alles in allem ist die Buildunterstützung für heutige Verhältnisse eher unbefriedigend. Da bleibt einem nur der Trost, dass Microsoft gerade hier kräftig nacharbeitet und mit TFS for Orcas deutlich verbesserte Buildfunktionalitäten anbieten möchte.

TFS – Vor- und Nachteile
Ich habe vor dem Vortrag den TFS schon kennenlernen dürfen. Nach dem Vortrag muss ich sagen, dass sich mein eigener Eindruck von TFS bestätigt hat. Kurz zusammengefasst die Pros and Cons aus meiner Sicht:

Vorteile:

• Gutes Konzept, Unterstützt nahezu komplett den Entwicklungsprozess
• Integration in Visual Studio
• .NET-Entwicklungen sehr gut unterstützt
• Extreme Anpassungsfähigkeit (Prozesse, Work Items, Workflows)
• Gutes Reporting und Monitoring

Nachteile:

• Langsam
• Fehlerbehaftet und z.T. Instabil
• Continious Integration absolut unbefriedigend
• Web-Oberfläche / Sharepoint-Support eingeschränkt
• Keine Backup-Funktionen oder –Strategie
• De Facto nur Online-Modus, keine Offline-Funktionalität (Thema Off-Site/On-Site)
• Installation, Wartung und Individualisierung aufwendig
• Kein klares Konzept bei Dokumentationsaufgaben (kein Wiki, keine Sandcastle-Integration)

So, nachdem ich aus einem Meeting-Bericht schon fast ein TFS-Artikel produziert habe, befürchte ich, dass meine Leserschaft ein wenig zu Müde ist für weitere Themen wie Bewertung von TFS aus Unternehmenssicht, Einführung des TFS in die Entwicklung, Vergleich von TFS zu anderen Systemen und noch einiges mehr. Falls Interesse besteht, etwas mehr in das Thema Team Foundation Server einzusteigen – einfach kommentieren oder bei mir melden.