Structure des scripts de construction NAnt et structure de la solution sur le serveur de construction

Question

Nous sommes en train de rationaliser/automatiser la construction, l'intégration et les tests unitaires ainsi que le déploiement. Notre logiciel est développé dans Visual Studio où nous avons utilisé C# et VB.NET dans nos projets. Un seul projet peut être contenu dans plusieurs solutions (le projet Utils est utilisé dans les solutions ProductA et ProductB)

Pour des raisons historiques, notre référentiel de code n'est pas aussi bien structuré qu'on aurait pu l'espérer. E.g. Le projet Utils peut être localisé sous la solution ProductA (parce qu'il a été utilisé en premier), mais il a ensuite été jugé utile pour le développement de productB et simplement inclus dans la solution de productB (mais toujours dans un sous-répertoire de productA). Je souhaite utiliser des tests d'intégration continus et installer un serveur de génération CC.NET dans lequel j'ai l'intention d'utiliser NAnt pour créer les versions réelles.

Question 1: Comment dois-je structurer mes builds sur le serveur de build? Dois-je demander à CC.NET de récupérer tous les projets pour le produit B dans une seule bibliothèque, par ex. une structure de fichier similaire à

-ProductB 
--Utils 
--BetterUtils 
--Data 

ou devrais-je opter pour un filestructure similaire à ce

-ProductA 
--Utils 

-ProductB 
--BetterUtils 
--Data 

et puis juste ont le NAnt construire des scripts gèrent les références? Nos références dans VS ne correspondent pas à l'emplacement réel dans le référentiel de code, il n'est donc pas possible aujourd'hui de vérifier la solution productB et de la construire immédiatement (malheureusement). J'espère que cette question est logique? Est-il préférable de vérifier tout le code source situé dans différents projets dans un seul dossier de fichiers (tout en conservant une sorte de structure) et puis construire tout à la fois ou avoir plusieurs projets dans CC. NET, puis laissez le serveur CC.NET gérer les dépendances? Exemple: Dois-je avoir un projet distinct dans CC.NET pour surveiller la construction/test automatisé du projet Utils quand il n'est jamais sorti seul? Ou devrais-je simplement le construire/tester tout en le construisant dans le cadre de ProductB?

J'espère que ce qui précède a du sens et que vous pouvez me fournir quelques arguments pour l'utilisation de l'une ou l'autre option. Nous ne sommes pas loin d'une structure de référentiel de code source idéale et je préférerais que je puisse résoudre l'absence de structure de référentiel sur le serveur de construction au lieu d'avoir à nettoyer la structure de notre référentiel. La désactivation de VSS n'est malheureusement pas une option. En ce moment, notre build consiste soit à déployer via VS clickonce, soit à appuyer sur F5, donc le simple fait d'automatiser la build serait un énorme pas en avant pour nous.

Merci

Answer 1

Pour répondre à votre première question, je recommanderais un dossier de niveau supérieur pour chaque projet de construction. Le problème avec un seul arbre correspondant à votre référentiel source est que lorsque votre serveur de construction tente d'exécuter plusieurs générations à la fois, un ou plusieurs échoueront probablement à cause des fichiers utilisés par d'autres processus. En outre, vous pouvez rencontrer des cas où un script de génération tire une ancienne version du code. Dans ce cas, vous ne voulez pas qu'un projet différent utilise accidentellement la version source incorrecte.

Si vos solutions la référence déjà des projets de chemins relatifs, vous pouvez vous retrouver avec une structure comme celle-ci:

-CCNetBuilds 
--ProductASource 
---Utils 
---... 
--ProductBSource 
---ProductA 
----Utils 
---ProductB 
----BetterUtils 
----Data 

Dans ce cas, la construction de produit B contient une partie du produit Une source, au même chemin relatif que votre solution attend déjà. Cela prend un peu plus de temps à mettre en place dans CC.Net, mais il est plus facile à maintenir si les développeurs ont leur code configuré de cette façon sur leurs machines. Les mêmes fichiers de solution utilisés en développement sont utilisés par le serveur de génération.

Pour répondre à votre deuxième question, je préfère les utilitaires étant sa propre construction. Si j'ai des tests unitaires sur mon assembly Utilitaires, je ne voudrais pas qu'ils s'exécutent pour chaque produit qui utilise les utilitaires. En outre, si vous disposez d'une version distincte pour Utilities, vous pouvez définir une dépendance dans CC.Net afin que les produits A et B n'essaient pas de générer si la version Utilities est endommagée. Cela fournit un retour un peu plus rapide que quelque chose ne va pas.