Comment puis-je plaider en faveur de la «gestion des dépendances»?

J'essaie actuellement de plaider en faveur de l'adoption de la gestion des dépendances pour les builds (ala Maven, Ivy, NuGet) et de la création d'un référentiel interne pour les modules partagés, dont nous avons plus d'une douzaine d'entreprises. Quels sont les principaux arguments de vente de cette technique de construction? Ceux que j'ai jusqu'à présent:

Facilite le processus de distribution et d'importation de modules partagés, en particulier les mises à niveau de version.
Nécessite que les dépendances des modules partagés soient documentées avec précision.
Supprime les modules partagés du contrôle des sources, accélère et simplifie les extractions / enregistrements _{(lorsque vous avez des applications avec plus de 20 bibliothèques, c'est un vrai facteur)} .
Permet un meilleur contrôle ou une meilleure connaissance des bibliothèques tierces utilisées dans votre organisation.

Y a-t-il des arguments de vente qui me manquent? Y a-t-il des études ou des articles donnant des mesures d'amélioration?

dependency-management

— Traverser
source

Je pense que vous avez réussi.

— Mike Partridge

Je ne récupérerai jamais les nombreuses heures de ma vie gaspillées sur des configurations Maven cassées. Je suis devenu convaincu que quelles que soient les bonnes intentions, dans un grand corp, cela finira par devenir un gâchis non entretenu qui vous suce la vie jusqu'à ce que vous soyez une coquille creuse.

— MrFox

@suslik Vous voulez savoir ce qu'est une configuration "Maven cassé"?

— Andrew T Finnell

@AndrewFinnell Supposons que 5 groupes travaillent sur des projets que vous devez intégrer pour que votre build soit compilé, et en raison d'une mauvaise coordination, tout le monde finit par dépendre des différentes versions des bibliothèques. Ensuite, il s'avère que l'un des projets n'était pas encore censé être «publié» mais (personne ne l'a dit à maven!), Vous avez une dépendance que vous devez satisfaire. Ce n'est pas «censé» se produire, mais la résolution automatique le rend trop facile. Si tout le monde avait un répertoire / libs à maintenir dans svn, cela forcerait les gens à s'arrêter et à poser des questions avant que les choses ne deviennent incontrôlables.

— MrFox

@MrFox C'est en effet à cause d'une mauvaise coordination, pas de la résolution des dépendances Maven. J'ai vécu les mêmes situations et je ne suis pas un fan de Maven, mais je pense que les outils ne sont pas censés résoudre les problèmes liés à l'homme comme les versions prématurées, le manque de communication, le manque de tests, la mauvaise maintenance, etc.

— scriptin

Réponses:

Je ne suis pas sûr à 100% des points positifs. Voici quelques points négatifs

Vous finissez souvent par ajouter des dépendances à des serveurs / points de terminaison tiers qui pourraient ne pas être stables.

Je suis arrivé avec bower que le dépôt de certaines dépendances ait été supprimé ou déplacé. Donc, un nouveau développeur arrive, clone mon dépôt, tape bower installet obtient des erreurs pour les dépôts non accessibles. Si, à la place, j'avais enregistré le code tiers dans mon référentiel, ce problème disparaît.

Cela est résolu comme le suggère l'OP si vous tirez des dépôts à partir de copies conservées sur un serveur que vous exécutez.
Plus difficile pour les noobs.

Je travaille avec des étudiants en art avec très peu d'expérience en ligne de commande. Ils font de l'art avec Processing, arduino, Unity3D et s'en sortent avec très peu de connaissances techniques. Ils voulaient utiliser du HTML5 / JavaScript que j'ai écrit. Étapes à cause de la tonnelle
1. Téléchargez Zip of repo depuis github (notez que c'est à droite de chaque repo sur github. Parce qu'ils ne connaissent pas git)
2. Téléchargez et installez le nœud (afin que nous puissions exécuter npm pour installer bower)
3. Installez git ou msysgit (car bower l'exige et il n'est pas installé sur les machines de nombreux étudiants)
4. Installer la tonnelle ( npm install -g bower)
5. bower install (enfin pour obtenir nos dépendances)
Les étapes 2 à 5 peuvent toutes être supprimées si nous archivons simplement les fichiers dans notre dépôt github. Ces étapes semblent très faciles pour vous et moi. Pour les étudiants, ils étaient très déroutants et ils voulaient savoir quelles étaient toutes les étapes où et à quoi elles servaient, ce qui pourrait être un bon apprentissage, mais était entièrement orthogonal au sujet de la classe et donc probablement rapidement oublié.
Il ajoute une autre étape lors de la traction.

C'est arrivé plusieurs fois que je fais un git pull origin master, puis teste mon code et il faut 5 à 10 minutes pour se rappeler que je devais taper bower install pour obtenir les derniers dépôts. Je suis sûr que cela est facilement résolu avec un crochet de script de tirage.
Cela rend le branchement plus difficile

Si 2 branches ont des dépôts différents, vous êtes un peu foutu. Je suppose que vous pouvez taper bower installaprès chaque git checkout. Voilà pour la vitesse.

Quant à vos points positifs, je pense qu'il y a des contre-exemples à chacun de ces

Facilite le processus de distribution et d'importation de modules partagés, en particulier les mises à niveau de version.

vs quoi? Ce n'est certainement pas plus facile à distribuer. Tirer un dépôt au lieu de 20 n'est pas plus facile et est plus susceptible d'échouer. Voir n ° 1 ci-dessus

Supprime les modules partagés du contrôle des sources, accélère et simplifie les extractions / enregistrements (lorsque vous avez des applications avec plus de 20 bibliothèques, c'est un vrai facteur).

Inversement, cela signifie que vous dépendez des autres pour les correctifs. Ce qui signifie que si vos dépôts proviennent d'une source tierce et que vous avez besoin d'un bug corrigé, vous devez attendre qu'ils appliquent votre patch. Pire, vous ne pouvez probablement pas simplement prendre la version que vous voulez plus votre patch, vous devez prendre la dernière version qui pourrait ne pas être rétrocompatible avec votre projet.

Vous pouvez résoudre ce problème en clonant leurs dépôts séparément, puis vous pointez vos projets sur vos copies. Ensuite, vous appliquez des correctifs à vos copies. Bien sûr, vous pouvez également le faire si vous copiez simplement la source dans votre référentiel

Permet un meilleur contrôle ou une meilleure connaissance des bibliothèques tierces utilisées dans votre organisation.

Cela semble discutable. Il suffit de demander aux développeurs de placer les bibliothèques tierces dans leur propre dossier sous <ProjectRoot>/3rdparty/<nameOfDep>. Il est tout aussi facile de voir quelles bibliothèques tierces sont utilisées.

Je ne dis pas qu'il n'y a pas de points positifs. La dernière équipe dans laquelle je me trouvais comptait plus de 100 députés de tierce partie. Je fais juste remarquer que ce ne sont pas que des roses. J'évalue si je devrais me débarrasser de bower pour mes besoins par exemple.

— gman
source

Wow, beaucoup de votes négatifs et pas une seule justification pour eux. Bon travail! :(

— gman

Je n'ai jamais utilisé Bower, mais le besoin de installchaque fois que vous passez à la caisse semble être un défaut de conception. Il doit vérifier sa configuration lors de la construction d'un projet: s'il y a des changements, il doit reconstruire à partir de zéro. En outre, le déplacement de référentiels n'est pas pertinent pour Maven, car il extrait les artefacts du référentiel Maven, qui stocke les artefacts, pas le référentiel réel avec du code. Vous ne pouvez modifier artifactIdet groupIddans la prochaine version de votre artefact que si vous le publiez dans le référentiel Maven. Ainsi, vos points # 1 et # 4 sont pour la plupart hors de propos pour Maven en particulier. # 3 peut être remplacé par mvn clean(parfois)

— scriptin

Tout en étant vrai, # 2 n'est pas un inconvénient - c'est un compromis. Bien sûr, vous devez apprendre vos outils! Par exemple, Git est assez difficile à saisir, mais je ne vais pas y renoncer à cause des noobs dem.

— scriptin

Jetez un oeil à l' Appli des douze facteurs

Lisez en particulier ce qu'ils ont à dire sur les dépendances . Vous remarquerez qu'une bonne conception fournit un mécanisme déclaratif pour localiser les dépendances, en Java, cela est souvent réalisé via Maven. Ivy et NuGet fonctionnent bien, mais Maven est actuellement le leader dans le domaine et Ivy est résolument un travail acharné.

Si vous adhérez au processus de publication de Maven (développez des instantanés jusqu'à ce qu'une version officielle soit prête, n'essayez jamais d'écraser une version précédente, utilisez un gestionnaire de référentiel approprié comme Nexus ou Artifactory), alors vous devriez avoir un processus de construction qui résonne bien.

Une fois que vous avez un solide processus de construction déclarative en place, cela ouvre la porte à d'autres bonnes pratiques telles que l'intégration continue avec Jenkins , l'analyse de code continue avec Sonar et vous vous retrouverez à la recherche d'une meilleure stratégie de branchement de contrôle de version à l'aide de git .

Chacun des éléments ci-dessus s'appuie sur le noyau qu'est Maven. De nos jours, c'est à peu près une décision évidente.

— Gary Rowe
source

J'ai regardé l'application Twelve Factor, mais elle est extrêmement litigieuse et seule une très petite partie est pertinente. Pousser Maven ne m'aide pas non plus à expliquer pourquoi nous avons besoin d'une injection de dépendance. Dans l'ensemble, cette réponse ne m'aide pas à vendre l'injection de dépendance, me dit juste beaucoup de choses que je dois faire pour mon processus de construction.

— C. Ross

L'injection de dépendance (le modèle de conception) n'est pas la gestion des dépendances (le modèle de génération). Vous avez déjà couvert tous les aspects les plus importants de votre question. Si votre équipe a encore besoin de convaincre après en avoir entendu parler, alors voir ce que la gestion de la dépendance entraînera devrait être le dernier convaincant.

— Gary Rowe

Et l'élément n ° 1 sur notre liste des 10 meilleurs est ...

(roulement de tambour)

Chaque développeur construit avec exactement les mêmes versions de toutes les dépendances, vous n'avez donc jamais à vous demander quoi déployer en production.

— Ross Patterson
source

En quoi est-ce différent de l'enregistrement des dépendances? En fait, si vous ne consignez pas les dépendances, vous courez le risque qu'une tierce partie casse votre distribution. J'ai eu cela plus d'une fois où certains bower dep pointaient vers un repo que quelqu'un avait supprimé ou renommé. Si je venais de copier la source dans notre référentiel, ce problème disparaît.

— gman