Est-ce une bonne pratique de stocker les runtimes du framework sous contrôle de source?

Je sais que de nombreux magasins de logiciels gardent les binaires sous contrôle de source . Cependant, notre boutique était venue pour stocker des frameworks entiers sur le référentiel: DirectX runtime, CUDA, nVidia Optix, peu importe.

On dit qu'il facilite la configuration d'une machine de développement (soi-disant, obtenez la dernière version et commencez à coder). Cependant, il gonfle considérablement le référentiel et le charge avec une histoire non pertinente.

Je n'ai jamais vu un tel modèle d'utilisation. Considérez-vous cela comme une bonne pratique?

[EDIT:] Je n'ai aucun problème avec le contrôle de source des binaires tiers isolés. La question se réfère à des temps d'exécution complets du framework, consistant généralement en plus de 10 binaires. À titre d'exemple extrême, prenez le SDK Windows (que nous ne conservons pas dans le référentiel, Dieu merci, mais je ne vois aucune différence de principe).

Les binaires ne sont généralement pas bien adaptés au système de contrôle de version car:

• ils ne bénéficient pas des fonctionnalités de contrôle de version (fusion, diff)
• ils augmentent la taille du dépôt ...
• ... ce qui compte car vous ne supprimez pas facilement une version d'un VCS (les VCS sont faits pour garder l'historique), contrairement aux référentiels d'artefacts comme Nexus , qui sont de simples répertoires partagés (faciles à nettoyer: cd+ rm!)
• ils doivent être référencés dans un VCS comme un texte , une déclaration de chemin + version: vous pouvez conserver l'historique pertinent de cette façon , en enregistrant tout changement de version binaire comme un changement dans ce fichier texte (comme un pom.xml si vous utilisez Nexus par exemple)

Je suis d'accord avec la version contrôlant les actifs binaires. Je suis contre la version contrôlant les fichiers générés .

En outre, la configuration de l'environnement est différente du développement. Nous développons principalement en Python et il dispose d'un outil appelé virtualenv qui vous permet de créer un environnement isolé léger (y compris des bibliothèques) pour un projet. Lorsque nous vérifions nos sources, nous avons un script de configuration qui construit ce virtualenv. À l'aide d'un manifeste, cela spécifie quelles versions de bibliothèques sont nécessaires et d'autres choses de ce genre. Rien de tout cela n'est contrôlé par la version. Seul le script de configuration l'est.

Jeter tout le cadre sous votre projet principal encombrera votre histoire et gâchera sérieusement les choses. Cela ne fait pas partie de votre projet et doit être traité différemment.

C'est généralement une bonne idée de faire la gestion de la configuration avec les versions du framework. Si votre code a besoin d'une version DirectX spécifique, cette version doit être facilement disponible et si vous extrayez une ancienne version de votre logiciel, il devrait être facile de déterminer les dépendances externes dont il dispose.

Ce que je ne pense pas être une bonne idée ici, c'est d'utiliser votre système de contrôle de version typique pour stocker ces binaires. Dans notre entreprise, nous stockons chaque version de frameworks, bibliothèques et outils externes dans une structure de sous-dossiers sur un lecteur réseau. Lorsque nous pensons que cela a du sens, nous avons des fichiers Lisez-moi pour documenter la version de l'outil à laquelle appartient la version du logiciel, ou, si possible, nous avons des scripts pour installer ou utiliser une version spécifique. Seuls ces fichiers et scripts Lisez-moi entrent dans le contrôle de version.

Nous conservons également les anciennes versions des outils et des bibliothèques tant que nous pensons qu'il peut y avoir une chance que nous devons reconstruire et les anciennes versions en fonction de ces outils. De cette façon, cela nous donne la possibilité de supprimer certains des très anciens bibliothèques et outils de notre lecteur réseau lorsqu'ils sont obsolètes (bien sûr, juste au cas où nous aurions des archives sur des supports externes).

Je pense que les binaires devraient être stockés quelque part. Je suggérerais de les stocker en dehors d'un référentiel, surtout s'ils sont volumineux et entraînent de longs délais de vérification. Je ne vais pas voir que c'est une mauvaise pratique, mais ce n'est pas non plus celle que j'ai vue.

Cela peut en fait être une bonne idée si votre organisation a de nombreux projets qui ciblent différentes versions d'exécution. Il garantit que vous disposez du bon binaire d'exécution lorsque vous travaillez sur les bons projets.

Personnellement, je considère cela comme une très mauvaise pratique. Je préfère configurer un wiki avec des instructions d'installation et y télécharger les fichiers binaires nécessaires. Ces fichiers ne sont nécessaires que pour les nouveaux développeurs, il n'est pas nécessaire de gonfler les référentiels de tout le monde.

Il y a une bonne raison pour cela, à savoir que vous avez tout ce dont vous avez besoin dans un seul endroit, sans aucune dépendance externe.

C'est beaucoup plus important que vous ne le pensez. Il garantit essentiellement que vous ne comptez pas sur un artefact sur un serveur fournisseur qui peut disparaître après quelques années, car vous avez tout en interne.

En ce qui concerne le ballonnement du référentiel. Ce n'est un problème que si votre VCS conserve une copie locale complète (git le fait, cvs non) car le clonage et / ou la mise à jour sera lent. En retour, vous aurez des copies sur chaque machine de développement, ce qui peut sauver votre entreprise si votre système de sauvegarde central échoue pour une raison quelconque un jour.

C'est une question de priorité ou de politique. Tant que la décision est délibérée, je serais d'accord avec cela.