Quand faut-il mettre à jour les dépendances?

Nous avons eu deux crises majeures liées à la dépendance avec deux bases de code différentes (Android et une application Web Node.js). Le dépôt Android devait migrer de Flurry vers Firebase, ce qui nécessitait la mise à jour de la bibliothèque des services Google Play en quatre versions principales. Une chose similaire s'est produite avec notre application Node hébergée par Heroku où notre pile de production (cèdre) était obsolète et devait être mise à niveau vers cèdre-14. Notre base de données PostgreSQL devait également être mise à jour de 9.2 à 9.6.

Chacune de ces applications de dépendances assis rassis pendant presque deux ans, et quand certains ont été désapprouvées et nous avons atteint le « coucher de soleil » période, il a été un grand casse - tête pour les mettre à jour ou de les remplacer. J'ai passé plus de 30 heures au cours du mois ou des deux derniers à résoudre lentement tous les conflits et le code cassé.

Évidemment, laisser les choses reposer pendant deux ans est beaucoup trop long. La technologie évolue rapidement, en particulier lorsque vous utilisez un fournisseur de plate-forme comme Heroku. Supposons que nous ayons une suite de tests à part entière et un processus CI comme Travis CI, ce qui élimine beaucoup de conjectures lors de la mise à jour. Par exemple, si une fonction était supprimée après une mise à niveau et que vous l'utilisiez, vos tests échoueraient.

À quelle fréquence les dépendances doivent-elles être mises à jour ou quand les dépendances doivent-elles être mises à jour? Nous avons mis à jour parce que nous étions obligés de le faire, mais il semble qu'une sorte d' approche préventive serait préférable. Faut-il mettre à jour lorsque des versions mineures sont publiées? Versions majeures? Chaque mois si des mises à jour sont disponibles? Je veux éviter à tout prix une situation comme celle que je viens de vivre.

PS - pour l'un de mes projets Rails personnels, j'utilise un service appelé Gemnasium qui suit vos dépendances afin que vous puissiez être averti, par exemple, des failles de sécurité. C'est un excellent service, mais il faudrait vérifier manuellement les dépendances des projets que j'ai mentionnés.

Vous devez généralement mettre à niveau les dépendances lorsque:

1. C'est requis
2. Il y a un avantage à le faire
3. Ne pas le faire est désavantageux

(Ceux-ci ne sont pas mutuellement exclusifs.)

La motivation 1 ("quand vous devez") est le conducteur le plus urgent. Certains composants ou plates-formes dont vous dépendez (par exemple Heroku) l'exigent, et vous devez vous aligner. Les mises à niveau requises dépassent souvent d'autres choix; vous décidez de passer à la version PostgreSQL tel quel. Vous devez maintenant mettre à jour vos pilotes, votre version ORM, etc.

La mise à niveau parce que vous ou votre équipe voyez un avantage à le faire est plus douce et plus facultative. Plus d'un appel au jugement: "La nouvelle fonctionnalité, capacité, performance, ... vaut-elle l'effort et la dislocation que cela entraînera?" Dans Olden Times, il y avait un fort parti pris contre les mises à niveau optionnelles. Ils étaient manuels et durs, il n'y avait pas de bons moyens de les essayer dans un bac à sableou un environnement virtuel, ou pour annuler la mise à jour si cela ne fonctionnait pas, et il n'y avait pas de tests automatisés rapides pour confirmer que les mises à jour n'avaient pas "bouleversé le chariot Apple". De nos jours, la tendance est à des cycles de mise à jour beaucoup plus rapides et plus agressifs. Les méthodes agiles aiment essayer des choses; les installateurs automatisés, les gestionnaires de dépendances et les référentiels rendent le processus d'installation rapide et souvent presque invisible; les environnements virtuels et le contrôle de version omniprésent facilitent les branches, les fourches et les restaurations; et les tests automatisés nous ont permis d'essayer une mise à jour puis d'évaluer facilement et substantiellement "Cela a-t-il fonctionné? Le biais a changé en gros, de "s'il n'est pas cassé, ne le corrige pas" à "mettre à jour tôt, mettre à jour souvent"

La motivation 3 est la plus douce. Les histoires d'utilisateurs ne se préoccupent pas de "la plomberie" et ne mentionnent jamais "et ne maintiennent pas l'infrastructure plus que N versions derrière l'actuelle." Les inconvénients de la dérive des versions (grosso modo, la dette technique liée au retard dans la courbe) empiètent silencieusement, puis s'annoncent souvent par rupture. "Désolé, cette API n'est plus prise en charge!" Même au sein des équipes Agile, il peut être difficile de motiver l'incrémentalisme et de "rester au top" de la fraîcheur des composants quand elle n'est pas considérée comme essentielle pour terminer un sprint ou une version donnée. Si personne ne préconise des mises à jour, elles peuvent rester sans surveillance. Cette roue peut ne pas grincer jusqu'à ce qu'elle soit prête à casser, ou même jusqu'à ce qu'elle soit cassée.

D'un point de vue pratique, votre équipe doit accorder plus d'attention au problème de dérive de version. 2 ans, c'est trop long. Il n'y a pas de magie. C'est juste une question de "payez-moi maintenant ou payez-moi plus tard". Soit aborder le problème de dérive de version de manière incrémentielle, soit souffrir puis surmonter les secousses plus importantes toutes les quelques années. Je préfère l'incrémentalisme, car certaines des secousses de la plate-forme sont énormes. Une API ou une plateforme clé dont vous dépendez ne fonctionne plus peut vraiment gâcher votre journée, votre semaine ou votre mois. J'aime évaluer la fraîcheur des composants au moins 1 à 2 fois par an. Vous pouvez planifier des révisions de manière explicite ou les laisser être déclenchées de manière organique par les cycles de mise à jour relativement métronomiques, généralement annuels, des principaux composants tels que Python, PostgreSQL et node.js. Si les mises à jour des composants ne déclenchent pas votre équipe très fortement, des contrôles de fraîcheur sur les principales versions, sur les plateaux de projets naturels, ou chaque version k peut également fonctionner. Tout ce qui attire l'attention sur la correction de la dérive de version sur une cadence plus régulière.

Les bibliothèques doivent être mises à jour lorsqu'elles doivent être mises à jour. Cela signifie que si la mise à jour n'apporte aucune valeur, vous ne devriez pas.

Dans votre cas particulier, vous migriez d'une ancienne pile technologique vers une nouvelle et pour ce faire, vous avez été obligé de mettre à jour vos dépendances. Ce moment est le bon moment pour mettre à jour les dépendances.

Si vous aviez mis à jour vos dépendances au fil du temps, afin de "ne pas avoir mal à la tête maintenant", vous auriez dû investir beaucoup de temps de travail (codage) sans valeur de retour. Et quand vous deviez faire la dernière mise à jour (celle que vous faites maintenant, mais en mettant à jour 1 version principale au lieu de 4), vous auriez probablement encore mal à la tête quelque part (après tout, la version principale signifie casser les changements). Je pense donc que vous êtes sur la bonne voie.

Cependant, si vous trouvez qu'il est trop difficile de migrer et que vous devez faire beaucoup de remaniement, le problème réside probablement dans votre base de code. Il est assez courant pour les projets Android de ne pas avoir une architecture globale en termes de structure de code. Un bon cadre d'injection de dépendances comme Dagger 2 et quelques principes d'ingénierie logicielle comme SOLID auraient facilité la modification de l'implémentation du code tout en conservant le même comportement / les mêmes exigences.

De plus, comme nous sommes sur la refactorisation, lisez un peu les tests unitaires, car cela aiderait beaucoup lorsque vous effectuez ce genre de travail.

Si vous utilisez des outils de gestion de packages (par exemple npm, NuGet) et disposez d'une suite de tests automatisée complète, la mise à niveau des dépendances devrait être une activité à faible effort, mettez simplement à niveau le package, exécutez votre suite de tests et voyez s'il y a des problèmes. S'il y a alors annulation et augmentation d'un élément de travail pour enquêter et résoudre le problème.

Tant que le coût de la mise à niveau des dépendances est faible, il vaut la peine d'être mis à jour:

• S'il y a des problèmes avec la mise à niveau, vous voulez le savoir plus tôt que tard au cas où des modifications en amont seraient nécessaires.
• Laisser les mises à niveau des dépendances à la dernière minute signifie souvent que vous effectuez ces mises à niveau au moment critique (par exemple en réponse à un bogue critique pour la sécurité). Garder le contrôle de vos dépendances signifie que vous contrôlez le moment où vous dépensez cet effort et pouvez effectuer ces mises à niveau lorsque vous n'êtes pas aussi occupé.
• Les versions plus récentes peuvent avoir des améliorations de productivité, par exemple une meilleure documentation, une API plus facile à utiliser, des corrections de bogues (bien que l'inverse soit également possible).

Si la mise à niveau des dépendances n'est pas un effort faible (par exemple parce que vous devez tester manuellement la mise à niveau ou parce qu'il y a des problèmes connus / des changements de rupture), vous devez peser le pour et le contre par rapport à vos autres tâches. Les anciennes dépendances sont une sorte de dette technique à faible taux d'intérêt et doivent donc être traitées en conséquence.

Vous ne devez pas faire de version où vous utilisez sciemment d'anciennes versions de vos dépendances, à moins que ces versions ne soient des alternatives prises en charge.

Par exemple, si vous êtes sur V1 et qu'il est toujours pris en charge, vous pouvez toujours utiliser la dernière version de v1.

La seule fois où vous devriez être obsolète est:

R: Vous n'avez pas sorti de version depuis un certain temps.

B: Vous utilisez la v1 depuis si longtemps qu'elle n'est plus prise en charge

Les mises à jour sont publiées pour une raison, elles contiennent des correctifs de sécurité que vous devriez intégrer.

Si une nouvelle version de votre dépendance sort, vous devriez également faire une version

Je pense que cela doit dépendre de la bibliothèque en question dans une certaine mesure, mais j'ai moi-même eu des maux de tête de dépendance similaires.

Le bon sens me dit qu'une version majeure est probablement le bon moment pour effectuer une mise à niveau, et qu'une version mineure qui corrige une faille grave, ou inclut un avantage significatif, remplacerait cela.

Parfois, nous n'avons pas le luxe de travailler sur toutes les applications qui nécessitent une maintenance, ou même de ne pas déployer une application critique, mais elles vous mordront finalement et une once de prévention vaut souvent une livre de guérison!

Les bibliothèques doivent être mises à jour lorsqu'elles offrent un avantage que votre logiciel utilisera pour compenser le travail consacré au changement.

Même les mises à niveau de version de bibliothèque mineures peuvent casser ou insérer des incohérences dans les applications. De ce point de vue, il n'y a pas de changements mineurs.

Il n'y a aucune honte à utiliser de vieilles bibliothèques. Lorsque le changement est nécessaire, cela peut être douloureux, mais cela fait partie du travail.