Testgetriebene Datenmigration

Um die Ausführung der Migration zu automatisieren, setzten wir auf den Open Source Continuous Integration Server Hudson [6] und insbesondere auf das Parameterized Trigger Plug-in [7], mit dem wir sehr elegant alle Schritte einer Migration als Pipeline abbilden konnten, die jede Nacht automatisch durchlaufen wurde. Abbildung 4 gibt eine Übersicht der wesentlichen Hudson-Jobs. Durch die Möglichkeit, Build-Artefakte wie CSV-Dateien mit dem aktuellen Migrationsstatus zu archivieren, konnten wir sehr leicht wesentliche Trendlinien des Projekts aufzeichnen.

Abb. 4: Hudson als-Continuous-Integration System erlaubte eine einfache Ausführung von Testmigrationen Abb. 4: Hudson als-Continuous-Integration System erlaubte eine einfache Ausführung von Testmigrationen (Vergrößern)

Agile Prozesse

Ein klassisches Vorgehensmodell à la Wasserfall schied im Projekt von Anfang an aus, da die wesentlichen Requirements sehr unklar waren und nicht zu Beginn sinnvoll geplant werden konnten. Erst im Verlauf des Projekts stellte sich sukzessive heraus, welche Migrationsteile spezielle Behandlung verdienten – immer dann, wenn der erste Ansatz im Migrationscode nicht funktionierte und auf Fehler lief, konnten Experten aus den Fachbereichen dabei helfen, die Spezifika einer neuen Variante exakt zu definieren, sodass diese umgesetzt werden konnten.

Die Entwicklung erfolgte nach Scrum und fand in 14-tägigen Iterationen statt. Ein ständig gepflegtes Product Backlog fasste die aktuellen Erkenntnisse aus vorangegangenen und gerade bearbeiteten Migrationen zusammen und war sowohl in der Kommunikation innerhalb des Entwicklungsteams als auch zur Abstimmung mit den Fachbereichen sehr hilfreich. Die iterativ-inkrementelle Vorgehensweise erlaubte einen sukzessiven Produktivgang. Nach Auftragsarten gruppiert, konnten wir durch einen Produktivgang von Teilen des Zielsystems sukzessive höchst wertvolle Erfahrungen im Umgang mit den technischen Systemen, vor allem aber in der Gestaltung der Arbeitsprozesse mit den Fachbereichen gewinnen.

Durch eine tagesaktuelle Auswertung des oben beschriebenen Migrations-Logs konnten wir frühzeitig Probleme der Datenqualität des Quellsystems erkennen. Durch recht einfache SQL-Abfragen konnten wir teils umfangreiche Excel-Listen erstellen, die zur Bereinigung an Mitarbeiter der Fachbereiche gegeben wurden. Diese konnten daraufhin im Quellsystem manuell problematische Daten gerade ziehen und hatten am nächsten Morgen durch eine erneute SQL-Abfrage schnelles Feedback, ob ihre Arbeit erfolgreich war und an welchen Stellen eventuell nachgebessert werden musste.

Natürlich waren nicht alle zunächst als problematisch erkannten Stellen faktisch fehlerhaft, die Auswertungen dienten uns auch zur inkrementellen Verbesserung des Migrationscodes. Zudem erlaubten sie eine Migration mit kontrolliertem Risiko – manche aus technischer Sicht fehlerhafte Datensätze konnten aus fachlicher Sicht akzeptabel sein und damit den Aufwand für die Migrationserstellung reduzieren.

Lessons Learned

Wir haben mit dem Projekt das Unternehmen mehr oder weniger überfahren. Gerade in der Endphase vor Produktivgängen war es für viele beteiligte Menschen eine hohe Belastung, teilweise über die Schmerzgrenze hinaus. Eine frühzeitigere intensive Einbindung von Mitarbeitern der Fachbereiche in die Projektorganisation sollte bei ähnlichen Projekten dafür genutzt werden, das gesamte Unternehmen über den erwarteten enormen Arbeitsumfang frühzeitiger zu informieren und so die Überlastung zu minimieren. Das agile Vorgehen in Verbindung mit einer weitgehend automatisierten Build- und Deployment-Struktur erwies sich als sehr hilfreich, um mit den sich ständig ändernden Anforderungen und den permanenten neuen Erkenntnissen umzugehen. Aus unserer Sicht wäre das Projekt bei einer Up-Front-Analyse schon deshalb zum Scheitern verurteilt gewesen, weil zahlreiche Besonderheiten des Quellsystems schlicht in Vergessenheit geraten waren. Insgesamt kann dieses Projekt als großer Erfolg gewertet werden, da:

  • das System im laufenden Betrieb abgelöst wurde
  • die Zielplattform an Funktionsreife massiv gewonnen hat
  • die Migration des Nürnberger Software Stacks dadurch erst ermöglicht wurde, derzeit läuft das entsprechende Projekt mit einem ähnlichen Vorgehensmodell
  • unsere Fachbereiche massiv am Projekt beteiligt wurden, und dies trotz oder gerade wegen der hohen zeitlichen und qualitativen Anforderungen des Projekts auch zu schätzen wussten
  • Scrum und Testautomatisierung als Erfolgsmodell mittlerweile unumstritten sind

Wir haben somit einen gewaltigen Schritt in Richtung einer gemeinschaftlich getragenen Handlungs- und Beteiligungskultur geschaffen. Die Akzeptanz für agile Methoden, insbesondere Scrum, ist als Ergebnis des Projekts mittlerweile im gesamten Unternehmen vorhanden.

Martin Wagner ist Principal Consultant bei der TNG Technology Consulting GmbH und vor allem in Projekten im Java-Umfeld tätig. Er hat an der TU München über verteilte Systeme zur Ortsbestimmung promoviert. Er war Leiter und Scrum Master des hier beschriebenen Projekts.
Thomas Scherm ist seit März 2009 Leiter IT der M-net Telekommunikations GmbH. Zuvor war er viele Jahre als Entwickler, Softwarearchitekt, Berater, Projektleiter und Produktmanager in einer großen Zahl nationaler und internationaler IT-Projekte mit überwiegendem ERP-Fokus tätig.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.