Wann sollten Abhängigkeiten aktualisiert werden?

Wir hatten zwei große Krisen im Zusammenhang mit Abhängigkeiten mit zwei unterschiedlichen Codebasen (Android und eine Node.js-Web-App). Das Android-Repository musste von Flurry auf Firebase migriert werden, wodurch die Google Play Services-Bibliothek in vier Hauptversionen aktualisiert werden musste . Ähnliches geschah mit unserer von Heroku gehosteten Node-App, bei der unser Produktionsstapel (Zeder) veraltet war und auf Zeder-14 aktualisiert werden musste. Unsere PostgreSQL-Datenbank musste ebenfalls von 9.2 auf 9.6 aktualisiert werden.

Die Abhängigkeiten dieser Apps waren fast zwei Jahre lang veraltet. Als einige davon veraltet waren und wir die "Sunset" -Periode erreichten, war es ein großes Problem, sie zu aktualisieren oder zu ersetzen. Ich habe in den letzten ein oder zwei Monaten über 30 Stunden damit verbracht, alle Konflikte und den kaputten Code langsam zu lösen.

Offensichtlich ist es viel zu lang, die Dinge zwei Jahre lang stehen zu lassen. Die Technologie entwickelt sich schnell, insbesondere wenn Sie einen Plattformanbieter wie Heroku verwenden. Nehmen wir an, wir haben eine vollständige Testsuite und einen CI-Prozess wie Travis CI, der das Aktualisieren erheblich vereinfacht. Wenn beispielsweise eine Funktion nach einem Upgrade entfernt wurde und Sie sie verwendeten, schlagen Ihre Tests fehl.

Wie oft sollten Abhängigkeiten aktualisiert werden, oder wann sollten Abhängigkeiten aktualisiert werden? Wir haben aktualisiert, weil wir dazu gezwungen wurden, aber es scheint, dass eine Art präventiver Ansatz besser wäre. Sollten wir aktualisieren, wenn kleinere Versionen veröffentlicht werden? Hauptversionen? Jeden Monat, wenn Updates verfügbar sind? Ich möchte eine Situation wie die, die ich gerade erlebt habe, um jeden Preis vermeiden.

PS - für eines meiner persönlichen Rails-Projekte verwende ich einen Dienst namens Gemnasium, der Ihre Abhängigkeiten aufzeichnet , damit Sie beispielsweise über Sicherheitslücken informiert werden können. Es ist ein großartiger Service, aber wir müssten die Abhängigkeiten für die von mir erwähnten Projekte manuell überprüfen.

Sie sollten Abhängigkeiten generell aktualisieren, wenn:

1. Es ist erforderlich
2. Das hat einen Vorteil
3. Dies nicht zu tun ist nachteilig

(Diese schließen sich nicht gegenseitig aus.)

Motivation 1 ("wenn Sie müssen") ist der dringendste Fahrer. Einige Komponenten oder Plattformen, auf die Sie angewiesen sind (z. B. Heroku), fordern dies und Sie müssen sich an die Regeln halten. Erforderliche Upgrades ergeben sich häufig aus anderen Optionen. Sie entscheiden sich für ein Upgrade auf die PostgreSQL-Version. Jetzt müssen Sie Ihre Treiber, Ihre ORM-Version usw. aktualisieren.

Ein Upgrade, weil Sie oder Ihr Team einen Vorteil darin sehen, ist weicher und optionaler. Eher ein Urteilsspruch: "Lohnt es sich, die neue Funktion, die Fähigkeit, die Leistung, ... die Anstrengung und die Versetzung, die sie mit sich bringt, zu verursachen?" In der Olden Times gab es starke Vorurteile gegen optionale Upgrades. Sie waren manuell und hart, es gab keine guten Möglichkeiten, sie in einem Sandkasten auszuprobierenoder in einer virtuellen Umgebung, oder um das Update zurückzusetzen, wenn es nicht funktioniert hat, und es gab keine schnellen automatisierten Tests, um zu bestätigen, dass Updates nicht "den Apfelkarren verärgert" haben. Heutzutage geht die Tendenz zu viel schnelleren, aggressiveren Aktualisierungszyklen. Agile Methoden lieben es, Dinge auszuprobieren. Automatische Installationsprogramme, Abhängigkeitsmanager und Repos machen den Installationsvorgang schnell und häufig fast unsichtbar. Virtuelle Umgebungen und allgegenwärtige Versionskontrolle machen Verzweigungen, Verzweigungen und Rollbacks einfach. und automatisierte Tests lassen uns dann einfach ein Update ausprobieren und substanziell auswerten "Hat es funktioniert? Hat es irgendetwas vermasselt?" Die Tendenz hat sich von "Wenn es nicht kaputt ist, repariere es nicht" zu "Update früh, Update oft" verschoben.

Motivation 3 ist die weichste. User Stories beschäftigen sich nicht mit "dem Sanitär" und erwähnen nie "und halten die Infrastruktur nicht mehr als N Releases hinter der aktuellen". Die Nachteile der Versionsverschiebung (grob gesagt die technische Verschuldung, die mit dem Zurückbleiben der Kurve verbunden ist) treten stillschweigend auf und melden sich dann häufig durch Bruch. "Sorry, diese API wird nicht mehr unterstützt!" Sogar in agilen Teams kann es schwierig sein, Inkrementalismus zu motivieren und die Frische der Komponenten im Auge zu behalten, wenn dies nicht als entscheidend für den Abschluss eines bestimmten Sprints oder einer bestimmten Veröffentlichung angesehen wird. Wenn niemand für Updates plädiert, können sie unbeaufsichtigt bleiben. Das Rad kann nicht quietschen, bis es bereit ist zu brechen oder sogar bis es gebrochen ist.

Aus praktischer Sicht muss Ihr Team dem Problem der Versionsverschiebung mehr Aufmerksamkeit schenken. 2 Jahre ist zu lang. Es gibt keine Magie. Es geht nur darum, "mich jetzt zu bezahlen oder mich später zu bezahlen". Behandeln Sie das Problem der Versionsverschiebung entweder inkrementell oder leiden Sie und überwinden Sie alle paar Jahre größere Stöße. Ich bevorzuge Inkrementalismus, weil einige der Plattformstöße enorm sind. Eine wichtige API oder Plattform, auf die Sie angewiesen sind, kann Ihren Tag, Ihre Woche oder Ihren Monat ruinieren. Ich mag es, die Frische der Komponenten mindestens 1-2 Mal pro Jahr zu bewerten. Sie können Überprüfungen explizit planen oder sie durch die relativ metronomischen, normalerweise jährlichen Aktualisierungszyklen von Hauptkomponenten wie Python, PostgreSQL und node.js organisch auslösen lassen. Wenn Komponentenaktualisierungen Ihr Team nicht sehr stark auslösen, überprüfen Sie die Aktualität der Hauptversionen. auf natürlichen projektplateaus, oder jedes k release kann auch funktionieren. Was auch immer Aufmerksamkeit auf die Korrektur der Versionsabweichung bei einer regelmäßigeren Trittfrequenz legt.

Bibliotheken sollten aktualisiert werden, wenn sie aktualisiert werden müssen. Das heißt, wenn die Aktualisierung keinen Wert bringt, sollten Sie dies nicht tun.

In Ihrem speziellen Fall haben Sie von einem alten auf einen neuen Tech-Stack migriert, und dazu mussten Sie Ihre Abhängigkeiten aktualisieren. In diesem Moment ist der richtige Zeitpunkt, um Abhängigkeiten zu aktualisieren.

Hätten Sie Ihre Abhängigkeiten im Laufe der Zeit aktualisiert, um "jetzt keine Kopfschmerzen zu haben", hätten Sie viel Arbeitszeit (Codierung) für keinen Rückgabewert investieren müssen. Und wenn Sie das letzte Update durchführen (das, das Sie gerade durchführen, aber 1 Hauptversion anstelle von 4 aktualisieren), haben Sie wahrscheinlich immer noch irgendwo Kopfschmerzen (schließlich bedeutet die Hauptversion, dass Sie die Änderungen aufheben). Ich denke, Sie sind auf dem richtigen Weg.

Allerdings , wenn Sie es zu schwer zu migrieren, zu finden und eine Menge Refactoring zu tun haben, stehen die Chancen, das Problem liegt in der Code - Basis. Es ist ziemlich üblich, dass Android-Projekte keine Gesamtarchitektur in Bezug auf die Codestruktur haben. Ein gutes Framework für die Abhängigkeitsinjektion wie Dagger 2 und einige Prinzipien der Softwareentwicklung wie SOLID hätten es einfacher gemacht, die Codeimplementierung bei gleichem Verhalten / gleichen Anforderungen zu ändern.

Da wir gerade am Refactoring arbeiten, lesen Sie ein wenig über Unit Testing, da dies bei dieser Art von Arbeit sehr hilfreich wäre.

Wenn Sie Paketverwaltungstools (z. B. npm, NuGet) verwenden und über eine umfassende automatisierte Testsuite verfügen, sollten Sie das Upgrade von Abhängigkeiten mit geringem Aufwand durchführen. Aktualisieren Sie einfach das Paket, führen Sie Ihre Testsuite aus und prüfen Sie, ob Probleme vorliegen. Wenn dies der Fall ist, führen Sie einen Rollback durch und lösen Sie ein Arbeitselement aus, um das Problem zu untersuchen und zu beheben.

Solange die Kosten für die Aktualisierung von Abhängigkeiten niedrig sind, lohnt es sich, auf dem neuesten Stand zu bleiben:

• Wenn es Probleme mit dem Upgrade gibt, möchten Sie dies lieber früher als später wissen, falls vorgelagerte Änderungen erforderlich sind.
• Wenn Sie die Aktualisierung von Abhängigkeiten auf die letzte Minute beschränken, bedeutet dies häufig, dass Sie diese Aktualisierungen zur kritischen Zeit durchführen (z. B. als Reaktion auf einen sicherheitskritischen Fehler). Wenn Sie den Überblick über Ihre Abhängigkeiten behalten, haben Sie die Kontrolle darüber, wann Sie diese Anstrengungen unternehmen, und können diese Upgrades auch dann durchführen, wenn Sie nicht so beschäftigt sind.
• Neuere Versionen können Produktivitätsverbesserungen aufweisen, z. B. eine bessere Dokumentation, eine benutzerfreundlichere API und Bugfixes (auch das Gegenteil ist möglich).

Wenn das Upgraden von Abhängigkeiten nicht mit geringem Aufwand verbunden ist (z. B. weil Sie das Upgrade manuell testen müssen oder weil bekannte Probleme / aktuelle Änderungen vorliegen), müssen Sie die Vor- und Nachteile mit Ihren anderen Aufgaben abwägen. Alte Abhängigkeiten sind eine Art niedrig verzinsliche technische Schulden und sollten dementsprechend behandelt werden.

Sie sollten keine Version erstellen, in der Sie bewusst alte Versionen Ihrer Abhängigkeiten verwenden, es sei denn, diese Versionen werden als Alternativen unterstützt.

Dh wenn Sie auf V1 sind und es weiterhin unterstützt wird, können Sie weiterhin die neueste Version von v1 verwenden.

Sie sollten nur veraltet sein, wenn:

A: Du hast seit einiger Zeit keine Veröffentlichung mehr gemacht.

B: Sie waren so lange auf v1, dass es nicht mehr unterstützt wird

Updates werden aus einem bestimmten Grund veröffentlicht. Sie enthalten Sicherheitsupdates, die Sie berücksichtigen sollten.

Wenn eine neue Version Ihrer Abhängigkeit herauskommt, sollten Sie auch eine Freigabe durchführen

Ich denke, es muss in gewissem Maße von der fraglichen Bibliothek abhängen, aber ich hatte selbst ähnliche Abhängigkeits-Kopfschmerzen.

Der gesunde Menschenverstand sagt mir, dass eine Hauptversion wahrscheinlich der richtige Zeitpunkt für ein Upgrade ist, und eine Nebenversion, die einen schwerwiegenden Fehler behebt oder einen signifikanten Vorteil beinhaltet, würde dies ersetzen.

Manchmal haben wir nicht den Luxus, an jeder Anwendung zu arbeiten, die gewartet werden muss, oder sogar eine unternehmenskritische zu entfernen, aber sie werden Sie letztendlich beißen, und eine Prise Prävention schlägt oft ein Pfund Heilung!

Bibliotheken sollten aktualisiert werden, wenn sie einen Vorteil bieten, den Ihre Software nutzt, um den Aufwand für die Änderung zu kompensieren.

Selbst kleinere Upgrades der Bibliotheksversion können zu Inkonsistenzen in Apps führen. Aus dieser Sicht gibt es keine geringfügigen Änderungen.

Es ist keine Schande, alte Bibliotheken zu benutzen. Wenn die Änderung erforderlich ist, kann es schmerzhaft sein, aber es ist Teil des Jobs.