Meilleures pratiques pour l'organisation de structure/exécution "construit" sur une grande solution

Question

Je crée une très grande application web (actuellement à 70 projets et 150k loc mais avec beaucoup plus à faire). J'utilise FinalBuilder pour exécuter des scripts de construction. Cependant, quelles sont les meilleures pratiques pour structurer un si grand projet? Qu'en est-il des dépendances de construction? Quel effet la structure de mes projets a-t-elle sur les performances du code (le cas échéant)?

J'ai déjà vu des discussions à ce sujet mais je ne les trouve pas. J'ai vu des discussions sur des solutions dépassant 600 projets dans la solution, pour des réponses claires, imaginons que ce système va grandir à cette taille (je voudrais savoir comment organiser un projet plus grand que ce que ma fin sera, cela signifierait que je peux organiser une solution plus petite).

Si cela est important, le système est principalement en .NET 3.5 (C#, LINQ, SQL Server, etc.) mais utilisera aussi Python/Erlang.

Answer 1

J'ai seulement 40 projets (mais plusieurs millions de loc), et les meilleures pratiques principales que nous avons est:

• identifier les dépendances entre les projets
• établir une liste globale des étiquettes utilisées par tous les projets qui souhaitent pour participer à la prochaine version
• assurez-vous que chaque projet désireux de publier une étiquette propre dans cette liste globale a créé cette étiquette à partir d'une configuration (liste d'étiquettes) provenant de la liste globale
• construit "(celui potentiellement destiné à être déployé en production) dans un référentiel.

De cette façon:

• développeurs œuvres et compiler leur code directement sur les livraisons des autres projets qu'ils dépendent de (par opposition à télécharger les sources des autres projets et reconstruire tout en local).
  Ils ont seulement les bonnes livraisons car ils connaissent leurs dépendances (immédiates et transitives)
• Les testeurs peuvent déployer rapidement un ensemble de livraisons (à partir de la liste globale des étiquettes) pour effectuer divers tests (non-régression, stress- tests, ...)
• gestion des versions peut déployer ces livraisons (après avoir une construction globale finale) sur les plates-formes de pré-production et de production

L'idée est de:

• ne reconstruira pas la livraison à tous les étapes
• construire seulement au stade de développement (par le biais d'un script de construction unifié commun)
• construire à nouveau avant la sortie (pour la pré-production et de la plate-forme de production)
• compilation et/ou un test seulement contre ces livraisons (et non par rapport aux sources téléchargées et recompilé pour l'occasion: quand vous avez plus de quelques projets, il est tout simplement pas pratique)

principal des meilleures pratiques :
Si votre propre projet fonctionne avec les livraisons des autres projets (et non avec votre reconstruction locale de ces autres projets), il a de bonnes chances de travailler dans les prochaines étapes du cycle de vie de la production de logiciels (test, pré-prod, production)

Answer 2

Avez-vous envisagé d'utiliser NMaven et de faire de chacun des 70 projets un module? Cela vous permet de contrôler la construction, l'empaquetage, la gestion des versions et la publication des modules individuels et du projet parent dans son ensemble. Cela vous aidera également à résoudre les problèmes de dépendance entre les différents modules, les bibliothèques externes et même les versions et les différentes portées de cycle de vie (par exemple, vous n'avez besoin que de NUnit pendant le cycle de vie des tests).

Il pourrait être utile d'expliquer plus en détail à quoi ressemblent ces projets et comment ils dépendent les uns des autres.

Answer 3

Un peu ouvert en tant que question. Commençons par une structure de base, je suggère comme point de départ à mes clients, à l'intérieur d'une branche je

1. Scripts Build
2. des dépendances de construction - les choses à installer sur une machine de construction
3. Bibliothèques - LIB, DLL , ... directement référencé des projets
4. sources de documentation - sources d'aide
5. sources
6. Scripts Déployer

alors Sources est organisé

1. Administrateur - console d'administration et des scripts
2. Database - schémas, des scripts, des données initiales
3. commune
4. Web
5. de NTServices
6. Services - REST/Services SOAP
7. BizTalk - vous nommez des choses spécifiques à un produit