Arguments pour et contre l'inclusion de bibliothèques tierces dans le contrôle de version? [fermé]

Une autre raison de vérifier dans les bibliothèques de votre contrôle de source que je n'ai pas vu mentionné ici est qu'il vous donne la possibilité de reconstruire votre application à partir d'un instantané ou d'une version spécifique. Cela vous permet de recréer la version exacte sur laquelle quelqu'un peut signaler un bug. Si vous ne pouvez pas reconstruire la version exacte, vous risquez de ne pas pouvoir reproduire/déboguer les problèmes.

Oui, vous devriez (lorsque cela est possible).

Vous devriez être capable de prendre une nouvelle machine et de construire votre projet en aussi peu d'étapes que possible. Pour moi, c'est:

1. Installer IDE (par exemple Visual Studio)
2. Installer VCS (par exemple SVN)
3. commander
4. Construire

Quelque chose de plus doit avoir une très bonne justification.

Voici un exemple: j'ai un projet qui utilise le compresseur Yui de Yahoo pour minifier JS et CSS. Le YUI .les fichiers jar vont dans le contrôle de source dans un tools à côté du projet. Le runtime Java cependant, ne le fait pas-qui est devenu un prereq pour le projet tout comme L'IDE. Compte tenu de la popularité de JRE, cela semble être une exigence raisonnable.

Non-Je ne pense pas que vous devriez mettre des bibliothèques tierces dans le contrôle de source. L'indice est dans le nom "contrôle de la source".

Bien que le contrôle de source puisse être utilisé pour la distribution et le déploiement, ce n'est pas sa fonction principale. Et les arguments selon lesquels vous devriez simplement pouvoir vérifier votre projet et le faire fonctionner ne sont pas réalistes. Il y a toujours des dépendances. Dans un projet web, ils pourraient être Apache, MySQL, le runtime de programmation lui-même, disons python 2.6. Tu n'empilerais pas tout ceux dans votre référentiel de code.

Les bibliothèques de code supplémentaires sont les mêmes. Plutôt que de les inclure dans le contrôle de source pour faciliter le déploiement, créez un mécanisme de déploiement/distribution qui permet d'obtenir et d'installer facilement toutes les dépendances. Cela rend les étapes pour vérifier et exécuter votre logiciel quelque chose comme:

• Installer VCS
• code de synchronisation
• exécutez le script d'installation (qui télécharge et installe la version correcte de tous dépendances)

Pour donner un exemple spécifique (et je me rends compte que c'est assez centré sur le web), une application web Python peut contenir une exigence.fichier txt qui lit:

Simplejson = = 1,2
django = = 1.0
autresbibliothèque==0.9

Exécutez cela via pip et le travail est terminé. Ensuite, lorsque vous souhaitez mettre à niveau pour utiliser Django 1.1, il vous suffit de changer le numéro de version dans votre fichier de configuration et de relancer l'installation.

La source du logiciel tiers n'appartient pas (sauf peut - être comme référence statique), mais le binaire compilé le fait.

Si votre processus de construction compile un assembly / dll / jar / module, alors ne conservez que le code source tiers dans le contrôle de source.

Si vous ne le compilez pas, placez l'assemblage binaire / dll / jar / module dans le contrôle de source.

Cela peut dépendre de la langue et/ou de l'environnement que vous avez, mais pour les projets sur lesquels je travaille, Je ne place aucune bibliothèque (fichiers jar) dans le contrôle de source. Il est utile d'utiliser un outil tel que Maven qui récupère les bibliothèques nécessaires pour vous. (Chaque projet conserve une liste de fichiers JAR requis, Maven les récupère automatiquement à partir d'un référentiel commun - http://repo1.maven.org/maven2/)

Cela étant dit, si vous n'utilisez pas Maven ou d'autres moyens de gestion et automatiquement aller chercher les bibliothèques nécessaires, par tous les moyens de vérifier dans votre système de contrôle de version. En cas de doute, soyez pratique à ce sujet.

La façon dont j'ai eu tendance à gérer cela dans le passé est de prendre une version pré-compilée des bibliothèques tierces et de vérifier cela dans le contrôle de version, ainsi que les fichiers d'en-tête. Au lieu de vérifier le code source lui-même dans le contrôle de version, nous l'archivons dans un emplacement défini (disque dur du serveur).

Ce genre de vous donne le meilleur des deux mondes: un processus de récupération en 1 étape qui récupère tout ce dont vous avez besoin, mais il ne s'embourbe pas dans votre système de contrôle de version avec un tas de nécessaire fichier. En outre, en récupérant les binaires pré-compilés, vous pouvez ignorer cette phase de compilation, ce qui rend vos builds plus rapides.

Vous devriez définitivement mettre les bibliothèques tierces sous le contrôle de la source. En outre, vous devriez essayer d'éviter de compter sur des choses installées sur la machine du développeur individuel. Voici pourquoi:

• Tous les développeurs partageront alors la même version du composant. C'est très important.
• votre environnement de construction deviendra beaucoup plus portable. Installez simplement le client de contrôle de source sur une nouvelle machine, téléchargez votre référentiel, construisez et c'est tout (en théorie, au moins :) ).
• , il est Parfois difficile d'obtenir une ancienne version de bibliothèque. Les garder sous votre contrôle de source fait en sorte que vous n'aurez pas de tels problèmes.

Cependant, vous n'avez pas besoin d'ajouter du code source tiers dans votre référentiel si vous ne prévoyez pas de changer le code. J'ai tendance à ajouter des binaires, mais je m'assure que seules ces bibliothèques sont référencées dans notre code (et pas celles de Windows GAC, par exemple).

Non, ce n'est pas un crime de guerre d'avoir du code tiers dans votre dépôt, mais je trouve que cela perturbe mon sens de l'esthétique. Beaucoup de gens ici semblent être d'avis qu'il est bon d'avoir toute votre équipe de développement sur la même version de ces dépendances; je dis que c'est un passif. Vous finissez par dépendre d'une version spécifique de cette dépendance, où il est beaucoup plus difficile d'utiliser une version différente plus tard. Je préfère un environnement de développement hétérogène-il vous oblige à découpler votre code des versions spécifiques des dépendances.

IMHO le bon endroit pour garder les dépendances est sur vos sauvegardes de bande, et dans votre dépôt d'engagement, Si vous en avez un. Si votre projet spécifique l'exige (et que les projets ne sont pas tous les mêmes à cet égard), conservez également un document sous votre système de contrôle de version qui renvoie à ces versions spécifiques.

J'aime vérifier les binaires 3ème partie dans un répertoire " lib " qui contient des dépendances externes. Après tout, vous voulez garder une trace des versions spécifiques de ces bibliothèques non?

Lorsque je compile les binaires moi-même, je vérifie souvent une copie compressée du code à côté des binaires. Cela montre clairement que le code n'est pas là pour compiler, manipuler, etc. Je presque n'ai jamais besoin de revenir en arrière et de référencer le code zippé, mais quelques fois il a été utile.

Nous le faisons parce que nous voulons avoir testé une version mise à jour de la branche du fournisseur avant de l'intégrer à notre code. Nous commettons des modifications lors du test de nouvelles versions. Nous avons la philosophie que tout ce dont vous avez besoin pour exécuter L'application doit être dans SVN de sorte que

1. vous pouvez obtenir de nouveaux développeurs et en cours d'exécution
2. Tout le monde utilise les mêmes versions de différentes bibliothèques
3. Nous pouvons savoir exactement quel code était en cours à un moment donné dans le temps, y compris tiers bibliothèque.

Si je peux m'en sortir, je les garde hors de mon contrôle de version et de mon système de fichiers. Le meilleur des cas est jQuery où je vais utiliser la bibliothèque AJAX de Google et la charger à partir de là:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>

Mon prochain choix serait d'utiliser quelque chose comme Submodules. Et si aucun de ceux-ci ne suffit, ils finiront dans le contrôle de version, mais à ce moment-là, c'est seulement aussi à jour que vous êtes...