Centraliser/contrôler des constructions arbitraires de projets et de solutions .NET

Question

Au fil des années, j'ai créé et peaufiné un ensemble de scripts NAnt pour réaliser des projets complets. Le script principal prend un point d'extrémité d'application unique (un projet d'application Web par exemple) et en compile une version complète, à partir du contrôle de source. Les scripts sont préconfigurés avec les informations nécessaires concernant les emplacements de sortie de construction, les adresses de contrôle de source, etc. Le point principal est que vous pouvez lui fournir très peu d'informations et construire un projet donné à partir de zéro. Cela satisfait la partie "arbitraire" de ma question.

Dans le passé, j'ai travaillé pour des entreprises qui produisent quelques produits logiciels (principalement des applications web). Cet environnement se prête très bien à une configuration d'intégration continue typique où il y a un intégrateur pour chaque produit. J'ai mis en place des intégrateurs qui serviront à la fois de builds CI et d'intégrateurs pour gérer un build complet et un déploiement de QA. Ces intégrateurs utilisent les scripts de build principaux, de sorte que les intégrateurs eux-mêmes ne sont rien de plus que la surveillance du contrôle des sources et un appel au script maître NAnt.

Je travaille maintenant pour un groupe de développement qui crée de nombreuses applications. Souvent, les développeurs sont appelés à prendre en charge des applications créées à l'origine par d'autres. Quand j'ai commencé il n'y avait pas de gestion de construction en place. Je suis dans une position particulièrement unique au sein du groupe en tant que développeur principal d'une équipe de 4 personnes pour la suite de produits d'une unité commerciale (environ une demi-douzaine de systèmes complets). J'ai implémenté CruiseControl.Net avec les scripts de build principaux pour faire les deux versions de CI ainsi que les versions RC. Cela fonctionne pour l'ensemble fixe de projets au sein de la suite de produits de l'entreprise.

J'utilise CCNet depuis de nombreuses années maintenant, donc je suis pleinement conscient de ce qu'il peut faire. J'ai un grand respect pour sa contribution à l'arène de l'intégration continue car je l'utilise pour tous les projets de ma suite de produits. J'ai souligné à mon équipe l'utilisation de l'intégrateur de construction RC officiel en tant que maître d'œuvre pour tout ce qui est destiné à un autre endroit que le développement. Ceci fournit un grand contrôle sur l'ensemble fixe de projets qui sont sous le contrôle de CCNet.

Cependant, d'autres développeurs développent d'autres applications. Certains d'entre eux sont des projets de développement qui ne sont souvent même pas dans le contrôle de la source avant le début du cycle de vie du projet (autre chose que j'essaie de changer). Beaucoup de ces projets sont des projets uniques qui n'auront pas une grande partie du développement une fois qu'ils auront été déployés. Malgré cela, ils auront toujours besoin d'être soutenus. Le fait que sans la gestion centralisée de la construction de ces projets, le candidat à la mise à l'épreuve élabore des stratégies d'assurance de la qualité et, éventuellement, que la production soit laissée sur des machines de développement individuelles est essentiel. Ceci, bien sûr, fournit aucune garantie que tout est dans le contrôle de la source parmi les autres facteurs d'une construction de machine de développement. Le problème que j'ai essayé de résoudre est le suivant: quel type de système puis-je utiliser pour fournir un contrôle centralisé sur ces sortes de constructions arbitraires? Ce n'est certainement pas un problème unique. Cependant, dans une grande partie de la lecture que j'ai faite sur les builds centralisés, l'automatisation des builds et l'intégration continue, l'accent est mis sur les projets/produits fixes et la tâche de supporter le développement continu sur ceux-ci. Quels types de processus sont utilisés par les entreprises qui font du développement sur de nouveaux projets en permanence? N'utilisent-ils pas ces types de processus? Bien que les scripts de build principaux résident sur le serveur de génération, ils sont maladroits à utiliser. Aussi je préférerais limiter l'accès de la console au serveur de construction. Ainsi, un système de gestion est nécessaire pour fournir un accès plus facile à l'exécution de builds arbitraires sur un système central.

Je me rends compte que ce que je cherche peut être sous la couverture de MS Team Build. Malheureusement, chaque fois que je commence à lire à ce sujet, j'éprouve un sentiment de rapidité quand je commence à m'introduire dans le matériel marketing de MS et je me perds rapidement, ne sachant jamais vraiment ce que je veux faire.De plus, les coûts de licence ont été abordés comme un bouchon de spectacle probable dans certaines discussions générales passées sur le sujet de Team Foundation Server et Team System.

Je suis impatient d'entendre parler de quelqu'un qui a résolu ce problème et qui pourrait offrir des suggestions. J'ai fait du travail sur un système de construction centralisé basé sur mes scripts de construction "build-any-project". Cependant, ce que j'ai est à ses débuts et a été construit pour soutenir principalement seulement les types de projets que je travaille sur. Il manque le type de support requis à ce stade pour gérer de nombreux types d'applications ou la pléthore de configurations de projet/solution possibles avec Visual Studio.

Answer 1

Le plus gros problème que je vois avec un système de construction central est que même avec la meilleure volonté du monde, les outils vont diverger entre les équipes ou au fil du temps.

Je suis favorable à la conception de tout système de construction pour un projet particulier, de sorte qu'il nécessite l'extraction d'un seul module, par exemple. MyProjectBuildEnvironment, puis en exécutant un seul script d'une manière très neutre par rapport à l'outil, par exemple. sur un système Windows build.bat

Dans la mesure du possible, tous les outils utilisés par l'environnement de construction doivent être exécutables simplement en vérifiant le module MyProjectBuildEnvironmen plutôt que d'exiger des installateurs de niveau machine.

Ces deux contraintes n'empêcheront pas les équipes d'utiliser les outils qu'elles préfèrent à un moment donné.

Le système de compilation central peut alors être un système simple qui vérifie un module par projet et exécute simplement le fichier build.bat. Vous pourriez l'appeler un système de méta-construction. Pour être honnête, il serait probablement exagéré car un simple wiki décrivant le nom du module de construction pour chaque projet suffirait à permettre à quiconque de vérifier ce module et de le lancer par la commande commune build.bat. En guise de note finale, le script de démarrage doit toujours examiner l'environnement et indiquer à l'utilisateur si des outils sont manquants ou si une configuration de machine doit être modifiée pour terminer la construction.