Migration von SVN nach Git

Die Migration von SVN zu Git bereitet vielen Teams immer noch Kopfzerbrechen. Eigentlich ist die Sache ganz einfach! Das Repository mit allem drum und dran in Git importieren und fertig. So würde es sicher gut funktionieren, wenn man in der "heilen Welt" lebt und alle Entwickler und Tools ohne Verzögerung mit Git starten könnten.

In der Realität sieht es jedoch oft etwas anders aus. Das bei weitem Wichtigste sind hierbei die Entwickler und der Erhalt einer reibungslosen Lieferfähigkeit. Oft kennen sich nur einige wenige im Umgang mit Git schon gut aus. Die meisten haben jedoch nur sehr wenig Erfahrung und eventuell nur einmal etwas von Git gehört. Außerdem gibt es hier und da Entwickler die (um es einmal etwas politisch auszudrücken) eher konservativ neuen Entwicklungen gegenüber stehen. Die nächste große "Problemgruppe" stellen manche Tools dar. Gemeint sind hiermit Tools, welche helfen sollen einen gewissen Grad an Automatisierung in den Prozess der Softwareentwicklung zu bringen. Hier gibt es häufig ebenfalls Bedarf zu modernisieren. Im Falle von Jenkins Testjobs hat man wohl noch die besten Karten diese Änderungen recht zügig zu implementieren.

Es gibt also viele Situationen in denen ein sogenannter "Big Bang" - also ein Umstieg über Nacht nicht sehr sinnvoll ist.

Die Alternative dazu ist, bei der Umstellung schrittweise vorzugehen und mit einem möglichst kleinen Teil des Teams anzufangen. Eine bidirektionale Synchronisierung sorgt dafür, dass mit beiden Repositories gleichzeitig gearbeitet werden kann. Wenn dies gelingt, nimmt man sofort die Spannung aus diversen Diskussionen und kann den Umstellungsprozess beliebig dehnen. Im Extremfall werden nur ein oder zwei Entwickler umgestellt und arbeiten erstmal mit einem entsprechenden einfachen - an Git angepassten - Workflow. Diesen beiden Entwicklern sollte man in etwa vier Wochen Zeit geben um Erfahrung zu sammeln und aus ihren Fehlern zu lernen. Haben die ersten Entwickler genügend Erfahrung, können nach und nach andere Entwickler folgen. Die ersten Entwickler können hier wichtigen Support leisten und quasi "viral" das Know-how weitergeben.

Es gibt unserer Meinung nach keinen Grund, weshalb man sich nicht die Zeit nehmen sollte. Im Gegenteil! Die Entwickler sind motivierter und durch den Support der "Piloten" sammeln sich eine Menge an sehr tiefen Kenntnissen im Team. Später auftretenden Probleme werden dann meist mit großem Enthusiasmus gelöst. In der gewonnenen Zeit können die Entwickler schrittweise in kleinen Workshops geschult werden. Wir empfehlen dazu einen umfassenderen Grundlagen Workshop und danach periodisch zweimal wöchentlich einen kurzen Workshop von maximal 45 Minuten. Für den Grundlagen Workshop sollte eventuell ein externen Trainer engagiert werden. Die weiteren Workshops könnten dann bereits von den nun schon Erfahrenen geleitet werden.

Die einzige Frage, welche sich jetzt noch stellt ist: Wie bekomme ich eine funktionierende bidirektionale Synchronisation zwischen SVN und Git?

Im Laufe der Zeit haben wir ein Tool entwickelt, was sich eben dieser Aufgabe annimmt. Es arbeitet nach dem Prinzip, dass ein beliebiger Branch aus SVN mit dem Master Branch eines Git Repositories synchronisiert wird. Dies erfolgt im Abstand von 10 Minuten (kann konfiguriert werden) völlig automatisch und war bei seinem letzten Einsatz fast zwei Jahre ohne nennenswerte Probleme im Einsatz und wurde dabei noch ein wenig weiter entwickelt. Eine spartanische Weboberfläche diehnt dabei sich den jeweiligen Status anzuschauen oder die Synchronisation auszusetzen. Sollte ein Problem aufgetaucht sein kann man in den sehr ausführlichen Logdateien nachsehen, was das Problem gewesen ist. Im Falle eines Problemes stoppt die Synchronisation automatisch und informiert darüber per Mail.

Wo können wir dabei helfen?

Bestandsaufnahme

Im Rahmen einer Bestandsaufnahme analysieren wir die aktuelle Situation. Um einen reibungslosen Übergang nach GIT zu schaffen, ist dies einer der wichtigsten Punkte. Bei der Bestandsaufnahme werden Fragen nach Benutzern und Teams/Gruppen aufgeworfen und beantwortet sondern auch die bestehenden Abhängigkeiten in der Lieferkette untersucht. Welche Systemen sind bei einem Übergang betroffen? Bevor die Umstellung in der heißen Phase läuft, sollte allen Beteiligten klar sein, wie man auf eventuell auftretende Schwierigkeiten reagieren kann. Dies stellt sicher, dass der Stressfaktor nur eine untergeordnete Rolle spielt und man sich voll auf die kommenden Fragen der Developer und Operater konzentrieren kann.

Grundlagenschulung

Da sich die Arbeitsweise einer dezentralen Versionsverwaltung grundsätzlich von der einer zentralen unterscheidet gibt es natürlich eine ganze Menge zu lernen. Ziel der Grundlagenschulung ist es den Benutzers zu zeigen wie sie die ersten Schritte in der neuen Welt gehen können und welche Möglichkeiten es gibt eventuelle Fehler wieder auszubügeln. Dies soll vor allem Vertrauen schaffen und Berührungsängste abbauen. Ist diese Hürde genommen, können die vielen Features gefahrlos auf eigene Faust erkundet werden. Das weckt dann noch mehr Interesse und schafft in den meisten Fällen sehr schnell eine positive Einstellung gegenüber dem neuen System. 

In der Grundlagenschulung werden aber auch die theoretischen Grundlagen nicht zu kurz kommen. Diese helfen, die Funktionsweise zu verstehen und eigene Strategien zu entwickeln. Darüber hinaus werden auch Themen wie mögliche Branchlayouts und Arbeitsweisen besprochen.

Vorschläge zur schrittweisen Migration

Nach einer Bestandsaufnahme und Nachbesprechung werden wir detailierte Vorschläge zu einer schrittweisen Migration machen. Diese können dann Punkt für Punkt abgearbeitet werden. Neue Erkenntnisse können bei der Migration weiterer Repositories berücksichtigt werden. Ähnlich der agilen Vorgehensweise bei der Softwareentwicklung, tragen diese neuen Erkenntnisse dazu bei den Prozess stetig zu verbessern.

Synchronisations-Tool zur freien Verwendung auf GitHub verfügbar

Bei den bereits erfolgreich unterstützten Migrationen haben wir nicht nur viel Erfahrung gewonnen, sondern haben diese Erfahrungen auch zu Code werden lassen. Daraus ist ein stabiles Tool entstanden, welches für die schrittweise Migration eingesetzt werden kann. Dieses Tool ist ein im Hintergrund arbeitender Service, der eine bidirektionale Synchronisation zwischen SVN und Git bietet. Das Tool haben wir gern auf Github der Community bereit gestellt und werden es auch weiterhin pflegen. Hier ist der Link zum Synchronisations-Tool auf GitHub

Schulung/ Coaching der Benutzer

Bei unseren Schulungen behandeln wir Themen, welche etwas mehr in die Tiefe gehen und nicht ganz alltägliche Bereiche beleuchten. Hier kommt zum Beispiel eine vollautomatische Suche nach einem Commit ins Spiel, welcher einen Fehler eingeführt hatte. Dabei spielt man Zeitmaschine mit Git und implementiert einen Unittest in der Vergangenheit. Die Schulung kann parallel zur Einführung statt finden

Schrittweise Benutzer für Benutzer nach Git wechseln lassen (Freiwillige zuerst ;-)

Es gibt viele gute Gründe, sich mit der Umstellung auf ein neues Versionsverwaltungssystem die dafür nötige Zeit zu nehmen. Die Möglichkeiten dies zu tun hängen natürlich von den individuellen Bestandssystemen ab.

Nachbetreuung

Sollte es einmal nötig sein, sind wir für Sie da. Wir bieten schnelle und kompetente Hilfe. Im Falle eines Falles, sind wir für Sie da und können selbst per Fernzugriff die meisten Probleme beheben.