Lohnenswertes Invest: Migration von ClearCase zu Git

Ich spreche dann von Migration, wenn ich ein bestehendes Werkzeug durch ein neues austauschen möchte. Das heißt ich migriere nicht nur Daten, sondern ich ändere zudem Workflows, Tools und weitere Elemente. Am Ende geht es um die komplette Ablösung eines vorhandenen Systems, das aus verschiedenen Gründen abgeschaltet wird.

Beides sind Versionskontrollsysteme. Dabei ist ClearCase schon sehr lange auf dem Markt. Demgegenüber hat sich Git mit einem schlankeren und moderneren Ansatz etabliert. Von daher ergibt eine Migration für viele Organisationen einen Sinn.

Ganz klar. Eine zentrale Motivation für eine solche Migration stellen die Kosten beziehungsweise deren Einsparung dar. Bei ClearCase fallen je nach Modell relativ hohe Lizenzkosten an. Das sind Ausgaben, die eingespart werden sollen. Dafür bietet sich Git als Alternative an. Git ist nämlich Open Source. Die meisten Git-Tools, die von Entwicklerseite eingesetzt werden, sind entsprechend kostenlos.

ClearCase ist bereits sehr lange auf dem Markt, wird aber nicht mehr weiterentwickelt. Aktualisierungen and Anpassungen an moderne Systeme werden somit nicht mehr umgesetzt.

Weiterhin sind die Konzepte unterschiedlich. Wer mit ClearCase arbeitet, ist immer von einer Netzwerkverbindung zu einem zentralen System abhängig. Bei großen, verteilten Teams entsteht automatisch ein erheblicher Aufwand, die notwendigen Verteilsysteme einzurichten.

Git dagegen setzt auf ein dezentrales System. Das bedeutet weniger Aufwand in Bezug auf Netzwerk, Performance et cetera. Zusätzlich habe ich mehr Möglichkeiten, neue ALM- oder DevOps-Tools einzubinden.

Prinzipiell steigt die Qualität der Softwareentwicklung, indem ich Dinge wie Continous Integration oder Continous Deployment mit einbringen kann. Dann kann ich mit Hilfe verschiedener Tools noch automatisierte Tests oder teilautomatisierte Review-Prozesse anstoßen. Aber auch darüber hinaus gibt es viel Optimierungspotenzial, welches im Rahmen einer Migration abgerufen werden kann.

Und: Bei der Softwareentwicklung ist das ein wenig wie bei einem Keller. Nach einer gewissen Zeit weiß ich gar nicht mehr, was alles drin ist. Von daher bietet eine Migration die Gelegenheit, sich einen Überblick zu verschaffen und aufzuräumen. Was will, kann und muss ich überhaupt bei meinem Migrationsvorhaben berücksichtigen?

Als ersten Punkt muss ich ganz klar das Festhalten an alteingesessenen Strukturen nennen. Das ist typisch, wenn es um Versionskontrollsysteme geht. Wenn ich Software habe, die lange am Markt ist, ist das Versionskontrollsystem meist ebenfalls schon lange im Einsatz. 20 Jahre Laufzeit sind nicht selten. Da ist es keine Überraschung, dass es Altlasten gibt und die Mitarbeitenden eine gewisse Betriebsblindheit entwickelt haben.

Was wir in Konsequenz oft feststellen, ist eine falsche Sichtweise des Kunden auf die Migration an sich. Es gibt klare Ziele: Man will Kosten sparen, schlanker werden, komponentenbasiert arbeiten und vieles mehr. Schließlich geht es in Summe um eine höhere Softwarequalität. 

Dementsprechend darf ich den Weg dorthin nicht als Aufwand betrachten, sondern als Invest. Das ist für mich ein wichtiger Punkt und viele sehen darin nur den Kostenpunkt. Ich glaube, hier ist eine andere Denkweise gefragt. Das ist nicht nur eine reine Ausgabe, um die Migration zu bezahlen. Das ist eine Investition, die sich im Nachgang ganz schnell wieder amortisiert. 

Häufig besteht eine falsche Einschätzung von dem, was man eigentlich migrieren möchte. Da werden die Prioritäten falsch definiert. Wir unterscheiden zum Beispiel zwischen aktiven Nutzdaten, historischen Nutzdaten und Metadaten. Nutzen und Aufwand müssen hier betrachtet werden, damit die Migration nicht zu einer Dauerbaustelle wird.

Eine weitere Fehlerquelle ist das Bestreben, die bestehenden Funktionalitäten des alten Tools auf das neue zu übertragen. Das ist natürlich nicht der richtige Weg. Ich kann keinen Schraubendreher so lange verbiegen, bis ich einen notdürftigen Hammer habe. Sondern ich nehme natürlich direkt einen Hammer. Darauf muss ich mich aber einlassen.

Die Entscheidungskompetenz muss klar geregelt sein. Die sollte bei einem definierten Team liegen, dass notwendige Entscheidungen treffen sowie verantworten kann. Sonst kommt es schnell zu viel Diskussionsbedarf.

Sobald mehrere Projekte migriert werden, sollte jedes Projekt einen Experten in das Migrationsteam einbringen, der die Interessen und Anforderungen des jeweiligen Projekts klar definieren kann. Dieses interne Expertenwissen kann von Consultants kaum geleistet werden.