Javascript-Server: Die stabile Node.js-Entwicklung steht erst am Anfang
Für Außenstehende etwas überraschend: IBM ist eine der treibenden Kräfte gewesen, die mit der Gründung der Node.js Foundation vor etwas mehr als einem Jahr die Wiedervereinigung mit dem Fork Io.js forciert haben. Dank dieses Schritts ist das Projekt zur Erstellung einer serverseitigen Javascript-Umgebung wohl langfristig gerettet worden. Myles Borins, IBM-Angestellter und als Teil des Release-Teams für den 4er-Zweig mit Langzeitpflege zuständig, hat Golem.de erklärt, was das Team in diesem ersten Jahr geleistet hat und wie die Entwicklung von Node künftig gesichert werden soll.
Schnell wird dabei deutlich, dass dem Node-Team die Bedürfnisse der Nutzer-Community besonders wichtig sind. Dies schließt explizit das NPM-Ökosystem mit ein. Dieses "dürfen wir einfach nicht kaputt machen" , sagt Borins. Das ist leicht nachvollziehbar, werden Pakete von NPM doch für Projekte mit Millionen von Endnutzern eingesetzt, was selbst bei kleinen Problemen gravierende Auswirkungen haben kann, wie ein Streit im Frühjahr dieses Jahres gezeigt hat.
Um derartige schwerwiegende Ausfälle zu vermeiden, ist das Werkzeug Canary in the Gold Mine ( CITGM(öffnet im neuen Fenster) ) entstanden. Dieses basiere auf den wichtigsten Modulen von NPM, nutze Unit-Tests, um die Auswirkungen von Änderungen in Node auf die NPM-Pakete zu testen und überprüfe, ob sich diese überhaupt installieren lassen. Läuft etwas schief, stirbt also dem Namen nach der Kanarienvogel wie früher im Bergwerk. Borins nutze CITGM im Schnitt alle zwei Tage.
Ein stetiger Fluss von Zweig zu Zweig
Dabei steht CITGM selbst am Ende einer ganzen Kette von Abläufen, die sich dank einer strikten Organisation der Node-Entwickler inzwischen durchgesetzt haben. So nutze Node ein Modell zur Entscheidungsfindung für neue Beiträge, welches Borins als "verteilten Konsens" beschreibt. Das heißt, "sobald ein Pull Request [auf Github] erzeugt wird, können andere Beitragende diesem zustimmen" . Haben dies "einige wenige Personen gemacht und es beschwert sich binnen weniger Tage kein anderer Entwickler, wird die Änderung in den Master-Zweig von Node übernommen – sofern das Continuous-Integration-System keinen Fehler findet" . Das CI-System nutzt ebenfalls CITGM.
Von da aus wandert ein einzelner Beitrag in den Current-Zweig, weiter in einen Release-Zweig und letztlich eventuell in den aktuellen LTS-Zweig. Borins selbst nutzt zusätzlich noch einen Staging-Zweig für seine LTS-Pflege. "Wir verlassen uns darauf, dass unser Veröffentlichungsrhythmus Fehler findet" . Verursacht ein Betrag irgendwo in diesem Ablauf Probleme, "wird zurückgerollt" . Das geschehe zwar nicht sehr oft, sei aber durchaus schon vorgekommen.
Darüber hinaus setzt das Node-Team für die Behandlung von Problemen ebenfalls auf technische Hilfsmittel. So gibt es zum Beispiel einen Bot, der die Github-Issues überwacht und automatisch mit Labels versieht. Diese technischen und organisatorischen Vorgänge haben Node die notwendige Stabilität gebracht. Doch mit Blick auf die geplanten und kommenden Entwicklungen müsse sich auch die Node-Community selbst verändern, wobei noch viele Einzelheiten geklärt werden müssten, wie Borins bekräftigt.
Team-Organisation und Upstream-Pflege noch unklar
In den vergangenen zwei Monaten war Borins alleinverantwortlich für die Veröffentlichung des 4er-Zweigs. Das bringe auch eine große Verantwortung mit sich, da eine Veröffentlichung etwa nur schwer möglich sei, falls er zum Beispiel im Urlaub sei. Deshalb möchte Borins diese Aufgabe gern auf ein größeres Team verteilen.
Wie genau dies umgesetzt werden soll, ist jedoch noch nicht ganz klar, da die damit verbundenen Diskussionen in der Community erst noch anstehen. Besonders wichtig werde diese Arbeitsteilung vor allem mit Blick auf den anstehenden Beginn der LTS-Pflege des aktuellen 6er-Zweigs. Idealerweise sollten künftig wohl kleine Teams für die einzelnen Zweige zuständig sein.
Enge Zusammenarbeit mit eigenem Upstream
Ebenfalls noch nicht abschließend geklärt ist, wie die Node-Community selbst mit ihren eigenen Abhängigkeiten umgeht. Ein großer Vorteil von Node ist es laut Borins, dass Node seine Abhängigkeiten zumindest im Standardfall nicht statisch linkt, was leicht Updates ermöglicht. Dazu muss das Node-Team lediglich den Veränderungen des Upstream-Projekts folgen, wodurch schnell OpenSSL-Updates eingepflegt werden können.
Etwas problematischer für Node ist allerdings die Abhängigkeit von der Javascript-Engine V8 aus Googles Chromium-Projekt. Denn V8 wird mit dem Chrome-Browser im Rhythmus von sechs Wochen aktualisiert. Neben dem Code selbst verändern sich damit auch die von Google genutzten Werkzeuge und Node kann und will mit diesem Tempo nicht Schritt halten.
Deshalb pflegt Node derzeit einen Fork von V8, der sich etwa als Teil der LTS-Pflege über zweieinhalb Jahre nur sehr wenig verändert. Borins zufolge ist es wünschenswert für Node, dass dieser Langzeitzweig vom V8-Upstream-Team gepflegt wird, was zumindest derzeit aber noch nicht auf der Infrastruktur von Google umgesetzt werden könne. Allerdings gibt es bereits Gespräche mit den Google-Entwicklern, wie dies erreicht werden könnte, versichert Borins.
Diese Kooperation mit V8 wird außerdem durch die Arbeit der Abteilung für die Systementwicklung bei IBM intensiviert. Diese hat V8 auf die Power-Architektur ebenso wie auf die Z-Systems von IBM portiert, um Node auch auf den eigenen Serversystemen bereitstellen zu können.
Ob und wie genau dies zukünftig gelöst werden kann, ist zwar noch völlig offen. Die begonnenen Diskussionen sowie die damit verbundenen Überlegungen zeigen jedoch, dass sich die Node-Entwickler ihrer Verantwortung den vielen Nutzern gegenüber bewusst sind und entsprechend langfristig planen und handeln möchten.