Gestion des dépendances tierces internes

Question

Nous avons beaucoup de différentes solutions/projets qui sont gérés par différentes équipes. Notre solution doit référencer plusieurs projets qu'une autre équipe possède. Nous ne voulons pas ajouter ces dépendances comme références de projet car nous n'avons pas l'intention de modifier ce code, nous voulons juste l'utiliser. De plus, nous avons déjà pas mal de projets dans notre solution et nous ne voulons pas en rajouter car cela va ralentir Visual Studio. Nous construisons donc ces projets dans une solution séparée et nous les ajoutons comme références de fichiers à notre solution.

Ma question est, comment les gens gèrent-ils ces types de dépendances? Est-ce que je devrais juste avoir un processus automatisé qui cherche des changements à ces projets, les construit et vérifie les dll dans notre contrôle de source, après quoi nous les traitons comme d'autres dépendances de tiers? Y a-t-il une manière recommandée de faire ceci?

Answer 1

Une solution, bien qu'elle ne corresponde pas nécessairement à ce que vous recherchez, consiste à faire en sorte que chaque sous-système dépendant effectue une libération. Cette version peut prendre la forme d'une installation MSI ou simplement d'un partage réseau d'assemblys. Lorsqu'un changement important est effectué, cette équipe peut vous en informer et vous pouvez exécuter l'installation ou un script pour copier les fichiers. Une fois que vous avez obtenu la version, vous pouvez les mettre dans le GAC, de cette façon vous n'avez pas à vous soucier de les copier dans les dossiers de votre bin de projet.

Une autre solution, en supposant que vous utilisez un serveur de génération ou une intégration continue quelconque, consiste à avoir une étape de post-construction ou une étape de traitement des fichiers. À tout moment donné, les développeurs des autres équipes pourraient récupérer les nouveaux fichiers, ou avoir un script ou un fichier bat les retirer localement.

EDITER - UNE AUTRE SOLUTION Il est peut-être préférable de demander pourquoi avez-vous ces dépendances? En avez-vous vraiment besoin localement lors de la construction de votre partie de l'application? Pourriez-vous mocker les dépendances dans votre solution, vous permettant de coder, construire et exécuter des tests unitaires? L'application réelle les relierait dans vos environnements DEV/Test/Prod. Garder votre solution découplée et dépendante libre peut être une meilleure solution pour l'équipe individuelle. Laissez l'intégration et le couplage lorsque l'application s'exécute dans un paramètre réel.

Answer 2

(^{Pas complète réponse, mais encore:})
Toute livraison est mieux stocké dans un fichier/répertoire binaire, par opposition à un VCS utilisé pour gérer sources histoire.

Nous préférons gérer ces livraisons dans un repo comme Nexus, et nous utilisons maven pour récupérer les dépendances droite.
Même si ces outils peuvent être plus orientés Java, Nexus peut stocker n'importe quoi, et Maven est seulement là pour lire le pom.xml de chaque artefact et calculer les bonnes dépendances.