Erfolgreich auf Git gewechselt

Anfang 2013 star­tete bei Communardo der Umzug des über zehn Jahre gewach­se­nen Subversion-Systems nach Git. Im Folgenden werde ich unser Migrationsvorgehen, die auf­ge­tre­te­nen Probleme und Lösungen beleuchten.

Über die Vorzüge eines DVCS gegen­über der zen­tra­len Variante wurde schon viel geschrie­ben. Im Internet fin­det sich eine Vielzahl an Information und Vergleichen zu bei­den Verfahren. Einen inter­es­san­ten Vortrag hielt Sven Peters auf dem Unite 2012 in Frankfurt. Ein – für uns sehr wich­ti­ger – Punkt hat aller­dings nichts mit der ver­wen­de­ten Technik zu tun: Wir woll­ten die interne Migration gleich­zei­tig 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 abge­steckt und Aufgaben erar­bei­tet. Hauptproblem war hier­bei, dass wir zu die­sem Zeitpunkt keine Möglichkeit zu einer vali­den Schätzung hat­ten. Wir kann­ten das Zielsystem noch nicht; kei­ner hatte den Überblick über alle Repositories im SVN; kei­ner wusste, wer über­haupt alles im SVN arbei­tet und spä­ter dann im neuen System arbei­ten sollte. Damit stand auch schon die erste Hauptaufgabe fest: Analyse des SVN.

Analyse SVN

Um die Nutzerstatistiken zu erstel­len, bemüh­ten 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 unse­rem Fall erga­ben sich für die vor­han­de­nen 22 SVN-Repositories eine Nutzerzahl von 93 Nutzern, die jemals einen Commit durch­ge­führt haben.

Es war natür­lich klar, dass diese 93 Nutzer nicht alle Zugriff auf das neue System brau­chen und auch teil­weise im SVN schon kei­nen Zugriff mehr haben. Da sind z.B. Kollegen, die inzwi­schen Team- oder Abteilungsleiter wur­den; Mitarbeiter, die in eine andere Abteilung gewech­selt haben bzw. kom­plett aus­ge­schie­de­nen sind; oder auch Schüler des SRZ, die eine Arbeit bei Communardo geschrie­ben haben. Wir limi­tier­ten den Nutzerkreis, indem wir nur Nutzer berück­sich­tig­ten, die in den letz­ten zwölf Monaten ein Commit durch­ge­führt haben gli­chen diese Nutzer mit dem Active Directory ab. Als rele­vante Personengruppe ermit­tel­ten wir gut 30 Accounts. Damit war Atlassian Stash gesetzt und wir konn­ten mit den eigent­li­chen Migrationsvorbereitungen starten.

Migrationsvorbereitungen

In der Vorbereitungsphase wur­den drei Themen par­al­lel ange­gan­gen: Zwei Kollegen began­nen mit dem Aufsetzen des Systems und der Testmigration von ver­schie­de­nen Repositories unter­schied­li­cher Komplexität. Ein Berechtigungskonzept wurde aus­ge­ar­bei­tet und aus jedem Team wurde ein Git-Ambassador gewählt.

Testmigrationen

Die Migration selbst haben wir mit dem SVN Mirror for Atlassian Stash Plugin durch­ge­führt und ver­lief pro­blem­los. Einzige Problematik waren lange Wartezeiten bei der Analyse von gro­ßen SVN-Repositories. Wir hat­ten bei uns einige Sammel-Repositories, die im Zuge der Migration auf­ge­löst wur­den. Neben der eigent­li­chen Migration wurde die Einbindung von Git in unsere Entwicklungs- und Buildumgebungen unter­sucht und eingerichtet.

Berechtigungen und Struktur

Um den Verwaltungsaufwand für das Stash mög­lichst gering zu hal­ten, haben wir uns für eine sehr fla­che Berechtigungsstruktur ent­schie­den. Die Rollen „Systemadministrator“ und „Administrator“ lie­gen bei unse­rer IT-Abteilung. Projekte kann jeder Stash-Nutzer anle­gen. Die Berechtigungen inner­halb eines Projektes wer­den durch einen Verantwortlichen selb­stän­dig ver­wal­tet. Herausforderungen stell­ten einer­seits NDA- ande­rer­seits Quelloffene-Projekte (z.B. das SubSpace Plugin) dar.

Da es abseh­bar war, dass sehr viele Projekte in Stash ent­ste­hen wür­den, zeigte sich unter ande­rem die nicht vor­han­dene Strukturierung als Problem. Im Rahmen eines Open Innovation Days wurde des­halb das Stash Categories Plugin entwickelt.

Git-Ambassador

Die Git-Ambassadors die­nen als erste Anlaufstelle bei Fragen rund um Git bzw. Stash und sind des­we­gen direkt in den Teams unter­ge­bracht. Im März erhielt jeder Ambassador eine vier­stün­dige Schulung, um sich mit dem neuen System ver­traut zu machen. Dies beinhal­tete neben Grundlagen zu Git, Branching- und Merging-Strategien auch Themen wie Repository-Organisation oder die Verwendung von Hooks.

Migration

Die eigent­li­che Migration wurde über einen län­ge­ren Zeitraum durch­ge­führt. Wir woll­ten einer­seits keine Kundenprojekte beein­flus­sen und den Wechsel mög­lichst geräusch­los über die Bühne brin­gen, ande­rer­seits waren natür­lich auch die Kollegen, die die Migration durch­führ­ten, in ihren Projekten eingebunden.

Nachdem wir aus­rei­chend Erfahrung durch Testmigrationen sam­meln konn­ten, wur­den zuerst die im SVN abge­schlos­se­nen und lange nicht ver­wen­de­ten Repositories in ein Stash-Projekt „SVN-Archive“ gescho­ben. Anschließend wur­den die Repositories – in enger Abstimmung mit den Nutzern – ein­zeln nach Stash umge­zo­gen und ggf. auf­ge­teilt. Die Teammitglieder erhiel­ten eine ein­stün­dige Schulung mit Grundlagen zur Arbeit mit Git bzw. Stash.

Fazit

Die Migration ist seit einem Monat abge­schlos­sen. Die SVN-Repositories sind gesperrt und wer­den bis Mitte 2014 noch lesend zur Verfügung ste­hen – anschlie­ßend wird der Server einer ande­ren Verwendung zuge­führt. Aus den 22 SVN-Repositories sind 96 Stash-Projekte mit ins­ge­samt 266 Repositories geworden.

Der Aufwand war deut­lich gerin­ger als im Vorfeld zu befürch­ten 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 hilf­reich erwiesen.