Hätt ich das mal eher benutzt – Versionsverwaltung

Versionsverwaltung brauch ich nicht

Mit der Zeit lernt man ja verschiedene Arten von Entwicklern kennen. Jeder hat so seinen eigenen Stil. Jeder geht unterschiedlich vor. Wenn man eine Aufgabe hat, so wird die von verschiedenen Entwicklern unterschiedlich gelöst. Das ist auch OK so, um nicht sogar zu sagen gut. Dann gibt es wieder so Dinge, da fangen meine Augenlieder an unkontrolliert zu zucken. Versionsverwaltung ist so ein Thema. Wenn man im Gespräch z.B. als Antwort erhält: „Brauch ich nicht, ich arbeite ja alleine.“ Auch nach ein paar Minuten Aufklärung ändert sich die Einstellung nicht. Einem Selbst, als „Sehendem“ ist das dann sehr suspekt. Man kann nicht verstehen, warum der Andere die Vorteile nicht sieht. Und man versteht auch nicht, wieso er sich nicht bekehren lässt. 😉

Microsoft Visual Source Safe

Mein erster Kontakt mit einer Versionsverwaltung war Microsoft Visual Source Safe. Ich habe ein VB6 Programm übernommen. In der Projektgruppe gab es ca. 30 Projektmappen. Die ganze Bedienung gefiel mir jedoch überhaupt nicht. Beim Kompilieren konnte man die Version hochzählen lassen, aber dafür musste man die Projektmappendateien erst alle manuell auschecken. Einige andere Teile waren ebenfalls sehr hakelig in der Bedienung. Irgendwann gab es dann sogar mal den Fall, dass Daten verloren gegangen sind. In der „Entwicklergemeinde“ bekam VSS daher den Ruf, lieber gar keine Versionsverwaltung als Visual Source Safe.

Batches und Zip

Aufgrund des Nichtgefallens von Microsoft Visual Source Safe bin ich dann auf einen Batchmechanismus umgestiegen. Ich habe mir zu bestimmten Zeiten automatisch Zips der Entwicklungsordner erstellen lassen. Mir wurden so automatisch Monats, Wochen und Tagessicherungen erstellt. Mit „robocopy“ habe ich dann jeweils zwischen Tickets gesichert. Auch wenn das System schon eine gute Ausfallsicherheit bot, so war es unheimlich kompliziert bestimmte Änderungen nachzuvollziehen oder gar Unterschiede zu vergleichen. Ganze Ordner zurückzukopieren war auch nicht das Problem. Wollte man aber nur eine bestimmte Funktionalität wiederhaben, musste man viel mit Dateien jonglieren. Das System habe ich aber auch später noch genutzt um meine Bachelorthesis zu sichern. Selbst ohne Netz, durch kopieren auf eine eingesteckte SD hätte ich max. 10 Min verloren. 😉

Microsoft Team Foundation Server

Da mir das Backupsystem mit den Batches immer weniger gefiel, suchte ich nach einer besseren Möglichkeit. SVN war dabei eine Option. Allerdings besuchte ich einen Vortrag der Do-Dotnet User Group Dortmund auf dem Daniel Fisher den Microsoft Team Foundation Server vorstellte. Das System hatte mich überzeugt und ich wollte sofort einen haben. 🙂
Zu dem Zeitpunkt waren wir Microsoft Gold Partner und konnten den Server also für interne Zwecke nutzen. Nach ca. einer Woche hatte ich dann tatsächlich ein laufendes System und begann mich einzuarbeiten. Neben der Versionsverwaltung mit Branching waren die Integration der Tickets und Builds ausschlaggebend für mich. (Aktuell nutze ich Jenkins und Jira)
Der TFS hat meine Art zu arbeiten dann um einiges nach vorne gebracht. Änderungen ließen sich vor dem Einchecken bequem überprüfen. „Debug“-Änderungen ließen sich noch eben mit einem Klick zurücksetzen. Die Arbeit zu mehreren vereinfachte sich kolossal. Auch der TFS verfügte über genügend Bugs. Aber die Endbilanz war durchweg auf der Habenseite.

Mercurial

Irgendwann bröckelte der TFS leider. Das System hatte ein paar Dateifehler und der TFS lief nicht mehr stabil. Da für einen neuen TFS allerdings das Budget fehlte, ging ich den kleineren Weg. Als Versionsverwaltung habe ich mich zwischen git und Mercurial entscheiden müssen. Mercurial hatte den einfachren Einstig, also testete ich das. Tickets verblieben erstmal im TFS und als Buildserver arbeitete ich mich in Jenkins ein.
Auch über diese Entscheidung bin ich auch heute noch froh. In Mercurial habe ich mich schnell einarbeiten können. Das Mercurial hat mir so manchen Schweißausbruch erspart. Mehr als einmal konnte ich einen Bug auch für Kunden beheben, ohne gleich eine komplett neue Version einführen zu müssen. Branching sei dank, konnte ich einfach die Version fixen, die beim Kunden installiert war.
Da es sich bei Mercurial um ein Distributed Version Control System handelt, hat man auch immer die gesamte Historie zur Verfügung. Beim Kunden vor Ort hatte ich somit Zugriff auf alte Änderungen und Fehler ließen sich so oftmals besser eingrenzen. Beim TFS brauchte man dazu eine Verbindung zu selbigem.

git

Nachdem mir Mercurial sehr gute Dienste geleistet hatte, habe ich mich dann irgendwann dazu entschieden, git als Standard zu verwenden. Nicht nur bei Microsoft hat sich git ja mitlerweile als Quasistandard entwickelt und das macht einem die Arbeit mit anderen Repositories gerade auf github dann doch einfacher.
Dabei merke ich eigentlich kaum einen Unterschied zu Mercurial. Was ich aber manchmal ganz praktisch finde, ist das Staging. Wenn ich vor einem Commit noch schnell etwas ausprobieren will, ist das durchaus hilfreich. Ich käme aber auch ohne zurecht. Das Branching soll ja deutlich besser sein. Aber sooo ein Pro-User bin ich dann doch noch nicht. Zumindest wäre mir das noch nicht aufgefallen. 😉

Fazit – Save Games

Ich für meinen Teil möchte jedenfalls nie wieder ohne eine ordentliche Form der Versionsverwaltung arbeiten. Mit nur wenig Mehraufwand gegenüber robocopy, Zip und Konsorten bietet sich eine vielfach höhere Funktionsvielfalt. Man hat quasi mit jedem Commit ein „Save Game“ und kann zu jedem Zeitpunkt wieder zu diesem Punkt zurück.
Beim Aktualisieren von DLLs etc. ist es Gold wert zu wissen, wie es denn Vorher war. Wenn nach der Aktualisierung mal wieder was nicht so will.
Die Vorteile die (verteilte) Teams erhalten kann man gar nicht mal eben aufzählen, ich werfe nur mal „Pull Requests“ in den Raum. Viele Entwickler verstehen selbst geschrieben Tools als ihre Babies. Andere Entwickler kommen da nur schwer ran. Wenn ein Anderer dann wenigstens mit „Pull Requests“ dazu beitragen kann, lässt sich das Tool dann vielleicht dennoch etwas besser weiterentwickeln.
Dank diverser Features, wie eben Branching oder auch Taging, kann man auch bequem verschiedene Versionen kompilieren lassen. Eine Beta und eine Release Version zum Beispiel.
Für mich überwiegen die handfesten Vorteile alle mir bekannten Nachteile. Ein Großteil davon wird eh mit der Angst vor Neuem und der Bequemlichkeit zu tun haben. „Brauch ich nicht“ heißt dann vermutlich eher: „Will ich nicht“.
Und meinetwegen hätte ich gerne mit dem TFS begonnen, an Stelle erst mit VSS und Batches rumhantieren zu müssen.
Was nutzt Ihr um Eure Quelltexte abzusichern? Arbeitet Ihr dabei alleine oder mit mehreren?