0

Ceci est un post de suivi de notre article précédent (Aide Structuration VS2010 Solutions/Projets et TFS2010).Plus d'infos sur: Aide Structuration VS2010 Solutions/Projets et TFS2010

Nous avons quelques questions sur la façon de structurer nos solutions et projets VS2010 pour une meilleure organisation, ainsi que pour économiser et utiliser TFS2010.

Actuellement, notre code est structuré quelque chose comme:

/OverallAppName 
OverallAppName.sln 
-/Client 
- -/WindowsFormsProject1 
WindowsFormsProject1.sln 
- -/WindowsFormsProject2 
WindowsFormsProject2.sln 
-/Components 
- -/ClassLibrary1 (common library referenced by other projects) 
ClassLibrary1.sln 
- -/ClassLibrary2 
ClassLibrary2.sln 
- -/ClassLibrary3 
ClassLibrary3.sln 
- -/ClassLibrary4 
ClassLibrary4.sln 
- -/ClassLibrary5 
ClassLibrary5.sln 
-/Server 
- -/WindowsServiceProject1 
WindowsServiceProject1.sln 
- -/WindowsServiceProject2 
    WindowsServiceProject2.sln 
- -/WebProject1 
    WebProject1.sln 
- -/WebProject2 
    WebProject2.sln 

Depuis, en ce moment, nous sommes en train de passer de VSS à TFS2010, nous vouloir structurer l'ensemble de nos solutions/projets être le plus efficace, le plus logique, le plus facile à maintenir, le plus facile à référencer et le plus facile à utiliser et à construire dans TFS2010, et nous avons besoin de conseils sur la meilleure façon de tout structurer avec un modèle partitionné.

Des suggestions ????? Comment pouvons-nous structurer tous ces différents types de projets VS2010 dans une structure logique que des groupes distincts peuvent travailler sur des pièces individuelles (pas la solution entière), nous pouvons toujours avoir des références de projet, nous pouvons stocker dans TFS2010 suivre les «meilleures pratiques recommandées»?

Merci. (Désolé, je ne suis pas sûr que le formatage est sorti très bon.)

+0

double possible (http://stackoverflow.com/questions/5083211/help-structuring-vs2010-solutions-projects-and-tfs2010) [Aide Structuration VS2010 Solutions/projets et TFS2010] –

+0

Cela ressemble à un dupliquer, pas un suivi. S'il vous plaît dites pourquoi ce n'est pas une question en double. –

+0

Le premier article posait des questions sur les informations/exemples fournis dans le document Team Development avec Visual Studio Team Foundation Server. Juste essayer de comprendre ce que Microsoft proposait, ainsi que les autres questions. Ce post est spécifiquement sur notre base de code actuelle et comment la structurer de la "meilleure" manière. Sujets similaires, mais différents. Je ne voulais pas tout mettre dans un seul article parce que cela aurait été très long et peut-être confus. C'est pourquoi ce post est un post de suivi. – lmttag

Répondre

0

Bien que j'admire votre engagement à essayer de tout garder comme une grande solution, je pense que cela va vaincre certaines des meilleures fonctionnalités TFS a offrir dans le domaine des builds automatisés en y adhérant.

La raison pour laquelle je dis cela est parce que vous pouvez utiliser des builds déclenchés par check-in pour construire immédiatement le code pour prouver qu'il fonctionne (ou mieux encore, utilisez un check-in Gated). L'utilité de ces builds est inversement proportionnelle au temps qu'ils mettent à courir. Donc, si vous avez une solution massive qui prend 20 minutes à construire, cela va enlever les avantages de ces types de builds. Si toutefois vous disposiez de plusieurs solutions plus petites qui duraient environ 5 minutes chacune, vous n'obtiendrez que les solutions modifiées lors de l'enregistrement et vous connaîtrez les résultats plus tôt. D'après ce que vous avez énuméré ci-dessus, je serais enclin à avoir une solution pour chaque ensemble d'artefacts qui peuvent être libérés séparément. Dans votre exemple, c'est probablement un pour chacun des clients, un pour chacune des applications Web et un pour toutes les bibliothèques communes.

structure de dossier sage, il va ne pas être très différent de ce que vous avez ci-dessus (en supposant je l'interprète correctement)

/OverallApplication 
    /Clients 
     /Client1 
      -Client1.sln 
      /Client1Project1 
       -Client1Project1.csproj 
      /Client1Project2 
       -Client1Project1.csproj 
      ... 
     ... 
    /Components 
     -Components.sln 
     /ClassLibrary1 
      -ClassLibrary1.csproj 
     /ClassLibrary2 
      -ClassLibrary2.csproj 
     ... 
    /Server 
     /WebApp1 
      -WebApp1.sln 
      /WebApp1Project1 
       -WebApp1Project1.csproj 
      /WebApp1Project2 
       -WebApp1Project1.csproj 
      ... 
     ...  
    /CodeSigningKey 
     -KeyPair.snk 
    /ReferencedAssemblies 
     /Manufacturer1 
      -Manufacturer1Assembly1.dll 
      ... 
     ... 

Les bibliothèques communes peuvent encore être ajoutées en tant que références de projet dans le serveur et le client solutions. J'ai introduit quelques nouveaux dossiers pour des éléments communs tels que la clé de signature de code et les assemblys tiers référencés (tels que la bibliothèque d'entreprise). En plus de cela, vous voudrez utiliser une stratégie de branchement de sorte que les branches de code Main, Dev et Release soient séparées. Je recommande une lecture légère du guide de branchement ALM Rangers sur codeplex pour cela. http://vsarbranchingguide.codeplex.com/releases