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 Android repo nécessaire pour migrer de Flurry vers Firebase, qui nécessitait la mise à jour de la bibliothèque des services Google Play quatre versions principales. Une chose similaire s'est produite avec notre application hébergée par Heroku Node 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 .
Les dépendances de chacune de ces applications sont restées périmées pendant près de deux ans, et lorsque certaines ont été dépréciées et que nous avons atteint la période de "coucher du soleil", cela a été un majeur maux de tête pour les mettre à jour ou 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 devraient-elles être mises à jour, ou quand les dépendances devraient-elles être mises à jour? Nous avons mis à jour parce que nous y étions forcés, mais il semble qu'une sorte d'approche préemptive 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 personnels Rails, j'utilise un service appelé Gemnasium qui suit vos dépendances afin que vous puissiez être averti, par exemple, des vulnérabilités de sécurité. C'est un excellent service, mais nous aurions à vérifier manuellement les dépendances pour les projets que j'ai mentionnés.
Vous devez généralement mettre à niveau les dépendances lorsque:
- C'est requis
- Il y a un avantage à le faire
- 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é, la capacité, les performances, ... valent-elles 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 difficiles, il n'y avait pas de bons moyens de les essayer dans un bac à sable ou un environnement virtuel, ou de restaurer la mise à jour si cela ne fonctionnait pas, et il n'y avait pas de rapidité des tests automatisés pour confirmer que les mises à jour n'avaient pas "bouleversé le Apple." De nos jours, le parti pris est vers des cycles de mise à jour beaucoup plus rapides et plus agressifs. Les méthodes agiles adorent essayer les choses; les installateurs automatisés, les gestionnaires de dépendances, et les repos rendent le processus d'installation rapide et souvent presque invisible; les environnements virtuels et le contrôle de version omniprésent rendent les branches, les fourches et les restaurations faciles; et les tests automatisés nous permettent 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 corrigez pas "au mode" mise à jour précoce, mise à jour fréquente "de intégration continue et même continu livraison .
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 l'infrastructure que N versions derrière celle 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 organiquement 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 vérifications de fraîcheur sur les versions majeures, sur les plateaux de projets naturels, ou toutes les versions k peuvent é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. C'est assez courant pour Android projette de ne pas avoir une architecture globale en termes de structure de code. Un bon framework d'injection de dépendances comme Dagger 2 = , et quelques principes d'ingénierie logicielle tels que SOLID auraient facilité la modification de l'implémentation du code tout en conservant les mêmes comportement/exigences.
De plus, comme nous sommes sur la refactorisation, lisez un peu les tests unitaires, car cela aiderait beaucoup lorsque vous effectuez ce type de travail.
Si vous utilisez des outils de gestion de packages (par exemple npm, NuGet) et que vous 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 meilleure documentation, API plus facile à utiliser, corrections de bugs (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.