Unsere 10 Tipps für eine gelungene Liferay Migration
1. Infos über Zielversion einholen
Liferay bringt wöchentlich Releases heraus und entwickelt sich ständig weiter.
Es kann daher gut sein, dass mit der Zeit Features hinzugekommen sind, die früher vorgenommene Individualentwicklungen unnötig machen.
Eine Übersicht über Neuerungen, Bugfixes und Veränderungen je Global Access (GA) findet sich in aller Regel im Liferay Blog.
Sich vorab Fragen zu stellen, wie z. B.
„Welche sichtbaren Funktionen sind dazu gekommen, herausgenommen worden oder geändert/umgezogen worden?“ oder „Welche Tabellen/Klassen sind neu oder deprecated?“
kann den späteren Korrekturaufwand reduzieren.
2. Infos über Eigententwicklungen einholen
Statt einfach mit der Liferay Migration loszulegen, empfiehlt es sich, vorab zu prüfen, wie abhängig Eigenentwicklungen von der aktuellen Liferay-Version und damit auch von der künftigen sind.
Ist das Modul recht losgelöst von Liferay, sind oftmals keine Maßnahmen erforderlich, um eine Kompatibilität mit der Liferay-Zielversion herzustellen.
Sind im Sourcecode Service-Builder Module vorhanden, oder Module, die Datenbankzugriffe von Liferay überschreiben oder abändern, muss überprüft werden, ob für diese Module ggf. ein eigener Upgrade-Step zu entwickeln ist.
Liferay-nahe Module wie z. B. Modulfragmente, Override-Module, Jsp-Bags und weitere Extensionpoints, die eine (Teil-) Übernahme von Liferay-Sourcecode erfordern, sollten beim Upgrade-Vorgang zunächst ausgelassen/übersprungen werden. Im Anschluss können diese anhand der neuen Liferay Codebasis neu erstellt werden (oder ggf. auch nicht, siehe Punkt 1).
3. Datensicherung / Backup / Dump
Ob eine Liferay Migration bzw. ein Upgrade Prozess komplett fehlerfrei ausgeführt und abgeschlossen werden kann, ist in der Praxis schwer vorhersagbar. Daher ist es unabdingbar, Sicherungen wie z. B. Datenbank-Dumps oder Application Server Backups zu erstellen.
Wenn möglich, sollte die Migration auf Basis möglichst produktivnaher Daten geschehen, um vorab mögliche Probleme zu identifizieren.
TIPP: Es ist hilfreich, wenn es bereits Testumgebungen mit echten Produktivdaten gibt.
Die Datensicherung ist für die Datenbank und für die Dokumentenbibliothek (zu finden unter liferay.home/data/document_library) vorzunehmen.
4. Blindes Copy – Paste vermeiden
Für eine Migration empfiehlt es sich auch bei vermeintlich kleineren Migrationsprojekten einen neuen Liferay-Workspace zu erstellen, statt den bisherigen anzupassen oder zu kopieren.
Liferay verwendet im Hintergrund eine Vielzahl an unterschiedlichen Build-Tools (Gradle, Blade, Maven, Node/NPM, Gulp, etc.). Wird der Workspace direkt mit der richtigen Version erzeugt, spart man viel Zeit, da es zu weniger Nacharbeit und möglichen Migrationsfehlern kommt.
Insbesondere bei Custom Themes ist es wichtig, diese explizit für die Zielversion zu erstellen, da seitens Node.js sehr viele Module/Referenzen geladen und hinterlegt werden.
Ist das Grundgerüst eines Workspaces + Themes erstellt, können die oben genannten Liferay nahen Module nach und nach übernommen werden.
5. Versionen benötigter Dritt-Frameworks überprüfen
Vor dem Build des Workspaces sollte überprüft werden, ob die Versionen der o. g. Build-Tools kompatibel mit der Zielversion von Liferay und auch der aktuell verwendeten Java-Version sind.
6. Properties überprüfen
Vor dem Start des Upgrade Prozesses sind bekanntermaßen einige Properties zu hinterlegen.
Jedoch sind häufig nicht nur im Verzeichnis des Upgrade Clients wichtige Properties hinterlegt, sondern auch an anderer Stelle, z. B. liferay.home, osgi/config, osgi/static, tomcat/bin, tomcat/conf, usw.
Gerade beim Kopieren von Sourcen ist darauf zu achten, Referenzen auf die Datenbank oder liferay.home zu überprüfen und ggf. anzupassen.
7. Site-Initializer & Resources-Importer skippen
Vorlagen und allgemeine Inhaltselemente, die automatisch über
- einen Site-Initializer,
- einen Resources-Importer oder
- z. B. ein individuelles Setup-Modul hinzugefügt und/oder aktualisiert werden,
werden i. d. R. über den Liferay Standard Upgradeprozess aktualisiert.
Bevor der Site-Initializer, Resources-Importer oder das Setup Modul nach dem Liferay Upgrade deployed werden, sind die Strukturen/Vorlagen/Elemente im Modul durch die upgegradeten Versionen (diese sind nach Abschluss des Upgrade-Prozesses in der Datenbank zu finden) zu ersetzen.
Andernfalls würde für diese Elemente das Upgrade wieder rückgängig gemacht werden, wodurch Liferay die Ressourcen nicht mehr auflösen kann.
8. Meilensteine definieren
Nicht immer ist der Versionssprung einfach oder klein. Oftmals werden mehrere Versionen übersprungen.
TIPP: Bei größeren Versionssprüngen empfiehlt sich ein Aufteilen in mehrere kleine Migrationsschritte / Meilensteine.
So kann beim Auftreten eines Problems, dieses leichter eingegrenzt und identifiziert werden.
9. Erkenntnisse dokumentieren / teilen
Meistens ist die erste Migration nicht die Letzte, die ansteht.
Um für künftige Liferay Upgrades und Migrationen besser gerüstet zu sein, sollten auftretende Probleme, wenn möglich, immer dokumentiert werden. Gerade wenn diese Probleme in eigens entwickelten Modulen auftreten, können diese in späteren Liferay Updates ggf. wieder oder in ähnlicher Form auftreten.
Eine übersichtliche Dokumentation spart langfristig Zeit und Nerven.
10. Die Liferay Community
Beispiel: Ein noch nie zuvor gesehener Fehler passiert während des Upgrade-Prozesses oder bestimmte Ressourcen sind nach dem Upgrade einfach nicht mehr auffindbar?
Für diesen Fall haben wir folgende Tipps, wo sich nützliche Informationen für eine gelungene Liferay Migration finden lassen:
Liferay Community Forum
Liferay-Dokumentation
Diverse externe Liferay-Blogs, Stackoverflow u. v. m.