Organisation du travail d'équipe dans Visual Studio

Question

Dites-moi s'il vous plaît si le scénario suivant est possible de mettre en œuvre avec la version régulière de VS, je veux dire l'édition non-équipe. D'abord, notre équipe est assez petite environ 10 développeurs et nous utilisons SVN comme référentiel. La structure des répertoires est relativement le même pour tous les développeurs et pour l'amour de la simplicité, il ressemble

travail \ deploy
Working \ Sources

Tous les projets réside dans le répertoire « Sources » et mis dll de sortie dir « Déployer ». Alors imaginez, on travaille sur le projet "CoreLibrary" et la sortie dll est CoreLibrary.dll et le second travaille sur le projet "SomeLibrary", qui utilisent comme référence CoreLibrary.dll. C'est une situation simplifiée, dans la réalité ce projet pourrait dépendre de nombreux dll qui sont sous la responsabilité d'autres développeurs. Dans ce scénario pourrait être une telle situation lorsque CoreLibrary est modifié après la compilation de SomeLibrary. Et par exemple oublié d'informer les autres développeurs pour renouveler leurs références. Et cela fait que le projet SomeLibrary ne compile pas, mais il ne serait connu qu'au moment de l'exécution -) Donc, pour éviter cela, nous avons également décidé d'unir tous les projets dans une solution composite, où un projet référencerait d'autres - pas sa sortie dll , alors si la solution globale signifie que tout est compatible. Mais il y a un problème - pour cela nous devons changer la dépendance du projet source de dll en projet. Et si nous ouvrons un projet autonome nous liquidons l'icône d'excalmation en opposant cette référence, le projet peut encore être compilé.

I.e comme conclusion - nous avons des références entre les projets (chaque projet - fonctionnalité atomique) à travers dll. L'atomicité conduit à cela quand nous changeons un "atome" nous devons vérifier si ces changements sont compatibles avec d'autres atomes dépendants. C'est plus pratique de faire une solution globale, où nous chargeons les dernières sources et essayons de compiler. Mais, nous devons changer les dépendances entre les projets, des DLL aux projets. Cela semble ne pas être tout à fait "juste", comme les changements de références dans le projet autonome source. Faire une grande solution pour tous les développeurs, les obligeant à recompiler toutes les sources, et pas seulement son projet est également mauvais.

Answer 1

Je travaille dans une situation assez similaire à celle-ci et la façon dont nous la traitons est que chaque développeur a sa propre solution et à l'intérieur de la solution, nous ajoutons tous les projets qui l'utilisaient. Cela empêche l'événement lorsqu'un projet (ou dll) est modifié sur lequel votre projet dépend de ne pas voir ces modifications, car vous référencez l'ancienne version. Ainsi, à chaque fois qu'un fichier est mis à jour dans un projet auquel vous faites référence et que vous construisez votre solution, ce fichier sera mis à jour, reflétant ainsi les changements. Pour autant que je sache, c'est la bonne façon de le faire. Lorsque nous essayons d'utiliser une solution à partir de notre contrôle de source, nous avons tendance à avoir des erreurs de référencement, c'est pourquoi nous sommes passés à la simple vérification des projets à l'intérieur de la solution.