Warum wir bei TYPO3-Upgrades alles automatisieren, was sich sinnvoll automatisieren lässt

Wenn wir mit Agenturen über größere TYPO3-Upgrades sprechen, dreht sich das Gespräch zunächst fast immer um technische Themen. Welche TYPO3-Version wird eingesetzt? Welche Extensions müssen modernisiert werden? Wie groß ist der Custom Code? Welche PHP-Version soll zukünftig verwendet werden?

Diese Fragen sind selbstverständlich wichtig.

Interessanterweise beschäftigen sie uns intern jedoch oft deutlich weniger als eine andere Frage, die sich meist erst nach mehreren Projekten stellt:

Warum erledigen wir bestimmte Arbeiten eigentlich immer wieder manuell?

Diese Frage klingt zunächst erstaunlich banal. Tatsächlich hat sie unsere Arbeitsweise in den letzten Jahren stärker verändert als viele technische Neuerungen innerhalb von TYPO3 selbst.

Denn fast jedes größere Upgrade besteht aus einer Mischung zweier sehr unterschiedlicher Aufgaben.

Auf der einen Seite stehen technische Entscheidungen, die Erfahrung, Architekturverständnis und Gespräche mit dem Kunden erfordern. Auf der anderen Seite gibt es zahlreiche wiederkehrende Tätigkeiten, deren Ergebnis jedes Mal identisch sein sollte. Genau diese beiden Bereiche voneinander zu unterscheiden, ist für uns heute einer der wichtigsten Bestandteile eines erfolgreichen Upgrade-Prozesses.

Wiederholbare Arbeit ist kein Engineering-Problem

Zu Beginn unserer ersten Upgrade-Projekte haben wir viele Schritte selbstverständlich manuell durchgeführt. Wir analysierten Deprecation-Logs, starteten Upgrade Wizards, passten Konfigurationen an, prüften Extensions, führten Datenbankmigrationen durch und arbeiteten unsere Testlisten Punkt für Punkt ab.

Das funktionierte.

Mit jedem weiteren Projekt entstand jedoch ein merkwürdiges Gefühl.

Nicht, weil die Aufgaben schwierig gewesen wären.

Sondern weil wir bemerkten, dass wir dieselben Probleme immer wieder lösten.

Natürlich unterschieden sich die Projekte in ihren Details. Jede Plattform brachte ihre eigene Architektur, individuelle Geschäftslogik und eigene Herausforderungen mit. Trotzdem wiederholten sich viele technische Muster erstaunlich häufig.

Bestimmte Deprecations tauchten immer wieder auf.

Ähnliche Anpassungen an Extensions wurden in mehreren Projekten notwendig.

Deployment-Schritte verliefen nahezu identisch.

Und selbst viele Fehler während der Qualitätssicherung gehörten immer wieder zu denselben Kategorien.

Irgendwann wurde uns klar, dass wir diese Aufgaben gar nicht mehr als eigentliche Entwicklungsarbeit betrachten sollten.

Sie waren zu einem Prozessproblem geworden.

Erfahrung sollte nicht im Gedächtnis einzelner Entwickler bleiben

In vielen Unternehmen gilt Erfahrung als etwas Persönliches.

Ein bestimmter Entwickler kennt sich besonders gut mit einem alten Extension-Konzept aus. Ein anderer erinnert sich daran, welche Stolpersteine bei einem früheren Upgrade aufgetreten sind. Wieder ein anderer weiß genau, welche Reihenfolge bei einem komplexen Deployment eingehalten werden muss.

Das funktioniert erstaunlich gut – solange dieselben Personen jedes Projekt begleiten.

Aus unserer Sicht entsteht dadurch jedoch ein strukturelles Risiko.

Je mehr Wissen ausschließlich im Kopf einzelner Entwickler existiert, desto schwieriger wird es, Projekte reproduzierbar durchzuführen.

Deshalb versuchen wir heute, möglichst jede wiederkehrende Erkenntnis in den Prozess zu überführen.

Manchmal entsteht daraus eine neue Rector-Regel.

Manchmal erweitert sie unsere interne Wissensdatenbank.

Manchmal entsteht ein neues Skript oder ein zusätzlicher Punkt auf unserer Upgrade-Checkliste.

Und manchmal reicht bereits ein kurzer Hinweis in unserer Dokumentation, damit derselbe Fehler im nächsten Projekt gar nicht erst entsteht.

Der entscheidende Punkt ist dabei nicht das Werkzeug.

Der entscheidende Punkt ist, dass Erfahrung Schritt für Schritt Teil des Systems wird.

Automatisierung bedeutet nicht, alles automatisch zu erledigen

An dieser Stelle erleben wir häufig ein Missverständnis.

Sobald von Automatisierung gesprochen wird, entsteht leicht der Eindruck, dass wir möglichst viele Tätigkeiten vollständig durch Werkzeuge ersetzen möchten.

Genau das ist nicht unser Ziel.

Automatisierung eignet sich hervorragend für Aufgaben, deren Ergebnis eindeutig definiert ist.

• Eine wiederkehrende Datenbankmigration.
• Eine bekannte API-Transformation.
• Ein standardisierter Deployment-Schritt.
• Eine visuelle Regression, die sich zuverlässig vergleichen lässt.

Sobald jedoch fachliche Entscheidungen notwendig werden, endet dieser Vorteil sehr schnell.

Ein Skript kann nicht beurteilen, ob eine individuelle Backend-Funktion noch den aktuellen Geschäftsprozess des Kunden widerspiegelt.

Es kann nicht entscheiden, ob eine Extension besser ersetzt oder weiterentwickelt werden sollte.

Und es kann schon gar nicht mit einem Product Owner diskutieren, warum eine bestimmte Funktion in den vergangenen Jahren entstanden ist.

Diese Aufgaben bleiben auch in Zukunft die Verantwortung erfahrener Entwickler.

Genau deshalb sehen wir Automatisierung nicht als Ersatz für Expertise.

Wir betrachten sie vielmehr als Möglichkeit, Experten von Routinearbeit zu entlasten.

Unsere Werkzeuge sind das Ergebnis vieler Projekte

Wenn Besucher unser Büro sehen oder mit unserem Team sprechen, fragen sie gelegentlich nach dem Legacy Updater oder unseren internen Rector-Regeln.

Manchmal entsteht dabei der Eindruck, diese Werkzeuge seien der Ausgangspunkt unseres Prozesses gewesen.

In Wirklichkeit war es genau umgekehrt.

Zuerst kamen die Projekte, dann die Probleme – und erst danach entstanden Werkzeuge.

Unsere interne Upgrade-Checkliste ist dafür ein gutes Beispiel.

Heute umfasst sie vierundvierzig einzelne Prüfpunkte und begleitet ein Projekt von der ersten lokalen Entwicklungsumgebung bis zur finalen Go-live-Kontrolle. Am Anfang stehen Fragen wie der Zugriff auf Git, aktuelle Datenbank-Dumps oder die lokale Reproduzierbarkeit der Installation. Am Ende werden bewusst auch scheinbare Kleinigkeiten überprüft – etwa 404- und 403-Seiten, Redirects, Robots-Dateien oder die Sitemap –, weil genau diese Details nach einer Liveschaltung häufig als Erstes auffallen.

Keiner dieser Punkte wurde theoretisch entwickelt.

Jeder einzelne existiert, weil irgendwann einmal genau dort ein Problem aufgetreten ist.

Dasselbe gilt für unseren Legacy Updater.

Oder für unsere internen Migrationsskripte.

Oder für zahlreiche kleine Helfer, die Außenstehende wahrscheinlich nie zu Gesicht bekommen.

Sie alle sind das Ergebnis konkreter Erfahrungen aus realen Projekten.

Gute Prozesse verbessern nicht nur die Geschwindigkeit

Wenn über Automatisierung gesprochen wird, wird fast immer zuerst über Zeitersparnis diskutiert.

Natürlich spielt Geschwindigkeit eine Rolle.

Aus unserer Sicht ist sie jedoch eher ein Nebeneffekt.

Der eigentliche Vorteil liegt woanders.

Ein reproduzierbarer Prozess verbessert die Qualität.

Wenn ein Deployment jedes Mal denselben Schritten folgt, sinkt die Wahrscheinlichkeit, dass kurz vor dem Go-live ein wichtiger Punkt vergessen wird.

Wenn wiederkehrende Code-Transformationen automatisiert erfolgen, entstehen weniger Flüchtigkeitsfehler.

Und wenn visuelle Regressionstests nach jeder größeren Änderung automatisch laufen, müssen viele Probleme gar nicht erst während einer umfangreichen manuellen Testphase entdeckt werden.

Das reduziert nicht nur Entwicklungsaufwand.

Es verändert auch die Qualitätssicherung.

Je früher Fehler sichtbar werden, desto günstiger lassen sie sich beheben.

Deshalb investieren wir heute bewusst Zeit in Dinge, die für den Endkunden zunächst unsichtbar bleiben.

Sie zahlen sich häufig erst Wochen oder Monate später aus.

Jeder abgeschlossene Auftrag verändert den nächsten

Vielleicht unterscheidet uns genau dieser Gedanke am stärksten von unserer Arbeitsweise vor einigen Jahren.

Früher betrachteten wir ein Upgrade als abgeschlossen, sobald die Plattform erfolgreich auf der neuen TYPO3-Version lief.

Heute beginnt an diesem Punkt häufig eine zweite Analyse.

• Welche Erkenntnisse aus diesem Projekt werden wir künftig wieder benötigen?
• Welche Schritte haben unnötig Zeit gekostet?
• Welche Probleme hätten wir früher erkennen können?
• Welche Teile des Prozesses sollten wir automatisieren oder dokumentieren?

Erst wenn diese Fragen beantwortet sind, betrachten wir ein Projekt wirklich als abgeschlossen.

Denn unser eigentliches Ziel besteht nicht nur darin, eine einzelne Plattform erfolgreich zu modernisieren.

Unser Ziel besteht darin, dass das nächste Upgrade ein Stück besser wird als das vorherige.

Was wir daraus gelernt haben

Rückblickend würden wir unsere ersten Upgrade-Projekte heute wahrscheinlich deutlich anders organisieren.

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

Sondern weil wir inzwischen verstanden haben, dass langfristige Qualität nicht allein durch gute Entwickler entsteht.

Sie entsteht, wenn gute Entwickler ihre Erfahrungen in Prozesse, Werkzeuge und gemeinsame Standards überführen.

Vielleicht beschreibt genau das den Unterschied zwischen Entwicklung und Engineering.

Entwicklung löst ein konkretes Problem.

Engineering sorgt dafür, dass dieselbe Klasse von Problemen künftig gar nicht mehr auf dieselbe Weise gelöst werden muss.

Und genau deshalb investieren wir heute mindestens genauso viel Energie in unsere Prozesse wie in den eigentlichen Code.