So können Sie alle Edelsteine ​​in einer Rails-Anwendung sicher aktualisieren

Question

Rails-Anwendungen können Hunderte von Abhängigkeiten aufweisen, die normalerweise nicht aktualisiert werden und regelmäßig aktualisiert werden müssen. Nachdem ich bundle outdated ausgeführt und eine Liste mit über 100 Edelsteinen bekommen habe, die veraltet sind, bin ich ein bisschen eingeschüchtert, wenn ich jeden einzelnen nachschlagen, seinen CHANGELOG finden und bestätigen kann, dass das Update nichts kaputt macht. Es scheint nicht einmal ein bestätigter Weg zu update a single gem zu sein, ohne alle Abhängigkeiten zu ziehen.

Ich fand this project, die jedes Juwel in einem separaten Commit nach dem Bestehen automatisierter Tests aktualisieren soll. Dies würde helfen, den Prozess zu rationalisieren, aber es sagt Ihnen nicht, welche Edelstein-Versions-Upgrades DSL-Änderungen enthalten (wie this one). Manchmal aktualisiere ich Blind- oder Patch-Versionen blind, ohne zu überprüfen, in der Hoffnung, dass der Autor eine SEMVER-ähnliche Versionskonvention befolgt. In anderen Fällen gibt es keine Dokumentation (keine History- oder CHANGELOG-Dateien).

Wenn ich meinen eigenen Code schreibe, bin ich sicher, jede Zeile zu überprüfen, bevor ich sie begehe. Sollte für die Aktualisierung von Bibliotheken dieselbe Wachsamkeit gelten? Gewöhnlich wurde bei der Aufnahme der Bibliothek nicht viel Sorgfalt angewandt. Aber in einem Greenfield-Projekt gibt es wenig zu verlieren und viel zu gewinnen, wenn man den Code anderer nutzt. In einem ausgereiften Projekt gibt es wenig Toleranz für neue Fehler.

Gibt es irgendwelche Tools oder Prozesse, um Updates einzeln abzurufen, die Änderungen in einer diff-ähnlichen Weise anzuzeigen, das CHANGELOG anzuzeigen und die Testsuite auszuführen?

Answer 1

Meine Strategie besteht darin, immer nur ein paar Edelsteine ​​zu aktualisieren, wann immer es möglich ist. Offensichtlich können Abhängigkeitsbäume das schwierig machen, aber ich wurde ein paar Mal blindlings mit bundle update gebrannt, besonders in großen Projekten mit 100+ Edelsteinen und dies vermeide es wenn möglich. Das Aktualisieren kleinerer Gruppen von Edelsteinen bietet außerdem einen zusätzlichen Vorteil, da etwaige Nebenwirkungen leichter zu isolieren und zu beheben sind.

Ich versuche auch, dedizierte Git-Commits für alle Änderungen an Gemfile/Gemfile.lock zu verwenden. Alle Abhängigkeitsaktualisierungen verfügen daher über einen einzelnen Commit, der nur für diese beiden Dateien Änderungen enthält. Dies macht das Debuggen mit git bisect viel einfacher und Änderungen sind leicht rückgängig zu machen, wenn es nötig ist. Es hilft auch beim unvermeidlichen Versuch-und-Irrtum-Prozess der Auflösung von Abhängigkeiten. Ich habe festgestellt, dass diese Strategie auch für Migrationen gut funktioniert (obwohl Migrationen trickreicher sind als Abhängigkeiten IMO).

Natürlich, hin und wieder ein Update für eine wichtige Abhängigkeit wie Rails, Sidekiq, ActiveAdmin, RSpec, et. al. kommt mit, aber das ist relativ selten und die "dünneren" Abhängigkeiten beibehalten macht diese Pille ein bisschen leichter zu schlucken.