ClearCase zu Git: Erste Schritte zur gelungenen Migration

Der erste Schritt sollte immer aus einer Bestandsaufnahme bestehen. Wenn es unterschiedliche Projekte innerhalb einer Produktlandschaft gibt, lautet die zentrale Frage: Arbeiten diese Projekte alle gleich? Sind beispielsweise die Configuration Management Pläne gleich? Merke ich, dass es gravierende Unterschiede gibt, muss ich die Projekte einzeln betrachten.

Es hat sich gezeigt, dass wir bereits an diesem Punkt wertvolle Unterstützung geben können. Indem wir eine Bestandsaufnahme betreiben, stellen die Kunden oft fest, welche Tools und Prozesse sie überhaupt im Einsatz haben. Wenn da ein klares Bild entsteht, ist schon viel gewonnen. Im Anschluss kann ich die Migrationsvorbereitungen so gestalten, dass für den weiteren Verlauf alles glattgezogen ist.

Die Zielsetzung ergibt sich in großen Teilen aus der Bestandsaufnahme. Prinzipiell haben unsere Kunden ein starkes Interesse daran, eine homogene Entwicklungsumgebung zu schaffen. Diese Zielsetzung muss in vielen Belangen richtig definiert sein. Wir erleben immer wieder das Bestreben, die bestehende Umgebung mit den neuen Werkzeugen abzubilden. Das ist aber nicht die richtige Vorgehensweise.

Wenn ich den Doppelwumms vollziehe, setze ich von heute auf morgen auf das neue System. Das kann ich so machen. Es handelt sich dabei allerdings um einen sehr großen Schritt. Für viele Beteiligte ist das schwer umzusetzen. Wir versuchen dagegen alles im alten System so vorzubereiten, dass der Übergang in vielen kleinen, reproduzierbaren Schritten stattfindet.

Dadurch lassen sich die Workflows bis zu dem Übergang ein ganzes Stück anpassen. Dazu kann ich schrittweise entsprechende Schulungen in die Wege leiten. Wobei ich sagen muss, dass die technische Umsetzung einer Migration für viele Softwareentwickler meistens nicht das Problem ist. Vielmehr ist das eine kulturelle Veränderung, die in den Köpfen ebenfalls ankommen muss. Das geht über Workflows bis hin zu Begrifflichkeiten. Ich nenne ein Beispiel: Bei ClearCase werden Kommandos verwendet, die sich auch bei Git wiederfinden. Schwierig daran ist, dass sie inhaltlich unterschiedlich besetzt sind. Das gilt zum Beispiel für „Checkout“. Wenn damit 20 Jahre lang etwas Spezifisches verbunden worden ist, findet bei den Entwicklern keine automatische Ablösung statt. Das ist nachvollziehbar.

Bei kleineren Schritten lassen sich zudem die Ausfallzeiten minimieren. Kein Kunde will und kann es sich leisten, dass die Entwicklung aufgrund von Datenübernahmen blockiert oder gar Releases verschoben werden müssen. Indem wir beispielsweise eine Art Parallelhaltung und Deltamigrationen umsetzen, halten wir diese Ausfallzeiten so gering wie möglich. Der eigentliche Umstieg erfolgt dann am Wochenende, so dass die Entwickler am Freitag mit ClearCase abschließen und am Montag dann mit Git starten.

Das geschieht logischerweise anhand verschiedener messbarer Größen. Wir haben jetzt zum Beispiel ein Projekt mit sehr vielen Daten. Das Anlegen der notwendigen Arbeitsumgebung dauert mit ClearCase mehrere Stunden. Derselbe Vorgang lässt sich mit Git in ein paar Minuten erledigen. Das haben wir vorab als einen Effekt der Migration beschrieben. Da bestätigt die Praxis unsere Prognose

Es hat sich gezeigt, dass die Projektleitung allein oft nicht ausreichend dafür ist, da sie zu weit weg von der Praxis ist. Da hilft es wenig, wenn die Leitung eine allgemeingültige Entscheidung über das Konzept in Stein meißelt. Das kann nämlich auf die Füße fallen. Spätestens dann, wenn die Entwickler testen und rückmelden, dass sie schon seit geraumer Zeit eine ganz andere Arbeitsweise pflegen. Wir selbst haben diesen Fall schon in Projekten erlebt.

Vor diesem Hintergrund geben wir eine ausdrückliche Empfehlung: Wir müssen die Leute an den Tisch bekommen, die tagtäglich mit dem Tool arbeiten. Das sind die Entwickler. Mit ihrer Unterstützung können wir die Migration so vorbereiten, dass einer erfolgreichen Umsetzung nichts im Wege steht.