Als CDO unserer gerade entstehenden .NET-Entwicklungsabteilung bei meinem neuen Brötchengeber arbeite ich noch am Aufbau einer guten Infrastruktur für die produktive Entwicklungsarbeit. Der Grundstein ist mittlerweile durch die Einführung von Visual Studio 2005 Professional als Entwicklungswerkzeug gelegt. Vorher standen nur die Express-Versionen von C#, Visual Basic und Web Developer zur Verfügung, die jedoch teilweise erhebliche Einschränkungen gegenüber der Professional-Version haben. Diese sind zwar auf den ersten Blick nicht sichtbar, machen sich aber im täglichen Einsatz um so störender bemerkbar. Als Beispiele seien nur die beinahe vollständig fehlenden Refactoring-Möglichkeiten,das fehlende “Auto”-Fenster für die Variablenüberwachung oder die Schnellansicht zur komfortablen Objekt-Inspektion beim Debuggen genannt . Manchen mag das ja nicht stören (es soll ja immer noch Leute geben, die das “Watch”- [bzw. "Überwachen"-] Fenster beim Debuggen für das höchste der Gefühle halten
) – ich empfinde es wirklich als lästig.

Ein weiterer wichtiger Punkt ist die Etablierung eines Version Control Systems (VCS) zur Verwaltung und Versionierung des Quellcodes. Kaum vorstellbar: Unser ziemlich komplexes, internes Projektmanagement-System (eine Webanwendung auf PHP-Basis) wird momentan von einem durch Selbststudien relativ bewanderten Kollegen implementiert – und zwar mittels Try & Error OHNE VCS! Nicht, dass seine Arbeit schlecht wäre – aber man kennt das ja: Man baut ein Projekt so lange um, bis es überhaupt nicht mehr funktioniert – und schon steht man ohne VCS (und ohne das natürlich vergessene Backup) an einem Punkt da, von dem es so gut wie unmöglich ist, zu einem funktionierenden Stand zurück zu kehren. Nachdem ich ihm die Vorzüge und Einfachheit der Benutzung eines aktuellen VCS dargelegt habe war besagter Kollege dann auch Feuer und Flamme für dessen Nutzung bei seiner Arbeit.
Auf den ersten Blick erscheint es nur natürlich, in einer Microsoft – Entwicklungsumgebung den Visual Source Safe als VCS einzusetzen. Allerdings ist dieser unverhältnismäßig teuer und bietet für diesen Preis als spürbaren Mehrwert eigentlich nur die relativ unkomplizierte Integration in die Visual Studio – IDEs. Abgesehen davon beinhaltet Source Safe keine Funktion, die nicht auch diverse Open Source – VCSs so oder besser zur Verfügung stellen. Deswegen traf ich die Entscheidung, zunächst auf Source Safe zu verzichten und statt dessen die aktuellen Open Source – Tools abzuklopfen. Die Entscheidung fiel dann konsequenter Weise auf den Defakto-”Marktführer” (sofern man bei Open Source davon sprechen kann): Subversion. Subversion ist quasi der Nachfolger des in der Open Source – Szene weit verbreiteten CVS und bietet gegenüber diesem eine Menge Vorteile – die ich mir hier spare aufzuzählen, weil man sie übersichtlich aufbereitet auf der Subversion-Homepage findet, sofern Interesse besteht. Aktuelle Versioenen gibt es sowohl für Linux als auch für Windows. Vom Funktionsumfang ist Subversion durchaus ein geeigneter Ersatz für Source Safe, ganz besonders sogar, wenn man plant, verteilt über das Internet zu arbeiten. Ein Manko bis hierher ist jedoch eine fehlende grafische Benutzeroberfläche, hauptsächlich für Administrationszwecke, sowie die fehlende Integration in die Visual Studio – IDE, da Subversion nativ nur ein Befehlszeilen-Interface besitzt – was nicht wirklich komfortabel ist.
Aber auch hierfür existieren überzeugende (und kostenlose) Lösungen: Als grafische Oberfläche für Subversion ist TortoiseSVN sehr empfehlenswert. Das Tool integriert sich vollständig in den Windows Explorer und ermöglicht eine durchdachte und komfortable Bedienung über das Kontextmenü zu Ordnern und Dateien. Der Einsatz wird dadurch sehr flexibel – man kann quasi wie gewohnt durch’s Dateisystem browsen und alle gewünschten, Subversion betreffenden, Aufgaben wie Aus- und Einchecken von Dateien (bzw. “Update” und “Commit”, wie es bei Subversion heißt), Anlegen von Repositories usw. bequem nebenbei erledigen. Natürlich ist auch ein Repository-Browser integriert – den braucht man aber eher selten.
Die Integration ins Visual Studio schließlich erfolgt durch ein kleines Add-In namens AnkhSVN. Die Installation ist total simpel und in der Oberfläche bietet AnkhSVN (welches aus diversen, gut nachvollziehbaren Gründen kein SCC-Provider, sondern ein Visual Studio Add-In ist) den Komfort, welchen man erwartet: Im Projektexplorer zeigen Icons den Status einer Datei an, das Kontextmenü bietet alle wesentliche Funktionen inklusive History-Management oder Diff und AnkhSVN erkennt weiterhin beim Öffnen einer Solution, ob diese unter Subversion-Kontrolle steht. Zur Zeit steht die jeweils aktuellste Programmversion als Snapshot zum Download. Das heißt im Klartext: Die letzte, offiziell releaste, Version war 0.5.5 im August 2004. Seit dem tut sich aber ständig etwas am Projekt und es sind dutzende neuer Funktionen und Bugfixes hinzu gekommen. In der nächsten Zeit wird es dann wohl wieder einen offiziellen Release von AnkhSVN geben, der auch mit der aktuellsten Subversion-Version 1.4 laufen wird. Bis dahin greift man nach Möglichkeit immer auf einen aktuellen Snapshot zurück, der in der Regel auch stabil läuft. Auch für Eclipse gibt es übrigens eine ziemlich gute Subversion-Anbindung – nämlich über Subclipse.
Zusammenfassend kann ich sagen, dass ich im produktiven Einsatz mit der Kombination aus Visual Studio 2005, Subversion, TortoiseSVN und AnkhSVN sehr zufrieden bin. Installation und Einarbeitung nahmen nur äußerst wenig Zeit in Anspruch und im täglichen Betrieb zeigen sich nicht mehr Bugs als im Source Safe – eher im Gegenteil
Als nächste Schritte werde ich dann die Einrichtung eines separaten “Entwicklungs-Servers” in Auftrag geben, der sowohl die Quellen als auch Dokumentation (MSDN) und nützliche Tools zur Verfügung stellen soll. Auch der Aufbau eines stabilen Testsystems, höchst wahrscheinlich basierend auf NUnit, ist geplant und letztendlich die Automatisierung des Code – Test – Versioning – Deploy – Zyklus (wobei auch das Stichwort “Continous Integration” fallen wird). Über den Stand der Dinge werde ich dann sporadisch berichten.
Tags: .net



4. Januar 2007 um 11:11
Setzt Ihr Subversion auch für Web-Projekte unter VS ein? Ich hab irgendwo gelesen, dass es da Schwierigkeiten mit den .svn Verzeichnisse gibt.
4. Januar 2007 um 11:20
Machen wir in der Tat. Wir konnten aber bis jetzt keine besonderen Probleme feststellen (also solche, die sich von denen bei anderen Projekten unterscheiden
).
22. Januar 2007 um 11:44
Es gibt Probleme mit den .svn-Orndern: die werden von Webanwendungen als Frontpage-Extensions gewertet (zumindest in VS 2003). Es gibt aber einen Hack: Sowohl Tortoise als auch der Commandlineclient kann auf _svn umgestellt werden, und alles läuft Prima
Wir haben vor drei Monaten von VSUS (Visual SourceUnSafe) auf Subversion umgestellt, und sind begeistert. Stein des Anstoßes war die Notwendigkeit für einen externen Zugriff ohne VPN… die teuren VSS-Plugins haben uns nicht überzeugt, und da war SVN erste Wahl.
Leider gibts noch Probleme mit ssl/https in Tortoise, aber die sind bereits erkannt und gefixt (Thread “crash in 1.4.2 and https” in der Subversion development Gruppe) – mal sehn, wanns wieder ein Release gibt…