Die meisten Pimcore-Upgrades werden aus demselben Grund verschoben: Niemand kann sagen, was es kostet, also passt es in keine Planung, also bleibt es auf der Liste. Der Ausweg besteht darin, die Einschätzung vom Upgrade zu trennen. Den Rückstand zu bewerten ist eine kleine Arbeit. Das Upgrade ist ein Projekt. Beides zu vermengen ist der Grund, warum Instanzen stehen bleiben.
Hier geht es darum, wie Sie Ihren Stand messen, was typischerweise bricht und wie Sie das Vorhaben so aufsetzen, dass es tatsächlich landet.
Erst den Rückstand messen, dann planen
Drei Werte liefern den Großteil der Antwort, und Sie erheben sie an einem Nachmittag.
- Ihre aktuelle Pimcore-Version samt zugehöriger PHP- und Symfony-Version. PHP-Enddaten sind die härtere Grenze, denn irgendwann bietet Ihr Hoster die benötigte Laufzeit schlicht nicht mehr an.
- Die Liste der Fremd-Bundles aus der composer.json, jeweils mit einer Notiz: Gibt es einen zur Zielversion passenden Stand, ist das Bundle aufgegeben, oder wurde es durch etwas im Core ersetzt?
- Der Umfang an Custom Code, der Pimcore-Interna statt öffentlicher APIs berührt. Erweiterungen der Admin-Oberfläche, Event Listener auf interne Hooks und alles, was eine Pimcore-Klasse erweitert statt sie zu verwenden.
Warum die Bundle-Liste wichtiger ist als der Versionsabstand
Drei Versionen Rückstand auf einer nahezu unveränderten Instanz können weniger Arbeit sein als eine Version auf einer Instanz mit fünf eigenen Bundles. Änderungen im Pimcore-Core sind dokumentiert und mechanisch. Ein aufgegebenes Bundle ist eine Entscheidung: ersetzen, forken und selbst pflegen, oder nachbauen, was es geleistet hat.
Diese Entscheidung ist auch der Punkt, an dem Projekte hängen bleiben, denn sie ist keine technische Frage. Jemand muss beurteilen, ob eine Funktion die Mühe noch wert ist. Diese Entscheidungen vor dem Upgrade zu treffen statt während des Upgrades ist der wesentliche Unterschied zwischen einem reibungslosen Ablauf und einem, der aus dem Zeitplan läuft.
Was tatsächlich bricht
Zuerst der beruhigende Teil: Ihre Daten sind bei einem normalen Upgrade nicht in Gefahr. Datenobjekte, Assets und Dokumente überstehen es. Arbeit macht der Code drumherum.
- Bundles ohne Release für die Zielversion. Jedes davon ist eine Entscheidung, und sie gehören früh getroffen.
- Custom Code, der Pimcore-Interna mit geänderter Signatur oder verschobenem Namespace aufruft. Das ist mechanisch zu beheben, sobald wieder kompiliert werden kann, und mühsam im Verhältnis zur Menge.
- Erweiterungen der Admin-Oberfläche, historisch der Bereich mit den größten Änderungen zwischen Major-Versionen.
- PHP-Anforderungen, die unterhalb des Pimcore-Upgrades eine eigene Migration erzwingen. Genau hier wird aus einer Zwei-Wochen-Schätzung still eine Sechs-Wochen-Realität.
- Integrationen, die sich auf Verhalten statt auf dokumentierte API verlassen haben. Deshalb zählt der Integrationstest genauso viel wie der Test der Anwendung.
Wie das Upgrade ablaufen sollte
Die Mechanik ist unspektakulär, und genau das ist der Punkt. Ein Upgrade soll langweilig sein.
- In einer Branch-Umgebung mit produktionsnahem Datenvolumen arbeiten. Performance-Regressionen zeigen sich nicht an hundert Testprodukten.
- Eine Major-Version nach der anderen. Zwischen den Schritten gibt es einen testbaren Zustand, und wenn etwas bricht, wissen Sie, welcher Sprung es war.
- Die Bundle-Entscheidungen vor dem Core treffen. Ein Upgrade, das auf halbem Weg an einem aufgegebenen Bundle hängen bleibt, ist schlechter als eines, das noch nicht begonnen hat.
- Integrationen testen, nicht nur die Anwendung. Der nächtliche ERP-Import und die Data-Hub-Endpunkte sind das, wovon Ihr Geschäft tatsächlich abhängt.
- Einen Rollback bereithalten, den Sie getestet haben. Ein ungetesteter Rollback-Plan ist ein Absatz in einem Dokument und kein Rollback.
- In einem Zeitfenster ausrollen, in dem die Personen verfügbar sind, die das System kennen. Klingt selbstverständlich und wird regelmäßig ignoriert.
Das Audit enthält die Bewertung von Version und Upgrade-Pfad samt Aufwandsschätzung, damit die Zahl aufhört, unbekannt zu sein.
Pimcore Audit →Warum ein fester Upgrade-Rhythmus günstiger ist
Die Instanzen, die aktuell bleiben, haben nicht die größeren Budgets. Es sind die, bei denen das Upgrade ein wiederkehrender Wartungsposten ist statt ein Projekt, das jedes Mal eine Diskussion gewinnen muss.
Minor-Versionen laufend, Sicherheitspatches zeitnah, ein geplantes Major-Upgrade pro Zyklus: Dieses Muster hält den Abstand bei einer Version, und das ist die Größe, in der der Aufwand planbar bleibt. Über mehrere Jahre gerechnet ist es außerdem deutlich günstiger als das Aufholen in einem großen Sprung, weil Aufholen mehrere Sprünge gleichzeitig plus die Rekonstruktionsarbeit bedeutet.
Wenn Sie bereits mehrere Versionen zurückliegen
Dann ist der erste Schritt kein Upgrade, sondern eine Bewertung. Feststellen, welche Bundles tot sind, wie viel Custom Code Interna berührt und wie der PHP-Pfad aussieht. Daraus entsteht eine Zahl, und eine Zahl passt in ein Budget.
Der zweite Schritt ist die Entscheidung, was nicht mitkommt. Instanzen, die seit Jahren laufen, enthalten fast immer Funktionen, die niemand nutzt, und deren Migration kostet dasselbe wie die der wichtigen. Ein Upgrade ist ein guter Anlass, aufzuhören, dafür zu zahlen.
Wir planen und führen Pimcore-Upgrades für Hersteller in Österreich und Deutschland durch, auch auf Instanzen, die wir nicht gebaut haben.
Pimcore Entwicklung und Integration →