Anfang 2013 startete bei Communardo der Umzug des über zehn Jahre gewachsenen Subversion-Systems nach Git. Im Folgenden werde ich unser Migrationsvorgehen, die aufgetretenen Probleme und Lösungen beleuchten.

Über die Vorzüge eines DVCS gegenüber der zentralen Variante wurde schon viel geschrieben. Im Internet findet sich eine Vielzahl an Information und Vergleichen zu beiden Verfahren. Einen interessanten Vortrag hielt Sven Peters auf dem Unite 2012 in Frankfurt. Ein – für uns sehr wichtiger – Punkt hat allerdings nichts mit der verwendeten Technik zu tun: Wir wollten die interne Migration gleichzeitig als KnowHow-Aufbau für Kundenprojekte nutzen.
Der initiale Kick-Off für unsere Migration fand am 16. Januar statt. Hier haben wir unsere Ziele abgesteckt und Aufgaben erarbeitet. Hauptproblem war hierbei, dass wir zu diesem Zeitpunkt keine Möglichkeit zu einer validen Schätzung hatten. Wir kannten das Zielsystem noch nicht; keiner hatte den Überblick über alle Repositories im SVN; keiner wusste, wer überhaupt alles im SVN arbeitet und später dann im neuen System arbeiten sollte. Damit stand auch schon die erste Hauptaufgabe fest: Analyse des SVN.
Analyse SVN
Um die Nutzerstatistiken zu erstellen, bemühten wir etwas Linux-Kommandozeilen-Magie:
Für die Anzahl der Nutzer:
for i in *.conf; do grep ^[^#] ${i} | grep ^[^[];done | sort | uniq | wc -l
Für die Commit-Statistik pro Nutzer und Tag:
svn log http://svn/REPOSITORY | grep -E "^r[0-9]+ \| " | awk '{ print $5, $3; }' | sort | uniq -c | sort -n -r | uniq -c | awk '{ OFS = ","; print $3, $4, $2 ; }' | sort -r > REPOSITORY.csv
In unserem Fall ergaben sich für die vorhandenen 22 SVN-Repositories eine Nutzerzahl von 93 Nutzern, die jemals einen Commit durchgeführt haben.
Es war natürlich klar, dass diese 93 Nutzer nicht alle Zugriff auf das neue System brauchen und auch teilweise im SVN schon keinen Zugriff mehr haben. Da sind z.B. Kollegen, die inzwischen Team- oder Abteilungsleiter wurden; Mitarbeiter, die in eine andere Abteilung gewechselt haben bzw. komplett ausgeschiedenen sind; oder auch Schüler des SRZ, die eine Arbeit bei Communardo geschrieben haben. Wir limitierten den Nutzerkreis, indem wir nur Nutzer berücksichtigten, die in den letzten zwölf Monaten ein Commit durchgeführt haben glichen diese Nutzer mit dem Active Directory ab. Als relevante Personengruppe ermittelten wir gut 30 Accounts. Damit war Atlassian Stash gesetzt und wir konnten mit den eigentlichen Migrationsvorbereitungen starten.
Migrationsvorbereitungen
In der Vorbereitungsphase wurden drei Themen parallel angegangen: Zwei Kollegen begannen mit dem Aufsetzen des Systems und der Testmigration von verschiedenen Repositories unterschiedlicher Komplexität. Ein Berechtigungskonzept wurde ausgearbeitet und aus jedem Team wurde ein Git-Ambassador gewählt.
Testmigrationen
Die Migration selbst haben wir mit dem SVN Mirror for Atlassian Stash Plugin durchgeführt und verlief problemlos. Einzige Problematik waren lange Wartezeiten bei der Analyse von großen SVN-Repositories. Wir hatten bei uns einige Sammel-Repositories, die im Zuge der Migration aufgelöst wurden. Neben der eigentlichen Migration wurde die Einbindung von Git in unsere Entwicklungs- und Buildumgebungen untersucht und eingerichtet.
Berechtigungen und Struktur
Um den Verwaltungsaufwand für das Stash möglichst gering zu halten, haben wir uns für eine sehr flache Berechtigungsstruktur entschieden. Die Rollen „Systemadministrator“ und „Administrator“ liegen bei unserer IT-Abteilung. Projekte kann jeder Stash-Nutzer anlegen. Die Berechtigungen innerhalb eines Projektes werden durch einen Verantwortlichen selbständig verwaltet. Herausforderungen stellten einerseits NDA- andererseits Quelloffene-Projekte (z.B. das SubSpace Plugin) dar.
Da es absehbar war, dass sehr viele Projekte in Stash entstehen würden, zeigte sich unter anderem die nicht vorhandene Strukturierung als Problem. Im Rahmen eines Open Innovation Days wurde deshalb das Stash Categories Plugin entwickelt.
Git-Ambassador
Die Git-Ambassadors dienen als erste Anlaufstelle bei Fragen rund um Git bzw. Stash und sind deswegen direkt in den Teams untergebracht. Im März erhielt jeder Ambassador eine vierstündige Schulung, um sich mit dem neuen System vertraut zu machen. Dies beinhaltete neben Grundlagen zu Git, Branching- und Merging-Strategien auch Themen wie Repository-Organisation oder die Verwendung von Hooks.
Migration
Die eigentliche Migration wurde über einen längeren Zeitraum durchgeführt. Wir wollten einerseits keine Kundenprojekte beeinflussen und den Wechsel möglichst geräuschlos über die Bühne bringen, andererseits waren natürlich auch die Kollegen, die die Migration durchführten, in ihren Projekten eingebunden.
Nachdem wir ausreichend Erfahrung durch Testmigrationen sammeln konnten, wurden zuerst die im SVN abgeschlossenen und lange nicht verwendeten Repositories in ein Stash-Projekt „SVN-Archive“ geschoben. Anschließend wurden die Repositories – in enger Abstimmung mit den Nutzern – einzeln nach Stash umgezogen und ggf. aufgeteilt. Die Teammitglieder erhielten eine einstündige Schulung mit Grundlagen zur Arbeit mit Git bzw. Stash.
Fazit
Die Migration ist seit einem Monat abgeschlossen. Die SVN-Repositories sind gesperrt und werden bis Mitte 2014 noch lesend zur Verfügung stehen – anschließend wird der Server einer anderen Verwendung zugeführt. Aus den 22 SVN-Repositories sind 96 Stash-Projekte mit insgesamt 266 Repositories geworden.
Der Aufwand war deutlich geringer als im Vorfeld zu befürchten war. Die Unterstützung für Build- und Entwicklungsumgebungen durch Git ist sehr gut. Die offene Kommunikation im Wiki, die Schulungen der Entwickler und die Git-Ambassadors im Team haben sich als sehr hilfreich erwiesen.