Praxiserfahrungen bei der Migration auf Grails 4

03.03.2020 07:00

von Tobias Kraft

Am 5. Februar feierte das Grails Framework den 12. Jahrestag seit der Freigabe von Release 1.0.
exensio nutzt die Grails Plattform bereits seit Version 1.1 für produktive Projekte und implementiert aktuell mit der Version 4 größere und kleinere Softwarelösungen.

Durch langjährige Kundenbindung und Weiterentwicklungen laufen die von exensio umgesetzten IT-Lösungen in der Regel viele Jahre und bedingen deshalb entsprechende Aktualisierungen. In diesem Beitrag wird auf die Erfahrungen beim Upgrade von Grails 3 nach Grails 4 eingegangen. Neben dem Framework Upgrade stand des Weiteren der Update von JDK8 auf JDK11 an.

Ein Upgrade auf eine neues Major Release des verwendeten Frameworks muss immer hinterfragt werden, da es entsprechend Zeit und Geld kostet. Was spricht also generell für eine Framework-Migration, mit Fokus auf Grails:

Nutzung neuer Features
Einbindung neuerer Versionen von Dritt-Bibliotheken
Schließen von Security-Lücken
Ältere JDK-Versionen werden ggfs. nicht mehr unterstützt
Je länger man wartet um so teurer wird es, wenn mehrere Versionen in einem Rutsch aktualisiert werden müssen

Generelles Vorgehen

Während bei der Migration von Grails 2 auf Grails 3 am besten ein neues Projekt aufgesetzt wurde und die einzelnen Dateien Schritt für Schritt in das neue Projekt migriert wurden, kann bei der Migration auf Grails 4 im gleichen Projekt-Ordner gearbeitet werden.
Trotzdem haben wir parallel eine neues leeres Projekt aufgesetzt um einfach Abgleiche zwischen alt und neu durchführen zu können.

Bei der Migration wird am besten nach dem offiziellen Benutzerleitfaden vorgegangen. Zusätzlich gibt es einen sehr hilfreichen Blogpost, der potentiell alle auftretenden Probleme abhandelt. Auf die dort beschriebenen Vorgehensweisen wird hier nicht weiter eingegangen.

Für das aktuelle Projekt gab es bei zwei Plugins kurzfristig Probleme.

Die Nutzung des Caching Plugin führte zu Compilierfehlern, so dass die Applikation nicht mehr startete.
Dies konnte durch Nutzung einer Alpha-Version behoben werden:

compile "org.grails.plugins:cache:5.0.0.RC1"

Über das Database Migration Plugin konnten keine SQL Migrationen mehr ausgeführt werden. Hier lag das Problem in der Datei build.gradle. Dort muss Sorge getragen werden, dass die Definitionen für sourceSets vor den dependency-Definitionen eingebunden werden.

sourceSets {
  main {
    resources {
      srcDir 'grails-app/migrations'
    }
    java {
      srcDir 'grails-app/jobs'
    }
  }
}

Ansonsten traten bei der eigentlichen Migration keine weiteren Unwegbarkeiten auf.

Hot Reloading mit JRebel

Ab der Version 4 funktioniert das Hot Reloading von Code nicht mehr. Dies bedeutet, dass Code-Änderungen bei einem laufendem Server erst nach einem Neustart wirksam werden. Mit Hilfe der Developer-Tools von Spring kann der Neustart automatisch getriggert werden. Bei größeren Applikationen kann dies allerdings trotzdem etwas dauern und in den Log-Dateien kommen entsprechende Fehlermeldungen, wenn versucht wird gleichzeitig in der Applikation weiter zu arbeiten.

Mit JRebel steht ein kostenpflichtiges Tool zur Verfügung, das hier Abhilfe verspricht. Zum Zeitpunkt der Migration gab es noch keine offizielle Unterstützung von JRebel für Grails 4 und die Tests zeigten auch lange Reload-Zeiten.

Nach einer Kontakt-Aufnahme mit dem JRebel-Team und Testunterstützung von exensio wurden Funktionalitäten integriert, so dass ab der Version 2020.1.0.1 das Hot Reloading deutlich performanter läuft.

Fazit

In der Vergangenheit wurden von exensio bereits für viele Grails Projekte Migrationen auf neuere Major-Versionen durchgeführt.
Der Aufwand für eine Migration war noch nie geringer wie beim aktuellen Versionssprung von Grails 3 zu Grails 4.

Die nachfolgende Grafik zeigt jeweils das Stimmungsbild der Entwickler beim Durchführen einer Migration auf eine aktuellere Version.

Stimmungsbild der Entwickler beim Upgrade zwischen verschiedenen grails Versionen

In früheren Versionen waren die ersten Releases einer neuen Major-Version oftmals nicht stabil genug, um sofort für den Produktivbetrieb eingesetzt zu werden und es war geschickter die ersten Bugfix-Releases abzuwarten.

Dies hat sich deutlich geändert und es spricht nichts gegen zügigen Upgrade auf die aktuelle Grails Version.

Zurück