it-swarm.com.de

Wann sollten Abhängigkeiten aktualisiert werden?

Wir hatten zwei große abhängigkeitsbedingte Krisen mit zwei verschiedenen Codebasen (Android und eine Node.js-Web-App). Das Android Repo musste für die Migration von Flurry zu Firebase benötigt werden, für das die Google Play Services-Bibliothek aktualisiert werden musste vier Hauptversionen. Ähnliches geschah mit unserer von Heroku gehosteten App Node], in 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 .

Jede der Abhängigkeiten dieser Apps war fast zwei Jahre lang veraltet, und als einige veraltet waren und wir die "Sonnenuntergangs" -Periode erreichten, war es ein Major Kopfschmerzen, um sie zu aktualisieren oder zu ersetzen. Ich habe in den letzten ein oder zwei Monaten über 30 Stunden damit verbracht, alle Konflikte und fehlerhaften Codes langsam zu lösen.

Offensichtlich ist es viel zu lang, die Dinge zwei Jahre lang sitzen zu lassen. Die Technologie bewegt sich schnell, insbesondere wenn Sie einen Plattformanbieter wie Heroku verwenden. Nehmen wir an, wir haben eine vollwertige Testsuite und einen CI-Prozess wie Travis CI, der die Aktualisierung erheblich vereinfacht. Z.B. Wenn eine Funktion nach einem Upgrade entfernt wurde und Sie sie verwenden, 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 vorbeugender 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 verfolgt, damit Sie beispielsweise über Sicherheitslücken informiert werden können. Es ist großartig Service, aber wir müssten die Abhängigkeiten für die von mir erwähnten Projekte manuell überprüfen.

31
Chris Cirefice

Sie sollten Abhängigkeiten im Allgemeinen aktualisieren, wenn:

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

(Diese schließen sich nicht gegenseitig aus.)

Motivation 1 ("wenn Sie müssen") ist der dringendste Fahrer. Eine Komponente oder Plattform, von der Sie abhängig sind (z. B. Heroku), verlangt dies, und Sie müssen sich aneinanderreihen. Erforderliche Upgrades fallen häufig aus anderen Optionen heraus. 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 wahrnehmen, ist weicher und optionaler. Eher ein Urteilsspruch: "Ist das neue Merkmal, die Fähigkeit, die Leistung, ... die Mühe und die Versetzung wert, die es mit sich bringt?" In der Olden Times gab es eine starke Tendenz gegen optionale Upgrades. Sie waren manuell und hart, es gab keine guten Möglichkeiten, sie in einer Sandbox oder einer virtuellen Umgebung auszuprobieren oder das Update zurückzusetzen, wenn dies nicht der Fall war Es hat nicht geklappt, und es gab keine schnellen automatisierten Tests, um zu bestätigen, dass Updates "den Apple-Warenkorb nicht gestört haben". Heutzutage geht die Tendenz zu viel schnelleren, aggressiveren Aktualisierungszyklen. Agile Methoden lieben es, Dinge auszuprobieren. Automatisierte Installationsprogramme, Abhängigkeitsmanager und Repos machen den Installationsprozess schnell und oft fast unsichtbar. Virtuelle Umgebungen und die allgegenwärtige Versionskontrolle erleichtern Verzweigungen, Gabeln und Rollbacks. und automatisierte Tests lassen uns ein Update versuchen, dann einfach und gründlich zu bewerten "Hat es funktioniert? Hat es etwas vermasselt?" Die Tendenz hat sich im Großhandel von "Wenn es nicht kaputt ist, reparieren Sie es nicht" auf den Modus "Frühes Update, häufiges Update" der kontinuierlichen Integration und sogar kontinuierliche Lieferung .

Motivation 3 ist die weichste. User Stories beschäftigen sich nicht mit "dem Sanitär" und erwähnen niemals "und halten die Infrastruktur nicht mehr als N Releases hinter dem aktuellen". Die Nachteile der Versionsdrift (ungefähr die technische Verschuldung, die mit dem Zurückfallen hinter die Kurve verbunden ist) greifen lautlos ein und melden sich dann häufig durch Bruch an. "Entschuldigung, diese API wird nicht mehr unterstützt!" Selbst in agilen Teams kann es schwierig sein, Inkrementalismus zu motivieren und die Frische der Komponenten im Griff zu behalten, wenn dies nicht als entscheidend für den Abschluss eines bestimmten Sprints oder einer bestimmten Veröffentlichung angesehen wird. Wenn sich niemand für Updates einsetzt, können sie unbeaufsichtigt bleiben. Dieses Rad quietscht möglicherweise erst, wenn es zum Brechen bereit ist oder sogar bis es gebrochen ist.

Aus praktischer Sicht muss Ihr Team dem Problem der Versionsdrift mehr Aufmerksamkeit schenken. 2 Jahre sind zu lang. Es gibt keine Magie. Es geht nur darum, "mich jetzt oder später zu bezahlen". Beheben Sie das Problem der Versionsdrift entweder schrittweise 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, von der Sie abhängig sind, dass sie nicht mehr funktioniert, kann Ihren Tag, Ihre Woche oder Ihren Monat wirklich ruinieren. Ich möchte die Frische der Komponenten mindestens 1-2 Mal pro Jahr bewerten. Sie können Überprüfungen explizit planen oder sie durch die relativ metronomischen, normalerweise jährlichen Aktualisierungszyklen der Hauptkomponenten wie Python, PostgreSQL und node.js organisch auslösen lassen. Wenn Komponentenaktualisierungen Ihr Team nicht sehr stark auslösen, können Frischeprüfungen bei Hauptversionen, auf natürlichen Projektplateaus oder bei jeder k-Version ebenfalls funktionieren. Was auch immer die Aufmerksamkeit auf die Korrektur der Versionsdrift bei einer regelmäßigeren Trittfrequenz lenkt.

35
Jonathan Eunice

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 Tech-Stack auf einen neuen migriert, und dazu mussten Sie Ihre Abhängigkeiten aktualisieren. In diesem Moment ist der richtige Zeitpunkt, um Abhängigkeiten zu aktualisieren.

Wenn Sie Ihre Abhängigkeiten im Laufe der Zeit aktualisiert hätten, 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 würden (das, das Sie jetzt durchführen, aber 1 Hauptversion anstelle von 4 aktualisieren), würden Sie wahrscheinlich immer noch irgendwo Kopfschmerzen haben (schließlich bedeutet Hauptversion, Änderungen zu brechen). Ich denke, Sie sind auf dem richtigen Weg.

Wenn Sie jedoch die Migration zu schwierig finden und viel Refactor durchführen müssen, liegt das Problem wahrscheinlich in Ihrer Codebasis. Es ist ziemlich üblich, dass Android Projekte keine Gesamtarchitektur in Bezug auf die Codestruktur haben. Ein gutes Abhängigkeitsinjektionsframework wie Dolch 2 = und ein paar Prinzipien der Softwareentwicklung wie SOLID hätten es einfacher gemacht, die Code-Implementierung zu ändern, während sie beibehalten wurden Verhalten/Anforderungen.

Da wir uns gerade mit Refactoring befassen, 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, sollte das Aktualisieren von Abhängigkeiten ein einfacher Aufwand sein. 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 ein Rollback durch und lösen Sie ein Arbeitselement aus, um das Problem zu untersuchen und zu beheben.

Solange die Kosten für das Upgrade 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 eher früher als später wissen, falls vorgelagerte Änderungen erforderlich sind.
  • Wenn Sie Abhängigkeits-Upgrades bis zur letzten Minute belassen, bedeutet dies häufig, dass Sie diese Upgrades zur Crunch-Zeit durchführen (z. B. als Reaktion auf einen sicherheitskritischen Fehler). Wenn Sie Ihre Abhängigkeiten im Auge behalten, haben Sie die Kontrolle darüber, wann Sie diese Anstrengungen unternehmen, und können diese Upgrades zu Zeiten durchführen, in denen Sie nicht so beschäftigt sind.
  • Neuere Versionen können Produktivitätsverbesserungen aufweisen, z. Bessere Dokumentation, einfachere API, Bugfixes (obwohl auch das Gegenteil möglich ist).

Wenn das Aktualisieren von Abhängigkeiten kein geringer Aufwand ist (z. B. weil Sie das Upgrade manuell testen müssen oder weil bekannte Probleme/wichtige Änderungen vorliegen), müssen Sie die Vor- und Nachteile gegen Ihre anderen Aufgaben abwägen. Alte Abhängigkeiten sind eine Art zinsgünstige technische Schulden und sollten daher entsprechend behandelt werden.

4
Justin

Sie sollten keine Version erstellen, in der Sie wissentlich alte Versionen Ihrer Abhängigkeiten verwenden, es sei denn, diese Versionen sind unterstützte Alternativen.

dh Wenn Sie mit V1 arbeiten und es weiterhin unterstützt wird, können Sie weiterhin die neueste Version von Version 1 verwenden.

Sie sollten nur dann 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 Sicherheitskorrekturen, die Sie berücksichtigen sollten.

Wenn eine neue Version Ihrer Abhängigkeit herauskommt, sollten Sie auch eine Version erstellen

2
Ewan

Ich denke, es muss in gewissem Maße von der betreffenden Bibliothek abhängen, aber ich hatte selbst ähnliche Abhängigkeitskopfschmerzen.

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 erheblichen Vorteil enthält, würde dies ersetzen.

Manchmal haben wir nicht den Luxus, an jeder Anwendung zu arbeiten, die gewartet werden muss, oder sogar die Bereitstellung einer geschäftskritischen Anwendung aufzuheben, aber sie werden Sie irgendwann beißen und eine Unze Prävention schlägt oft ein Pfund Heilung!

1
Matt

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

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

Es ist keine Schande, alte Bibliotheken zu verwenden. Wenn die Änderung benötigt wird, kann es schmerzhaft sein, aber es ist Teil des Jobs.

0
Lucas