Frischzellenkur für JavaScript

JavaScript auf Basis von ES6+ mit npm, Babel und Webpack sind die Standards für moderne Webentwicklung und ermöglichen zusammen mit der Entwicklungsumgebung IntelliJ effizientes Arbeiten. Doch wie bringt man 265'000 Zeilen JavaScript-Code auf den neusten Stand, wechselt die Entwicklungsumgebung aus und entwickelt gleichzeitig neue Features? Ein Entwicklerteam bei BSI macht’s vor.

Die Arbeitsumgebung vor der Umstellung auf IntelliJ

Ausgangslage

Das bei BSI entwickelte Open Source Framework Eclipse Scout ist die Basis für unsere Produkte wie BSI CRM oder die Marketing-Automation-Lösung BSI Studio. Vor fünf Jahren wurde der alte UI-Layer von Swing zu HTML migriert und Scout dadurch zu einem Web-Framework. Der JavaScript-Code aus dieser Zeit entspricht dem damals aktuellen EcmaScript 5.1 Standard, die Entwicklung erfolgte bis heute mit der Eclipse IDE.

Mit dem aktuellen CRM Release Ocean wollten wir die gesamte JavaScript Code-Basis nach ES6+ migrieren, die Entwicklungsumgebung von Eclipse zu IntelliJ wechseln und verschiedene proprietäre Build-Tools durch Npm und Webpack ablösen. Die Umstellung musste parallel zur Entwicklung von neuen Features erfolgen, sowohl in Eclipse Scout als auch in den Produkten – die Migration durfte Entwickler also nicht blockieren. Darum sollte die Umstellung weitgehend automatisch erfolgen.

Vorgehen

Fünf BSI Entwickler bildeten das Migrationsteam. Zuerst erstellte dieses Team einen Prototyp des Eclipse Scout Frameworks auf Basis von ES6+ und dazu eine einfache Applikation, die auf dem migrierten Framework aufbaute. Dieser Prototyp verwendet moderne ES6+ Syntax und Sprachkonstrukte wie import, class und extends. Der Build erfolgt nicht mehr wie bisher mit BSI-spezifischen Tools, sondern mit Npm, Webpack und Babel. Der Prototyp definiert, wie der migrierte Source-Code aussieht, welche Sprachfeatures verwendet werden und wie das Framework in ES6-Module aufgeteilt wird. Dabei war es wichtig, dem Entwickler in IntelliJ möglichst gute Unterstützung anzubieten, z. B. durch Code-Completion für JavaScript-Klassen. Diese Anforderung hatte einen grossen Einfluss darauf, wie die ES6-Module und Exports angelegt wurden.

1. Dependency Management mit JavaScript

Viel konzeptionelle Arbeit steckt darum im Thema ES6-Module und Dependency-Management. Wie wird der Code in Module aufgeteilt? Wo werden die Module gehostet? Welche Module müssen in der öffentlichen Npm-Registry verfügbar sein, welche nur intern über Artifactory? Welches Versionierungsschema soll mit Npm verwendet werden? Wie verfahren wir mit Snapshots und lokal ausgecheckten Modulen, zu denen mehrere Abhängigkeiten bestehen? Gerade der letzte Punkt war eine echte Knacknuss und hat dazu geführt, dass sich das Team schlussendlich für den Einsatz von pnpm entschieden hat.

Sobald klar war, wie das Ziel der Migration aussieht, konnte das Team den nächsten Schritt angehen: den Migrator.

2. Code-Migration auf Knopfdruck

Der Migrator ist ein Java-Programm, welches unseren bestehenden Source-Code automatisch – ohne grosse manuelle Eingriffe – gemäss den im Prototyp definierten Konventionen auf den neuen Stand bringt. Verschiedene Tasks transformieren den Code und erledigen Aufgaben wie das Einfügen von Imports oder die Verwendung der Keywords class und extends. Das Programm aktualisiert nicht nur den Framework-Code, sondern auch Projekt-Code, der auf dem Framework aufbaut – ein wichtiges Feature für unsere Kundenprojekte.

«Der Migrator wurde iterativ entwickelt: während der Entwicklung wurde die Migration laufend ausgeführt und der migrierte Code gebuildet und deployt, so dass Fehler schnell bemerkt und durch die Entwickler korrigiert werden konnten.»

André WegmüllerSoftware Engineer bei BSI

Probleme traten vor allem dort auf, wo Entwickler im alten Code von bewährten Patterns abgewichen sind. Diese Stellen wurden von Fall zu Fall analysiert. Je nach Ergebnis wurde der alte Code korrigiert und vereinheitlicht, oder ein Migrator-Task so angepasst, dass die betreffende Code-Stelle verarbeitet werden konnte.

3. Von Eclipse zu IntelliJ

Ein Teil des Teams beschäftigte sich unterdessen mit dem Wechsel der Entwicklungsumgebung weg von Eclipse hin zu IntelliJ. BSI hat für Eclipse Scout eigene Eclipse-Plug-ins entwickelt, um effizienter zu arbeiten. Diese Plug-ins mussten nun migriert werden. Schritt für Schritt wurden Konfigurationsdateien und Launch-Konfigurationen für IntelliJ bereitgestellt. Das Team erstellte laufend Dokumentation zu Themen wie Installation, Erste-Schritte oder Key-Shortcuts, um Umsteigern den Wechsel zu IntelliJ so einfach wie möglich zu machen. Alle Entwickler konnten den Workspace jederzeit mit Eclipse oder mit IntelliJ nutzen. Um den Wartungsaufwand klein zu halten, werden in Zukunft aber nur noch die Konfigurationen für IntelliJ gepflegt.

4. Migration übers Wochenende

Nach vier Monaten rückte der Tag der Wahrheit näher. In Absprache mit allen Mitgliedern des 35-köpfigen Produktentwicklungsteams wurde ein Push-Stopp auf allen GIT-Repositories für die Dauer von einem Wochenende vereinbart. Pünktlich zum Wochenende startete der Migrator und aktualisierte den kompletten Source-Code. Alle Änderungen wurden nach GIT gepusht, die Builds gestartet und die gebauten Applikationen auf den Testsystemen neu deployt und getestet. Das Migrationsteam nahm ein paar letzte Änderungen am IntelliJ-Paket vor – doch dann war alles erledigt. Am Montagmorgen konnte jeder Entwickler IntelliJ hochfahren und mit frischem JavaScript-Code in die Woche starten.

Das Migrationsteam

Fazit

Natürlich gab es in den ersten Tagen kleinere Probleme, die gelöst werden mussten und die Umstellung auf IntelliJ ist für gestandene Eclipse-Anwender mit viel Umgewöhnung und Einarbeitungszeit verbunden.

«Insgesamt sind wir aber glücklich über den frischen Code, den tollen IDE-Support für Webtechnologien und über die Werkzeuge, die wir mit dem State-of-the-Art Toolstack bekommen.»

André Wegmüller

Ein besonders wertvolles Tool für unsere JavaScript-Entwickler ist Babel. Der Transpiler sorgt dafür, dass Entwickler aktuelle Ecma-Sprachfeatures verwenden können, ohne dabei Rücksicht auf ältere Browser nehmen zu müssen, denn Babel generiert beim Build mit Webpack Code, der auf diesen Browsern ausgeführt werden kann. Die Umstellung war ein Erfolg. Mit frischem Code und IntelliJ sind wir gut gerüstet, um in Zukunft verstärkt auf die Entwicklung mit JavaScript zu setzen und trotz grosser Mengen Code, eine robuste, wartungsfreundliche Codebasis zu pflegen.

Die Arbeitsumgebung nach der Umstellung auf IntelliJ
Datum