où devrais-je installer des outils de développement?

Question

Au travail, nous utilisons NUnit, FxCop et d'autres logiciels tertiaires sur nos projets. À l'heure actuelle, nous avons les fichiers de projet pour chaque application stockée dans le rapport du projet et le logiciel est installé par machine de développement (enfin ... un seul, moi).

Nous embauchons quelques autres développeurs dans quelques semaines et j'essaie de rendre les choses plus faciles et plus transparentes. J'ai lu que c'est une bonne idée d'installer ces types de logiciels dans le repo, et de copier/coller des raccourcis sur votre bureau pour exécuter le GUI. Cela facilite la mise à jour vers les versions les plus récentes du logiciel (installez-les sur votre copie de travail, par-dessus l'ancienne, puis validez les modifications) et il est facile de mettre à jour tous les développeurs: inclura la nouvelle version du logiciel.

Je me demande ...

Est-ce que ce travail comme annoncé? Quelqu'un a-t-il essayé? De plus, en tenant compte de la structure du dossier référentiel ci-dessous, si vous avez plusieurs logiciels en développement, installez-vous une copie de, disons nunit, dans le dossier Extras de chaque projet, ou installez-vous un et un le dossier commun des référentiels à utiliser pour tous les projets? (ce dernier me fait penser qu'il y a une déconnexion logique et physique entre le projet et l'outil, mais le premier signifie qu'il pourrait y avoir une poignée d'outils différents car le projet a utilise nunit 2.4.5 et le projet b utilise nunit 2.4. 8, etc. - ainsi que tous les autres outils/versions)

Repository>Common 
Repository>ProjectName>Extras 
Repository>ProjectName>Trunk 
Repository>ProjectName>Tags 
Repository>ProjectName>Experiments 

Je ne sais pas si cette dernière partie est logique ... laissez-moi savoir et je vais clarifier.

Answer 1

Je n'installe pas ou ne place pas d'outils tiers dans un référentiel. Ils vont sur un serveur de fichiers mais pas dans le repo.

Généralement, lorsque j'ai plusieurs versions d'outils, je les configure en définissant des variables d'environnement dans le processus de construction.

Utilisez également une machine de génération dédiée pour vous aider à définir vos stratégies et à limiter les problèmes que rencontrent vos développeurs.

Answer 2

Nous utilisons un dossier (ou projet) appelé "Fournisseur". Toutes nos bibliothèques dépendantes qui ne sont pas développées en interne, ainsi que tous les outils qui s'y trouvent. C'est au niveau supérieur de l'arbre source.

Answer 3

Notre équipe de développement utilise des machines virtuelles. Ainsi, un nouveau membre de l'équipe obtient une VM avec Visual Studio et SQL Server 2008 Express déjà installé. Ces outils commerciaux que nous n'avons pas la possibilité de modifier ne sont pas dans notre système de contrôle de version. Mais nous disposons d'une documentation versionnée des outils installés sur l'image de la machine virtuelle.
Grâce à l'outil Open Source Fitnesse, la vérification dans le référentiel fonctionne bien. Comme vous le dites, vérifier une nouvelle version et mettre à jour les références permet une mise à jour instantanée pour l'équipe. Mais cela fonctionne bien dans ce cas, car aucun processus d'installation de l'outil.
Dans notre cas, nous avons nos outils de milieu comme xUnit, FxCop, ccNet sont vérifiés dans le projet. Nous travaillons principalement avec un grand projet, de sorte que tout va en dessous.
Pour un employeur précédent, nous avions une zone Outils communs dans le référentiel. Étant donné que les différents projets ne souhaitaient pas tous passer à une nouvelle version d'un outil en même temps, chaque version de l'outil devait être archivée dans son propre dossier. Rendre cette zone du référentiel peu différente d'un partage de fichiers. Le stockage contrôlé par le référentiel peut toujours être utile.Les outils de contrôle de version vous permettent de spécifier des "vues" pour supprimer tous les fichiers de projet nécessaires.