Eine Spring-Boot-Anwendung migrieren

Eine Spring-Boot-Anwendung migrieren

0:00 Jetzt läuft alles zusammen. In den letzten sechzehn Modulen haben wir jede Schicht einzeln betrachtet — hier fügen wir sie zu einem Vorgehen zusammen. Und der wichtigste Satz steht gleich am Anfang: Eine Migration ist keine Übersetzung. Sie ist eine Folge kleiner Stände, von denen jeder lauffähig und geprüft ist. Wer sie als großen Umbau plant, bei dem am Ende alles gleichzeitig funktionieren soll, plant ein Projekt ohne Zwischenerfolge — und ohne Rückweg.

Eine Spring-Boot-Anwendung migrieren

0:27 Vorletztes Modul. Wir nehmen den Bestand auf, stellen schichtweise um und weisen am Ende nach, dass dasselbe herauskommt. Alles, was wir dafür brauchen, haben Sie bereits: die Landkarte aus Modul zwei, die Testsuite aus Modul neun, die Zusicherungsliste aus Modul elf und die Messreihen aus den Modulen vierzehn bis sechzehn.

Bestand inventarisieren

0:47 Beginnen wir mit der Inventur. Sie klingt nach Bürokratie und ist in Wahrheit die Risikoanalyse dieses Projekts. Die Inventur beantwortet drei Fragen: Welche Abhängigkeiten bringt die Anwendung mit? Welche davon haben ein Quarkus-Gegenstück? Und wo verlässt sich der Code auf Mechanismen, die das Build-Modell nicht kennt?

1:06 Die dritte Frage ist die entscheidende, denn sie findet die Dinge, die sich nicht durch Fleiß lösen lassen. Das Bild: Vor einem Umzug interessiert weniger, wie viele Kisten Sie haben, als ob das Klavier durchs Treppenhaus passt. Und diese dritte Frage lässt sich nicht durch mehr Personen beantworten, sondern nur durch genaues Hinsehen — deshalb gehört die Inventur an den Anfang und nicht in die Mitte des Projekts.

1:29 Fünf Schritte, und die Fußnote enthält den wichtigsten Hinweis: Der Abhängigkeitsbaum zählt, nicht die Build-Datei. Die Blocker stecken fast immer transitiv drin — über einen internen Firmenstarter, über eine Bibliothek, die eine andere mitbringt. Die Schritte drei bis fünf sind Suchaufträge im Code: Auto-Configurations, Zugriffe auf den Application Context, reflektive Registrierung. Nehmen Sie sich dafür einen halben Tag.

1:54 Das ist der günstigste halbe Tag im ganzen Projekt, weil er die Schätzung auf Fakten stellt. Vier Kategorien, und die letzte ist die ehrlichste: offen. Was noch nicht geprüft ist, gehört nicht in einen der drei anderen Körbe, nur weil es plausibel aussieht. Der erste Korb ist erfreulich, der zweite ist der Arbeitskorb für die erste Stufe.

2:14 Der dritte, die Blocker, entscheidet über Machbarkeit und Aufwand — und über den Zeitpunkt, an dem man ehrlicherweise noch abbrechen kann. Wichtig: Ein Blocker ist kein Urteil über die Bibliothek, sondern eine Aussage über die Kombination aus ihr und dem Build-Modell. Der erste Punkt ist der schon genannte: Die Liste entsteht aus der Build-Datei statt aus dem Abhängigkeitsbaum.

2:37 Der zweite ist der teuerste im ganzen Projekt: Ein Blocker wird entdeckt, wenn die halbe Migration steht — dann sind Sie in der schlechtesten aller Positionen, weil weder Umkehren noch Weitermachen billig ist. Der dritte betrifft interne Firmenstarter, die niemand mehr im Blick hat. Und der vierte ist Optimismus im falschen Moment: Der Umfang wird geschätzt, bevor die Inventur fertig ist — und diese Schätzung bleibt danach hängen.

Schichtweise umstellen

3:01 Kommen wir zum Vorgehen selbst. Zwei Stufen, klare Reihenfolge — und nach jedem Schritt ein Stand, der läuft. Die Migration läuft in zwei Stufen. Zuerst kompatibilitätsorientiert, mit den Spring-Erweiterungen, die wir in den Modulen vier, fünf und sieben kennengelernt haben. Dann Quarkus-nativ, mit CDI, Jakarta REST, Panache, Quarkus Security und den MicroProfile-APIs.

3:25 Der Sinn dieser Zweiteilung: In Stufe eins beantworten Sie eine einzige Frage — läuft die Anwendung überhaupt auf dieser Plattform? Erst wenn diese Frage geklärt ist, lohnt sich die Arbeit an der Eleganz. Das Bild: Sie ziehen erst mit den alten Möbeln ein und prüfen, ob Wasser, Strom und Heizung funktionieren. Erst danach kaufen Sie neue Möbel — nicht umgekehrt.

3:49 Vier Stationen, und die Reihenfolge ist nicht beliebig. Ohne Konfiguration startet nichts, also steht sie am Anfang. Die Persistenz bestimmt die Datenzugriffe aller darüberliegenden Schichten. Die REST-Schicht lässt sich gegen den bestehenden Vertrag prüfen — das ist der erste Punkt, an dem Sie einen echten Nachweis bekommen.

4:08 Und Security und Messaging kommen zuletzt, weil sie fremde Systeme berühren und damit Abstimmung brauchen. Diese Reihenfolge maximiert die Zahl der Zwischenstände, an denen Sie etwas vorzeigen können. Die vier Begründungen im Einzelnen. Konfiguration zuerst, weil sie Voraussetzung für alles ist. Persistenz vor REST, weil die Endpunkte auf den Daten aufsetzen und nicht umgekehrt.

4:30 REST an dritter Stelle, weil dort der Vertrag liegt, gegen den Sie prüfen können — hier bekommt das Projekt seinen ersten belastbaren Zwischenerfolg. Und Security und Messaging zum Schluss, weil sie Abstimmung mit anderen Teams und mit dem Betrieb brauchen. Diese Abstimmung dauert, und sie sollte nicht das Vorankommen der ersten Schichten blockieren.

4:51 Der erste Punkt ist der häufigste Ablaufffehler: An mehreren Schichten gleichzeitig zu arbeiten führt dazu, dass nichts mehr läuft und niemand weiß, woran es liegt. Der zweite ist die übersprungene Kompatibilitätsstufe — alle Fehler treten gemeinsam auf. Der dritte ist ein Trugschluss: Zwischenstände bleiben ungetestet, weil sie ohnehin bald ersetzt werden; genau deshalb fehlt später der Beleg, wann ein Fehler entstanden ist.

5:15 Und der vierte ist ein Organisationsproblem, das jede Migration bedroht: Der Ausgangsstand wird weiterentwickelt, während migriert wird.

Verhalten und Ressourcen nachweisen

5:24 Und jetzt zum Nachweis. Denn fertig ist eine Migration nicht, wenn sie läuft, sondern wenn belegt ist, dass sie dasselbe tut. Ein Contract Test prüft, ob zwei Implementierungen denselben Vertrag erfüllen: gleiche Anfragen, gleiche Statuscodes, gleiche Antwortkörper, gleiche Fehlerformate. Das ist etwas anderes als ein Test, der prüft, ob die neue Variante korrekt arbeitet — es ist ein Vergleich, kein Urteil.

5:49 Und genau deshalb ist er für eine Migration das richtige Werkzeug: Er ersetzt die Meinung, dass alles noch funktioniert, durch einen Nachweis, den auch jemand akzeptiert, der dem Projekt skeptisch gegenübersteht. Diese sechs Zeilen sind die Abnahmeliste für Ihre Migration, und ich empfehle, sie genauso in das Repository zu legen.

6:09 Fachliches Verhalten, API-Vertrag, Fehlerfälle, Security, Messaging, Ressourcen — jede Zeile mit einem konkreten Nachweis. Beachten Sie, dass fünf der sechs Zeilen aus früheren Modulen stammen; Sie haben die Arbeit also größtenteils schon getan. Und die Fußnote nennt die Konsequenz: Erst wenn jede Zeile abgehakt ist, wird der alte Dienst abgeschaltet. Vorher ist er Ihre Rückfallebene.

6:34 Der erste Punkt ist der gefährlichste: Der alte Dienst wird abgeschaltet, bevor der Vergleich vollständig ist — meist aus Ressourcengründen oder weil es sich fertig anfühlt. Der zweite entzieht der ganzen Migration ihre Begründung: Die Ressourcenmessung entfällt, und damit ist unbelegt, ob der Grund für die Migration eingetreten ist.

6:52 Der dritte ist ein Denkfehler: Contract Tests nur gegen die neue Variante zu fahren, beweist nichts über Gleichheit. Und der vierte ist banal und folgenreich: Die Abnahmeliste steht in einem Chat statt im Repository — und ist nach dem Projekt verschwunden.

Übung

7:07 In der Übung führen Sie die Migration von Pfandkreis zu Ende — mit allem, was wir in den letzten zwei Tagen vorbereitet haben. Der Hinweis auf dieser Folie fasst das Seminar zusammen: Die Charakterisierungstests aus Modul neun und die Zusicherungsliste aus Modul elf sind hier Ihre Prüfmittel. Sie haben also nicht nur Code geschrieben, sondern Werkzeuge gebaut.

7:28 Erfolgreich sind Sie, wenn beide Quarkus-Varianten die Abnahmeliste bestehen und ein Vergleich vorliegt: Codeänderungen, Testaufwand, Startzeit, Speicherbedarf — jeweils gegenüber dem Ausgangsstand. Erfolgreich sind Sie, wenn beide Quarkus-Varianten die Abnahmeliste bestehen und ein Vergleich vorliegt: Codeänderungen, Testaufwand, Startzeit und Speicherbedarf gegenüber dem Ausgangsstand.

7:49 Und halten Sie nach jedem Schritt einen lauffähigen Stand — das ist die eigentliche Disziplin dieser Übung. Beachten Sie besonders den zweiten Schritt: Stufe eins ist erst fertig, wenn die Tests grün sind — nicht, wenn die Anwendung startet. Erst dann beginnt Stufe zwei. Und schreiben Sie im fünften Schritt den Aufwand mit, und zwar während Sie arbeiten, nicht hinterher. Nur so lässt sich später auf die anderen Dienste hochrechnen.

8:15 Die Fußnote nennt den Zweck des Ganzen: Das Ergebnis trägt die Go-, Pause- oder Stop-Entscheidung im letzten Modul. Der erste Punkt ist die Ungeduld, die jede zweistufige Migration bedroht: Stufe zwei beginnt, bevor Stufe eins vollständig grün ist. Der zweite verhindert jede Hochrechnung: Der Aufwand wird nicht mitgeschrieben.

8:34 Der dritte ist der klassische Projektfehler, den man in keiner Migration vermeiden kann, sondern nur benennen: Fachliche Änderungen schleichen sich ein, und hinterher weiß niemand, ob ein Unterschied im Verhalten von der Migration kommt oder von der neuen Funktion. Und der vierte ist der, der ein Projekt unumkehrbar macht: Es gibt keinen definierten Rückweg, wenn ein Schritt scheitert.