Teamfähiges Visual Studio

Die meisten Änderungen in Visual Studio Team System 2008 gibt es im Build-Management, war das doch der Bereich, welcher in der ersten Version (2005) am wenigsten stark ausgeprägt war. So lassen sich die Build-Projektdateien nun an einem frei einstellbaren Ort in der Versionsverwaltung ablegen, was Branching-Szenarien deutlich erleichtert.



Die fertigen Builds können – abhängig vom Status – automatisch aufgeräumt werden, indem man definiert, wie viele Builds mit welchem Ergebnis erhalten bleiben sollen; die anderen werden gelöscht. Begrifflich wird jetzt zwischen einer Build-Definition, die in der Datenbank gespeichert wird, und einem Build-Typ, welcher wie gehabt als XML in der Versionsverwaltung residiert, unterschieden. Letzterer enthält die konkreten Schritte zur Ausführung des Build-Vorgangs, ersterer allgemeine Informationen wie beispielsweise auf welchem Build-Server gebaut werden soll und wo die Ergebnisse abgelegt werden müssen. Build-Definitionen lassen sich nun nach einem Zeitplan oder nach jedem Eincheckvorgang direkt ausführen.

Um Tests im Rahmen eines Build-Prozesses auszuführen, sind keine Testlisten mehr notwendig. Auch die volle Kraft ihrer Mehrkernprozessoren ist nun mit «multithreaded» Builds nutzbar, um den Kompiliervorgang zu beschleunigen. Ebenfalls hinzugekommen sind Warteschlangen für Builds, die dafür sorgen, dass mehrere Build-Aufträge – ähnlich wie bei Druckeraufträgen unter Windows – hinten eingereiht und nacheinander ausgeführt werden.

Versionsverwaltung

In der Versionsverwaltung sind zahlreiche bisher als Power Tools verfügbare Werkzeuge in das Produkt übergegangen: Die «Annotate»-Funktion zeigt links neben den Codezeilen, mit welchem Changeset diese geändert wurden. Ideal, wenn man aus dem Urlaub kommt und sich fragt, welcher freundliche Kollege in der Quell­codedatei herumgefuhrwerkt hat. Die «Compare»-Funktion vergleicht lokale Ordner mit Ordnern auf dem TFS und umgekehrt oder kreuz und quer.

Für ehemalige Benutzer von Visual SourceSafe ist sicherlich eine Einstellung interessant, die es beim Auschecken erlaubt, auch gleich die neuste Version aus der Versionsverwaltung zu ziehen, was im Standardfall beim TFS nicht passiert.
Für Administratoren gibt es zusätzlich die Möglichkeit, neben dem (logischen) Löschen, welches es auch bisher gab, Dateien und Ordner im TFS zu zerstören. Es ist auch möglich, beispielsweise bei sehr grossen Dateien, alle alten Versionen – ausser der aktuellen – permanent zu löschen.

Date Warehouse und Reporting

Auch im Bereich Data Warehouse und Reporting gab es eine Erweiterung: So können Überschreibungen der Eincheckrichtlinien, wenn diese durch den Entwickler nicht erfüllt, sondern umgangen wurden, nun im Warehouse ausgewertet werden.


Bei der Installation und Adminis­tration des Servers wurde viel gemacht, dennoch sind Installa­tionen nicht immer trivial. Viele Ports können jetzt angepasst werden. Die Remoting-Verbindung zu Build-Servern läuft jetzt auch über Web Services mit anpassbarem Port. Office SharePoint 2007 und Windows SharePoint Service 3.0 werden nun auch unterstützt, ebenso wie benannte Instanzen vom SQL Server 2005.

TFS: Viele Probleme ausgemerzt

Wenn sich der Autor dieses Artikels auf ein einzelnes Feature festlegen müsste, aus welchem Grunde er einen Umstieg vom TFS 2005 auf den 2008er-Release befürworten würde, wäre es keines der bisher genannten, sondern die grosse Zahl an Verbesserungen im Bereiche Performance und Skalierbarkeit sowie die vielen behobenen Problemchen der Vorgängerversion. Beim ersten Start von Visual Studio 2008 und bei Zugriffen auf den TFS 2008 wird das jedem sofort deutlich.


Auch sollte erwähnt werden, dass der TFS 2008 nicht zwingend VSTS 2008 voraussetzt. Man kann getrost mit Visual Studio 2005 weiterarbeiten und auch umgekehrt (VS 2008 mit TFS 2005). Einzig die neuen Build-Features sind aus dem «alten» Visual Studio nicht nutzbar. Installiert man aber den Team Explorer 2008, so wird ein Mini-Visual Studio 2008 installiert, welches diese Optionen anbietet – nur eben nicht mehr integriert in das bestehende Visual Studio 2005.

Übrigens ist das Upgrade auf den TFS 2008, wenn alles gut läuft, eine Sache von mehrfachem Drücken auf «Weiter» und etwa zwanzig Minuten Wartezeit. Dabei wird der TFS 2005 deinstalliert, die Datenbank per Skript aktualisiert und der TFS 2008 installiert.

Development-Edition stark erweitert

Bei den verschiedenen Editionen des Visual-Studio-Team-System-Clients hat sich ebenfalls einiges getan. Nachfolgend ein Überblick über die verschiedenen Neuerungen:



- Die Development Edition hat die meisten Änderungen abbekommen: Die Unit Tests, die mittlerweile auch in der Professional Edition von Visual Studio zu finden sind, laufen deutlich schneller ab. Auch das neue, hilfreiche Rechtsklicken auf «Run Test» beschleunigt das Arbeiten ungemein. Der Profiler zeigt jetzt weniger Daten an, denn bisher wurde man mit diesen überhäuft. Es ist nun einfacher geworden, die Aufzeichnung auf bestimmte Programmphasen zu beschränken, und die Hotpath-Funktion findet auf Wunsch automatisch den «Flaschenhals», der das Programm abbremst. Performance-Berichte lassen sich auch miteinander vergleichen, um beispielsweise nach grösseren Umstrukturierungsaufgaben den Erfolg oder Misserfolg der Aktion genau messen zu können.




Neu eingeführt wurden Codemetriken. Angewandt auf ein Visual-Studio-Projekt oder eine Projektmappe wird die Wartbarkeit des Quellcodes gemessen und als Wartbarkeitsindex von 0 bis 100 ausgegeben, wobei 100 für den bestmöglichen und 0 für den schlechtesten Wert steht. Berechnet wird der Wert aus der sogenannten zyklomatischen Komplexität (wie viele mögliche Wege durch ihre Methode führen), die Anzahl der Codezeilen (weniger bedeutet, leichter zu warten), der Tiefe der Vererbungshierarchie sowie der Abhängigkeit einer Klasse von anderen Klassen. Weiterhin hat die statische Codeanalyse einige neue Regeln bekommen – unter anderem eine Rechtschreib- und Grammatikprüfung für die im Code verwendeten Bezeichner. Leider wurden auch einige Regeln wieder entfernt.



- Die Architecture Edition kommt jetzt mit neuartigem Top-down Service Design daher.


- Die Test Edition erweitert die Funktionalität des Web Test um Unterstützung für AJAX und vereinfacht die Datenbindung gegen XML- und CSV-Dateien. Die Darstellung der Lasttests wurde übersichtlicher gestaltet, und zudem lässt sich bei der Simulation von Benutzern die Testverteilung auf diese wesentlich besser steuern.



- Die Database Edition ist jetzt voll integriert in die Team Suite und den Prozessleitfaden (Process Guidance).

Ausblick auf «Rosario»

Hinter dem Codenamen Visual Studio «Rosario» verbirgt sich die nächste, dritte Version von VSTS samt TFS, die einen grossen Meilenstein in der Weiterentwicklung der ALM-Plattform darstellt. Funktional wurden tiefgreifende Erweiterungen in Angriff genommen. Hierarchische Work Items erlauben ein deutlich höheres Niveau der Durchgängigkeit und Transparenz, die Synchronisation mit dem Microsoft-Project-Server ist dann eine Selbstverständlichkeit und der Bereich Testing & Qualitässicherung – auch in Bezug auf Windows UI-Tests – erfährt mächtig Aufwind.



Bis es so weit ist, wird uns Microsoft die Zeit durch die sogenannten Power Tools, und sicherlich auch mit einem Service Pack, verkürzen. Der Unterschied zwischen beiden ist, dass sich ein Service Pack etwa 6 Monate lang in Planung, Entwicklung und Test befindet, bis es in unsere Hände fällt. Die Power Tools hingegen werden kaum getestet, jedoch von denselben Leuten entwickelt, die auch die Service Packs programmieren. So beliefert uns Microsoft kontinuierlich mit neuer Funktionalität.

Was ist Application Lifecycle Management?

Application Lifecycle Management, oder kurz ALM, steht in der Definition von Microsoft für den Prozess von der ersten Idee, ein Softwareprojekt zu initiieren über die konkreten Schritte zur Entwicklung bis hin zur späteren Wartung und dem Betrieb des Produkts. Application Lifecycle Management umfasst dabei viele Disziplinen wie Anforderungsmanagement, Entwurf & Design, Implementierung und Qualitätssicherung, Softwarekonfigurationsmanagement und richtet sich somit auch an viele unterschiedliche Personengruppen im Team (Architekten, Tester, Entwickler, Datenbankprofis, User-Interface-Spezialisten, Supportmitarbeiter, Anforderer, Projektleiter, Entwicklungsleister).

Visual Studio Team System soll die Plattform für einen werkzeug­unterstützten Application Lifecyle sein, wobei Microsoft hier die Rolle eines Plattformanbieters einnimmt. Es werden in einigen Bereichen spezielle Werkzeuge angeboten, etwa in der Datenbankentwicklung. Andere Bereiche wiederum sind dünn besetzt und warten darauf, von Drittherstellerprodukten abgedeckt zu werden. Beispielsweise fehlt ein Werkzeug, das einem dabei hilft, zu einer Liste von guten Anforderungen zu kommen.