Warum wir Code- und Datenbankmigration bei TYPO3-Upgrades konsequent trennen

Im ersten Moment klingt diese Aussage fast widersprüchlich.

Natürlich muss jede TYPO3-Installation den offiziellen Upgrade-Pfad durchlaufen. Die Datenbankmigrationen, Upgrade Wizards und Breaking Changes existieren aus gutem Grund. Niemand sollte versuchen, diese Mechanismen zu umgehen oder abzukürzen.

Trotzdem bedeutet das nicht zwangsläufig, dass sich auch der gesamte Entwicklungsprozess an genau derselben Reihenfolge orientieren muss.

Genau diese Unterscheidung hat unsere Herangehensweise an größere TYPO3-Upgrades grundlegend verändert.

Der klassische Weg ist technisch vollkommen richtig

Wer bereits mehrere TYPO3-Upgrades durchgeführt hat, kennt den üblichen Ablauf.

Ein Projekt wird zunächst auf die nächste unterstützte Major-Version gebracht. Der Code wird so weit angepasst, dass das System wieder lauffähig ist, anschließend werden die Upgrade Wizards ausgeführt, Deprecations entfernt und die Anwendung stabilisiert. Erst danach beginnt derselbe Prozess für die nächste TYPO3-Version.

Dieser Ablauf funktioniert.

Er orientiert sich konsequent an der Evolution des TYPO3-Cores und stellt sicher, dass jede Datenbankänderung und jede technische Anpassung in der vorgesehenen Reihenfolge erfolgt.

Lange Zeit haben wir genauso gearbeitet.

Mit jedem größeren Projekt entstand jedoch das Gefühl, dass wir einen erheblichen Teil unserer Entwicklungszeit in Arbeit investierten, die für das eigentliche Zielsystem kaum noch einen Mehrwert erzeugte.

Dasselbe Problem mehrmals lösen

Ein einfaches Beispiel sind API-Änderungen.

Während eines klassischen Upgrades wird eine Methode häufig zunächst nur so weit modernisiert, dass sie unter TYPO3 9 funktioniert. Wenige Tage später muss dieselbe Stelle erneut angepasst werden, weil TYPO3 10 andere Anforderungen stellt. Anschließend folgen weitere Änderungen für TYPO3 11, TYPO3 12 und schließlich TYPO3 14.

Technisch betrachtet ist daran nichts falsch.

Aus Engineering-Sicht entsteht jedoch ein unangenehmer Nebeneffekt.

Ein Entwickler beschäftigt sich mehrfach mit derselben Code-Stelle, obwohl das eigentliche Ziel längst feststeht.

Das Ergebnis ist häufig eine Reihe von Zwischenlösungen, die ausschließlich deshalb entstehen, weil der Entwicklungsprozess den einzelnen Versionsschritten folgt.

Für das spätere System haben diese Zwischenlösungen keinen bleibenden Wert.

Sie waren lediglich notwendig, um die nächste Zwischenversion zu erreichen.

Irgendwann haben wir begonnen, genau diese Arbeit infrage zu stellen.

Zwei völlig unterschiedliche Aufgaben

Der eigentliche Wendepunkt entstand, als wir das Upgrade nicht mehr als einen einzigen Prozess betrachteten, sondern als zwei unterschiedliche Aufgaben mit völlig unterschiedlichen Zielen.

Die erste Aufgabe betrifft die Datenbank.

Hier gibt es kaum Spielraum. Die offiziellen Upgrade Wizards des TYPO3-Cores müssen ausgeführt werden. Tabellen verändern sich, Felder werden migriert, Datenstrukturen angepasst und bestehende Inhalte in ein neues Schema überführt. Dieser Ablauf folgt dem TYPO3-Core und sollte möglichst exakt eingehalten werden.

Die zweite Aufgabe betrifft den Anwendungscode.

Hier stellt sich eine ganz andere Frage.

Nicht:

„Wie bringen wir diesen Code möglichst schnell auf TYPO3 9?"

Sondern:

„Wie soll dieser Code aussehen, wenn das Projekt am Ende auf TYPO3 14.3 läuft?"

Diese beiden Fragen haben erstaunlich wenig miteinander zu tun.

Die Datenbank interessiert sich für den Weg.

Der Anwendungscode interessiert sich ausschließlich für das Ziel.

Unser Ziel ist die Zielarchitektur

Diese Erkenntnis hat unsere Projekte deutlich verändert.

Heute definieren wir zu Beginn eines größeren Upgrades zunächst die Zielarchitektur.

• Welche TYPO3-Version soll langfristig betrieben werden?
• Welche PHP-Version wird verwendet?
• Welche APIs möchten wir einsetzen?
• Welche Third-Party-Extensions bleiben erhalten?
• Welche Komponenten werden ersetzt?

Erst wenn diese Fragen beantwortet sind, beginnen wir mit der eigentlichen Modernisierung.

Dadurch vermeiden wir viele Zwischenlösungen, die später ohnehin wieder entfernt werden müssten.

Der Code entwickelt sich von Anfang an in Richtung der späteren Architektur und nicht in Richtung einer Zwischenversion, die wenige Tage später bereits wieder verlassen wird.

Die Rolle unserer Werkzeuge

Diese Arbeitsweise wäre ohne Automatisierung allerdings kaum praktikabel.

Über viele Jahre haben wir deshalb Werkzeuge entwickelt, die genau diese Trennung unterstützen.

Ein wichtiger Bestandteil ist unsere interne Erweiterung Legacy Updater.

Sie bündelt verschiedene TYPO3-Core-Upgrade-Wizards, projekterprobte Migrationsroutinen, eigene Rector-Regeln und zahlreiche Hilfsskripte, die wir in vielen Upgrade-Projekten wiederverwenden.

Der Name der Erweiterung ist dabei fast nebensächlich.

Entscheidend ist der Gedanke dahinter.

Wenn ein bestimmter Migrationsschritt bereits in mehreren Projekten notwendig war, sollte er nicht jedes Mal neu entwickelt werden.

Dasselbe gilt für unsere Wissensdatenbank.

Nach jedem Projekt dokumentieren wir Probleme, Lösungen und typische Stolpersteine. Manche Erkenntnisse werden später zu How-tos, andere zu Rector-Regeln oder neuen Funktionen innerhalb des Legacy Updaters.

Mit jedem Upgrade wächst dadurch nicht nur unsere Erfahrung.

Der Prozess selbst wird besser.

Automatisierung ersetzt keine Architektur

An dieser Stelle entsteht häufig ein Missverständnis.

Wer über Automatisierung spricht, vermittelt leicht den Eindruck, ein Upgrade ließe sich weitgehend per Knopfdruck erledigen.

Unsere Erfahrung zeigt das Gegenteil.

In einem der zuletzt abgeschlossenen Enterprise-Projekte konnte Rector ungefähr vierzig Prozent der eigentlichen Migration übernehmen.

Das ist beeindruckend.

Gleichzeitig bedeutet es aber auch, dass sechzig Prozent weiterhin erfahrene Entwickler benötigten.

Nicht, weil Rector unzureichend wäre.

Sondern weil sich Architekturentscheidungen nicht automatisieren lassen.

Eine PI-based Extension, die seit fünfzehn Jahren produktiv eingesetzt wird, lässt sich nicht allein durch eine Regel auf Extbase migrieren.

Ein individuell entwickeltes Backend-Modul lässt sich nicht automatisch an moderne TYPO3-Konzepte anpassen.

Und Geschäftslogik entsteht nicht aus Syntax.

Gerade deshalb investieren wir so viel Zeit in Automatisierung.

Nicht weil wir Entwickler ersetzen möchten.

Sondern weil wir möchten, dass sie sich auf genau diese Aufgaben konzentrieren können.

Warum sich dieser Aufwand lohnt

Von außen betrachtet wirkt unser Ansatz zunächst aufwendiger.

• Interne Werkzeuge
• Checklisten
• Deployment-Skripte
• Regressionstests
• Eine Wissensdatenbank
• Eigene Rector-Regeln

Keine dieser Investitionen sieht der Endkunde unmittelbar.

Langfristig verändern sie jedoch die Wirtschaftlichkeit eines Projekts erheblich.

Je reproduzierbarer ein Upgrade wird, desto weniger Zeit verbringen Entwickler mit wiederkehrenden Routineaufgaben.

Je besser sich Änderungen automatisiert überprüfen lassen, desto geringer wird der Aufwand für manuelle Regressionstests.

Und je strukturierter ein Go-live vorbereitet ist, desto kleiner wird das Risiko kurz vor der eigentlichen Umstellung.

Engineering bedeutet aus unserer Sicht deshalb nicht, schneller zu programmieren.

Engineering bedeutet, unnötige Arbeit systematisch aus dem Prozess zu entfernen.

Ein Upgrade endet nicht mit dem Go-live

Vielleicht ist das der größte Unterschied zu unserer früheren Arbeitsweise.

Früher endete ein Projekt mit einer erfolgreichen Migration.

Heute beginnt dort oft die eigentliche Verbesserung.

Nach jedem Upgrade fragen wir uns, welche Erkenntnisse wir in zukünftigen Projekten wiederverwenden können.

• Welche Schritte lassen sich automatisieren?
• Welche Probleme sind erneut aufgetreten?
• Welche Dokumentation hätte Zeit gespart?
• Welche Entscheidung würden wir beim nächsten Mal früher treffen?

Genau aus diesen Fragen entstehen neue Werkzeuge, neue Regeln und neue Prozesse.

Deshalb betrachten wir ein Upgrade heute nicht mehr als einzelnes Projekt.

Wir betrachten es als Möglichkeit, den gesamten Engineering-Prozess weiterzuentwickeln.

Was wir daraus gelernt haben

Wenn wir heute auf unsere ersten größeren TYPO3-Upgrades zurückblicken, würden wir vieles noch einmal anders organisieren.

Nicht, weil die damaligen Lösungen technisch falsch gewesen wären.

Sondern weil wir heute deutlicher zwischen dem unterscheiden, was TYPO3 für eine erfolgreiche Migration benötigt, und dem, was ein Engineering-Team für einen wirtschaftlichen und reproduzierbaren Projektablauf benötigt.

Die Datenbank folgt dem offiziellen Upgrade-Pfad.

Der Anwendungscode folgt der Zielarchitektur.

Diese Trennung mag zunächst wie ein technisches Detail wirken.

Für uns war sie jedoch einer der wichtigsten Schritte, um große TYPO3-Upgrades planbarer, effizienter und qualitativ hochwertiger umzusetzen.

Und genau deshalb sprechen wir heute bei Upgrade-Projekten deutlich häufiger über Prozesse als über Versionsnummern.