Status quo der Versionskontrolle

Inhaltsverzeichnis

Bricht man heute eine Diskussion über Versionskontrolle vom Zaun, ist es zuweilen verwunderlich, welche Aspekte mittlerweile einfließen. DevOps, DVCS, Agile, ALM Governance, Continuous "Everything" heißen die neuen Schlagworte, und es werden gar wieder Kämpfe in der Versionierungswelt ausgefochten und neue Positionierungen vorgenommen.

In den frühen 80ern des letzten Jahrhunderts entstand das Revision Control System (RCS). Noch im selben Jahrzehnt erschien CVS zunächst als RCS-Aufsatz auf der Bildfläche und dominierte jahrelang die Entwicklung in der Open-Source-Welt. In der Folge etablierten sich kommerzielle Anbieter wie ClearCase, PVCS und Perforce, und natürlich versionierten Borland-Anhänger zunächst mit StarTeam und Microsoft-Anhänger zunächst mit Visual SourceSafe. Viel ist dann über die Jahrtausendwende hinweg nicht passiert, sieht man mal davon ab, dass Subversion weitgehend den Platz von CVS in der Open-Source-Welt eingenommen und sich darüber hinaus in der kommerziellen Softwareentwicklung stark verbreitet hat. Einiges hat sich abgenutzt, ein paar wenige Neue wie AccuRev, Plastic SCM oder der Team Foundation Server sind erschienen. So weit, so langweilig.

Als besonders leidenschaftlich lässt sich das Verhältnis zwischen dem Versionierungswerkzeug und seinem Benutzer, dem Entwickler, üblicherweise nicht bezeichnen. Aus der Sicht vieler Entwickler steht das Tool im besten Fall nicht im Weg. Der eine oder andere freut sich auch über eine leistungsfähige GUI und über performantes Einchecken von Änderungen, wohl wissend, dass es auch Tools gibt, die einen an dieser Stelle mitunter mit langen Wartezeiten quälen.

Viele der heutigen Komfortfunktionen existieren, da sie sich aus der Integration mit populären Entwicklungsumgebungen wie Visual Studio oder Eclipse ergeben. Gleichzeitig verwischen so auch manche Unterschiede zwischen den Versionierungswerkzeugen, was aber viele Entwickler kaum bedauern dürften. Kurzum: Ein Softwareentwickler arbeitet heute ganz selbstverständlich mit Versionierungswerkzeugen, ohne merkliche Gefühlsausbrüche. Bemerkenswert ist es allerdings – Fachgespräche auf Messen belegen das –, dass es noch 2013 Softwareentwickler gibt, die gänzlich ohne Versionierung über Werkzeuge auskommen. An die Stelle von Branches und Labels treten Zip- oder Tar-Archive auf Netzwerklaufwerken mit so klangvollen Namen wie ProduktA-Version1.zip oder noch besser ProduktA-Version1-neu.zip.

Die Anderen – und ein paar Trends

Produktentwicklung, in der Software zunehmend dominierend, kennt aber noch eine Reihe weiterer Beteiligter mit berechtigten Ansprüchen an die Versionsverwaltung. An erster Stelle sind da Stabilität und Verlässlichkeit zu nennen. Nimmt man die jedoch als gegeben an, bleiben Anforderungen, die nicht notwendigerweise für jeden Entwickler relevant sind. Betrachtet seien hierzu ein paar Trends oder Herausforderungen, denen sich Softwareunternehmen zu stellen haben.

Komponentenbasierte Softwareentwicklung ist allgegenwärtig und gleichzeitig eine Herausforderung für die Versionsverwaltung. Auch wenn eine Komponente nur verwendet werden soll, ist es schlicht notwendig, die Verwendung jeweils nachzuvollziehen und dem Entwickler auch die richtige Komponente im Projekt zur Verfügung zu stellen. Das gilt nicht nur für die Entwicklung, sondern reicht weit in Build, Softwareproduktion und Auslieferung hinein.

Besonders delikat werden die Anforderungen, sollten Komponenten eigene Produktlebenszyklen haben oder gar externe Komponenten, seien sie kommerziell oder Open Source, Verwendung finden. Die Nutzung ausgewählter Versionen und der möglicherweise damit in Zusammenhang stehenden Lizenzen kann dann schon projektentscheidend sein oder gar Gegenstand von Regressansprüchen werden, wenn Lizenzbedingungen verletzt werden. Dass aus Komponenten zusammengefügte Produkte noch in einer weiteren Dimension als Varianten Gegenstand von Wiederverwendung werden, lässt die Anforderungen nochmals komplexer erscheinen. Aus versionierungstechnischer Sicht gehen sie flexibel nutzbare Verzweigungen (Branches) und auch dynamisch anpassbare Arbeitsbereiche (Workspaces) im Grunde angemessen an.

Solange das Werkzeug diese Eigenschaften zuverlässig anbietet, ist die Herausforderung zumindest technisch zu bewältigen. Die wirkliche Anforderung liegt dann darin, in einer komplexen Produktwelt den Überblick zu behalten und Änderungen gesichert zwischen den Branches fließen zu lassen – entweder um Fehlerbeseitigungen von einer Kundenvariante in alle anderen betroffenen zu propagieren oder um festzustellen, welche Produktvarianten von Änderungen an Komponenten betroffen sind. In erster Linie bedarf es hierzu einer gesicherten und erprobten Methodik zum Codezeilen-Management. Hilfreich ist es, wenn entsprechende Visualisierungen zur Verfügung stehen und eine solche Methodik auch in Software gegossen ist. Bei Versionierungswerkzeugen ist das seltener der Fall, als man erwarten würde.