Wie oft npm-Packages updaten?
Wer nervt sich nicht, wenn Windows mal wieder seine Updates-Meldung zeigt? “Aber ich habe doch erst letzte Woche aktualisiert?”, denkt man sich, während Windows sich neu startet. Dasselbe passiert im Frontend, wenn man mit modernen JavaScript-Libraries oder -Frameworks wie Angular, Vue.js oder React.js arbeitet. Es vergeht kaum eine Woche, in der man nicht eines der Packages updaten müsste. Nur: Warum?
Ein Grund ist, dass diese Art von Applikationen im Internet zur Verfügung stehen und damit besonders gefährdet sind. Jeder kann sich somit daran als “Hacker” versuchen und Schwachstellen ausnutzen. Daher ist es wichtig, die Updates möglichst schnell anzugehen, sobald eine Vulnerabilität festgestellt wurde. Entwickler können sich diese mit dem Befehl “npm -i” auflisten lassen.
Weiter sind nicht nur die Packages für jeden verfügbar, sondern auch der Code. Das heisst, Hacker können sich den Code anschauen und direkt nach Lücken suchen. Für die Entwickler dieser Packages heisst das, ständig daran zu arbeiten, zu verbessern und Updates zur Verfügung zu stellen.
Strategien
Das Problem an sich kann man nicht lösen, somit muss man sich eine Strategie überlegen, wie man damit umgehen will. Unten aufgelistet sind vier Möglichkeiten und meine Erfahrungen dazu.
Strategie 1: Jedes Jahr updaten
Dies ist vor allem für POs (Process Owners) eine angenehme Strategie. Es ist planbar, wann dieses Update gemacht wird, und man kann umfangreiche Tests durchführen, um zu prüfen, ob alles noch läuft. Jedoch ist es gerade im Webbereich wichtig, öfters Updates zu machen. Einmal im Monat oder allerspätestens alle zwei Monate wegen den Sicherheitslücken. Ein weiterer Nachteil ist, dass man schlecht abschätzen kann, wie lange so ein Update braucht. Im Zeitraum von einem Jahr werden viel mehr Packages ein Update brauchen und je mehr Packages betroffen sind, desto schwieriger wird es, den Aufwand abzuschätzen. Auch im Testing können sich Schwierigkeiten zeigen, weil Fehler dann nicht auf ein einzelnes Package, welches geupdated wurde, zurückzuführen ist, sondern gleich 10 oder mehr.
Strategie 2: Jede Hauptversion von Angular/View.js/React.js updaten
Bei Angular gibt es einen regelmässigen Release-Zyklus von ca. einem halben Jahr, während dem Neuerungen hinzukommen. Diese Variante ist sicher besser als nur einmal im Jahr, allerdings für die meisten Frontends nicht genug. Denn auch die Hauptversionen von diesen Libraries können Bugs haben oder es wird eine Sicherheitslücke entdeckt und man muss updaten. Die Probleme beim Testing, dass man danach nicht weiss welches Packet welchen Fehler verursacht, hat man hier ebenfalls.
Strategie 3: Entwickler updaten bei jeder Anpassung der Applikation
Das wiederum halte ich für etwas zu viel des Guten. Denn damit ändert sich dauernd das package-lock und wenn ein Bug entsteht wegen einem Update, wird es schwieriger herauszufinden, durch welchen Commit/Änderung/Update er entstanden ist. Zudem ist es für die POs schwierig zu priorisieren und es braucht Absprachen zwischen Entwicklern, wenn bspw. ein grosses Update einer Hauptbibliothek ansteht, damit die Arbeit nicht doppelt gemacht werden muss.
Strategie 4: Jeden Monat bis alle zwei Monate
Diesen Ansatz habe ich bei der Strategie 1 bereits erwähnt und erachte ich als eine der zuverlässigsten Lösungen. Der PO kann einen Task/Story/Issue im Sprint einplanen und die Entwickler können vorgängig ein npm outdated & npm audit auslösen, um das Ausmass der Updates abzuschätzen. In der Regel sollte die Menge überschaubar sein mit wenigen oder keinen “breaking changes”. Teils entsteht nicht mehr als eine halbe Stunde Arbeit, die Packages zu updaten. Jedes Mal beim Update einer Hauptbibliothek wie Angular/React etc. muss zwar mehr Zeit eingeplant werden, aber dadurch, dass alle anderen Packages regelmässig aktualisiert werden, ist mit weniger unerwarteten Bugs zu rechnen und das was beim Testing festgestellt wird, kann auf ein paar wenige Packages zurückgeführt werden.
Zusammenfassung
Egal, für welche Strategie man sich entscheidet, jede hat ihre Vor- und Nachteile, und jedes Team muss diese für sich selbst abwägen. Meine Empfehlung, um eine möglichst sichere Software und trotzdem Planungssicherheit zu haben, ist Strategie 4. Mit der Ausnahme besonders schwerwiegender Sicherheitslücken, diese sollten sofort behoben werden. Denn keiner will eine unsichere, “hackbare” Applikation auf dem Markt haben.
Empfehlungen: Observables vs Promises in Angular ist eine interessante fiktionale Diskussion über die zwei asynchronen Möglichkeiten in Angular. Unschlüssig, welche Technologie am Besten für das Projekt passt? Schau mal hier rein: Angular vs React.
