Gestern: TechTalk in München zum Microsoft Team System


Thomas Wölfer
Thomas Wölfer

18. Mai 2005


Zum Vortrag

Dies war bereits der 3. oder 4 Vortrag von Dariusz Parys den ich mir angehört habe, und wie schon zuvor brachte er die Sache locker und verständlich rüber. Allerdings hätte ich mir deutlich mehr technische Details gewünscht: So zeigte Dariusz zwar das irgend eine Form von Integration mit Microsoft Project besteht - wie die aber genau aussieht wurde dann nicht gezeigt. Dariusz zeigte auch, das es einen integrierten Profiler gibt - aber das wars dann auch: Was der genau kann und wie die Integration wirklich aussieht wurde nicht gezeigt. Zum Revision Control System gab es überhaupt keine Informationen, ebenso gab es keine zu Tools wie preFast oder fxCop - bzw. zu deren Integration ins System.

Die Sache war auf 18:00 bis 22:00 angelegt, dauerte dann aber mit einer ausführlichen Pause nur bis 20:45. In den 2 Stunden konnte man wohl nicht mehr Tiefe erwarten. Hätte ich allerdings vorher gewusste das das ganze System in 2 Stunden statt in 4 vorgestellt werden soll, wäre ich wohl erst gar nicht hingegangen.

Wer sich mit den verfügbaren Informationen zum Team System schon auseinandergesetzt hat, der wird nichts neues erfahren - und demjenigen rate ich davon ab, einen der noch folgenden Talks zu besuchen: Zeitverschwendung. Wer das Ding mal live sehen will, oder sich noch nicht damit auseinandergesetzt hat, der nimmt ein bisschen Wissen mit nach Hause.

Ein kleines interessantes Detail gabs zum Timing: Vorraussichtlich wird die fertige Version von Visual Studio 2005 irgendwann mitte November als Download auf MSDN verfügbar werden, das Team System selbst erst ein paar Monate später.

Zum Produkt

Das Team System ist ein komplexes Gebilde: Ein (teilweise) optionale Komponente ist der Team System Foundation Server. Dabei handelt es sich um das 'Verwaltungs' Tool mit dem Revision Control System, dem work-Item Tracking und dergleichen mehr: Es ist also letztlich die Datenbank fürs Team-System.

Dann gibt es drei Komponenten auf Anwendungs-Ebene: Die setzten alle drei auf dem 'normalen' visual Studio auf und werden nach Aufgabenstellung unterteilt. Es gibt eine Version für 'Architekten', eine für 'Entwickler' und eine für 'Tester'. Wer mehr als eine Ausgabe benötigt, der kann eine 'Suite' anschaffen - das geht aber ganz erheblich ins Geld, denn schon die Einzelausgaben liegen im Bereich oberhalb einer MSDN Universal Subscription.

Die 'Archtitect Edition': Kringel und Pfeile

Ich bin vielleicht etwas langsam was derlei Dinge angeht, aber ich habe keine blassen Schimmer wer das benutzen soll. Im wesentlichen gibts hier Tools für zwei unterschiedliche Arten von Software-Architekten: Damit kann man dann irgendwelche Kästchen malen und die mit Pfeilen verbinden. Die Kästen und die Kringel unterscheiden sich ein bisschen, je nachdem ob man 'Application Architect' oder 'Infrastructure Architect' ist. Zusammen gibts dann einen Test, ob ein 'Deployment' möglich ist.

Nun ist es so, das ich schon diverse Architekturen für Anwendungen und Libraries entworfen habe - und dabei habe ich auch schon den ein oder anderen Kringel aufgemalt und selbige mit Pfeilen verbunden. Das war aber immer nur ein Hilfsmittel für die Planung, und kein wesentlicher Bestandteil des Designs. Nun mag es Projekte geben die so groß sind, das man diese Kringel und Pfeile tatsächlich aufheben will um sie für spätere Designänderungen als Dokumentation zur Verfügung zu haben, und es mag auch Projekte geben die so groß sind das sich einige Personen mit nichts anderem als der Archtektur der Anwendung beschäftigen (sprich: keinen Code anfassen oder gar selbst programmieren) - ich glaube aber das das die Projekte sind, die typischerweise irgendwann als fehlgeschlagen eingestellt werden.

Es mag natürlich auch anders sein - aber eine 'normaler' Entwicklungsfirma die Windows-Programme entwirft und entwickelt wird sowas mit Sicherheit im Normalfall nicht einsetzen.

Die 'Tester Edition': Nicht für Windows.Forms

Die 'Tester' Edition ist für Personen gedacht, die sich den Großteil Ihrer Zeit damit bschäftigen, Software zu testen. Es gibt Unit-Tests, die man schreiben und verwalten kann, Stress-Tests und manuelle Tests. Alle kann man zu Test-Sätzen zusammensetzen und die dann in den Build integrieren. (Die manuellen Tests natürlich nicht.)

Der Verwaltungs-Aufwand dafür ist immens: Will man wirklich Unit-Tests für den kompletten Code entwerfen und mitführen, dann wird das die Menge des Quellcodes ganz deutlich erhöhen: Ich schätze mal, das in etwa der doppelte Umfang dabei rauskommt. Das kann natürlich ganz erheblich zur Qualität des Codes beitragen - es kann aber auch ein einziger Verwaltungs-Albtraum werden.

Die Integration der Tests ist ganz gut gelungen: Es gibt sogar eine statistische Aussage darüber, wieviel Prozent des Codes tatsächlich getestet wurden. Diese Aussage ist natürlich nur so gut, wie die vom Tester implementierten Tests - und sagt daher letztlich gar nichts aus. Alles was die Sache dann tut, ist die Qualitätsprüfung mit einer zusätzlichen Indirektion zu versehen. Als Werkzeug mag das hilfreich sein - überzeugt davon bin ich für meinen Fall aber nicht.

Was man übrigens nicht testen kann: Windows.Forms. Benötigt man einen Test bei dem sichergestellt wird, das ein Klick auf einen Button einen bestimmten Dialog öffnet: Pech gehabt - das geht nur mit einem manuellen Test. Und dabei handelt es sich im Wesentlichen um ein Textdokument, das man Schritt für Schritt abarbeitet: Besser als nichts, aber nicht viel besser als nichts.

Was es auch nicht gibt ist ein integriertes Defekt-Tracking: Wer also denkt er könne seine Bug-Datenbank durchd die Einführung des Team Systems loswerden - falsch gedacht.

Die 'Developer Edition'

Die Developer-Edition ist die mit den meisten Tools: Unter anderem gibt es statische Code-Analyse, Profiler mit Sampling und Instrumentation, Build-Checks, ein Regelsystem-Mechanismus für Coding-Conventions, Unit-Testing und einen Klassen-Designer.

Das sind alles nette Tools - auch wenn man in Einzelfällen vielleicht ein wenig zweifelnd sein darf: So halt ich 'Klassen-Designer' einfach nur für eine extrem umständliche Methode Code zu verwalten - auch wenn es sicherlich Fälle gibt wo sowas ganz handlich ist.

Die meisten der Tools kann man auch ohne den (auch etwas teuren) Team Foundation Server benutzen: Ob man aber für die Integration dieser Tools tatsächlich den erheblich höheren Preis vom 'visual Studio Team System Developer Edition' im Vergleich zum normalen Visual Studio bezahlen will: Ansichtssache - und meine Ansicht ist: Nein, das will ich nicht. Da verwende ich lieber weiterhin 'externe' Werkzeuge.

Für wen ist das ganze geeignet ?

Ein klares Wort: Habe keine Ahnung. Ich schätze, Ein Projekt das weniger als 3o Personen beschäftige, kann das ganze Team System gar nicht vernünftig nutzen - schon allein der Verwaltungsaufwand den man treiben muss wird die Effektivität bei kleineren Projekten eher verringern. Wirklich nützlich wird die Sache sicher erst bei Projekten mit viel mehr Entwicklern, Testern und ja, auch Architekten. Das bedeutet auch: Firmen die 'normale' Windows-Programme entwickeln - auch recht umfangreiche Programme wie zum Beispiel unser Faltwerksprogramm das sich im Multi-Megabyte Bereich an Quellcode mit tausenden von beteiligten Dateien befindet - sind fürs Team System schlicht zu klein.

Für solche 'kleinen' Projekte fehlen auch elementare Tools wie Testmöglichkeiten für Windows.Forms oder ein Defekt-Tracking System. Wer normale Windows-Anwendungen baut, der ist in Microsofts Augen 'nur' professioneller Entwickler - und hält sich besser an das normale Visual Studio 2005. Und an 'externe' Tools fürs Revions Control, Defekt Tracking, fürs Build, Profiling und die Einhaltung von Coding-Conventions.