In der ersten Folge dieser Artikelserie haben wir darüber berichtet, warum wir uns dazu entschlossen haben, unsere Source Code Verwaltung von Subversion nach IBM Engineering Workflow Management zu migrieren, und was wir damit erreichen wollten. Wesentliche Gründe waren die Reduzierung des Aufwandes für den Nachweis sicherheitskritischer Eigenschaften bei unserem Produkt RXF-Cert. Zudem wollten wir für RXF und RXF-Cert eine durchgehende Traceability herstellen über Toolgrenzen, Projekte und Versionen hinweg. Falls Sie noch einmal nachlesen möchten, Teil 1 finden Sie hier.
Unsere Source Code Dateien und andere Artefakte von RXF und RXF-Cert waren in unterschiedlichen Repositories abgelegt:
ein Teil der Dateien wurde verwaltet in einem Subversion Repository, das variantenübergreifend angelegt war.
Die zugehörigen Dateien waren gespeichert in verschiedenen Windows-Ordnern, die mit den Varianten in Subversion verknüpft waren
Die Module, die von IBM EWM (Engineering Workflow Management) verwaltet wurden, lagen ebenfalls in diesen Windows-Ordnern.
Abbildung 1 veranschaulicht das Szenario.
Aus dieser Situation und den Abläufen, die sich in dieser Umgebung eingespielt hatten, ergeben sich für die Migration eine Reihe von Punkten, die zu beachten sind:
Die Datenmodelle von SVN und IBM EWM sind unterschiedlich
Skripte und andere Daten waren über svn:externals eingebunden, die nicht ohne Bearbeitung migriert werden können.
SVN-Befehle wurden an mehreren Punkten im Prozess genutzt, beispielsweise beim Vorbereiten der Entwicklungsumgebung für den Test einer Produktversion, für das Anstoßen von CI/CD Jobs oder für das Generieren von Release-Notes
Zudem gibt es keine Möglichkeit, die Change History aus SVN zu übertragen nach EWM.
Aus diesen rein praktischen Anpassungen, die mit der Migration zu EWM erforderlich sind, ergeben sich natürlich auch Änderungen in den Prozessen und Arbeitsabläufen, die Akzeptanz und aktive Unterstützung durch die Team-Mitglieder voraussetzen.
Diese externen Verknüpfungen führten zu Abhängigkeiten zwischen unterschiedlichen Projekten und mussten individuell aufgelöst und ersetzt werden. Dazu haben wir zunächst alle svn:externals ermittelt und einzeln für jede Datei geprüft, ob verschieben oder kopieren erforderlich ist.
Unsere Präferenz war es, möglichst viele dieser Dateien in einen Ordner zu verschieben, der von unterschiedlichen Projekten referenziert werden kann. Das war möglich bei etwa 90% dieser Dateien. Bei einem kleinen Anteil von ca. 10% mussten wir die Datei kopieren und die Kopien im jeweiligen Repository ablegen.
Im nächsten Schritt konnten wir dann unsere “SVN verwalteten” Daten sauber trennen von unseren “EWM verwalteten” Daten. Dabei legten wir großen Wert auf klare Strukturen mit einer sauberen Trennung der Dateien. So konnten wir Redundanzen reduzieren und eine brauchbare Basis für die eigentliche Migration schaffen.
Um die Risiken zu minimieren, haben wir die Migration von SVN nach EWM schrittweise durchgeführt. Zunächst haben wir eine Kopie der Daten nach EWM migriert, um sicherzustellen, dass die neuen Prozesse in der Zielumgebung ohne SVN genau so funktionieren, wie wir es für unsere Entwicklungsprojekte brauchen. Nachdem das erreicht war, haben wir die Produktiv-Daten schrittweise in sorgsam ausgewählten Teilmengen migriert. Dabei war die kontinuierliche enge Abstimmung mit den Entwicklungsteams besonders wichtig für den Erfolg des Migrationsprojektes und die Akzeptanz der neuen Umgebung.
Dank sorgfältiger Planung konnten wir die SVN Repositories vollständig in unsere IBM EWM Umgebung migrieren und unser wichtiges Ziel der durchgängigen Traceability, auch zwischen Anforderungen und Modellelementen erreichen. In der kommenden letzten Folge dieser Artikelserie werden wir unsere neue Umgebung vorstellen und betrachten, was wir bei diesem Projekt gelernt haben. Außerdem werden wir über unsere Erfahrungen mit der Produktentwicklung im Kontext der neuen Source Code Verwaltung berichten.