Recommandation de structure de dossiers de projets

Avoir de l'installation des centaines de projets au cours des années, et avoir spécialisée dans les logiciels de gestion de la configuration et de la libération de l'ingénierie, je vous conseille de d'abord mettre l'accent sur la façon dont vous voulez construire/déblocage de votre projet(s).

Si vous utilisez un IDE de construire (de compiler et d'emballage) projet(s), alors vous pourriez aussi bien il suffit de suivre les conventions typique de cette IDE, et tous les "meilleures pratiques" que vous pouvez trouver.

Cependant, je recommande fortement que vous ne créez pas seulement avec un IDE, ou même pas du tout. Au lieu de cela, créer une génération automatique/script de sortie à l'aide de l'un ou plusieurs des nombreux outils open-source disponible. Puisque vous semblez être en ciblant Windows, je vous recommande de commencer avec un look à la Fourmi, le Lierre, et le cas échéant xUnit (jUnit pour Java, nUnit .NET, etc.) pour les tests.

Une fois que vous commencez en bas de ce chemin, vous trouverez beaucoup de conseils sur la structure du projet, de la conception de vos scripts de création, d'essais, etc. Plutôt que de vous accabler avec des conseils détaillés maintenant, je vais simplement vous laisser avec cette suggestion, vous allez facilement trouver des réponses à votre question, ainsi que de trouver tout un tas d'autres questions méritent d'être analysés.

Profitez-en!

Basée sur les commentaires, il semble que quelques précisions sont nécessaires.

Un particulier recommandation que je ferais, c'est que vous vous séparez de votre base de code en différents sous-projets qui produisent chacun un seul produit. La principale de l'application (.EXE) devrait en être un, tout en soutenant les binaires seraient chacun des projets distincts, l'installateur pourrait être un projet distinct, etc.

Chaque projet ne produit qu'un premier résultat: une .EXE, un .DLL, un .HLP, etc. Cette étude est "publié" à un seul, partagé, local, répertoire de sortie.

Faire une arborescence de répertoires où les sous-projets sont pairs (pas de profondeur ou de la hiérarchie, parce qu'il n'aide pas), et ne PAS laisser les projets "atteindre" dans les uns des autres sous-arborescence, chaque projet doit être complètement indépendant, avec dépendances UNIQUEMENT sur les principaux produits livrables des autres sous-projets, référencé dans la répertoire de sortie.

Ne PAS créer une hiérarchie de créer des scripts qui appellent les uns les autres, je l'ai fait et constaté qu'il n'ajoute pas de valeur, mais ne augmenter de manière exponentielle l'effort de maintenance. Au lieu de cela, faire de l'intégration continue script qui appelle votre stand-alone script de compilation, mais d'abord, un nettoyage de caisse dans un répertoire temporaire.

De ne PAS commettre les produits ou les dépendances dans le contrôle de la source--pas votre sortie de la construction, pas les bibliothèques que vous utilisez, etc. L'utilisation de Lierre contre un type Maven binaire référentiel que vous déployez séparé de la source de contrôle et de publier vos propres livrables à elle pour le partage au sein de votre organisation.

Oh, et ne pas utiliser Maven--c'est trop compliqué, code le processus de construction, et n'est donc pas rentable de le personnaliser.

Je suis le mouvement vers SCons, BuildBot, de Fourmis, de Lierre, de nAnt, etc. basé sur ma plate-forme cible.

J'ai été de la rédaction d'un livre blanc sur ce sujet, qui je vois peut avoir un public.

EDIT: Veuillez voir ma réponse détaillée à Comment organisez-vous votre référentiel de contrôle de version?