Comment et pourquoi configurer une machine de génération C #?

Je travaille avec une petite équipe de développement (4 personnes) sur un projet C #. J’ai proposé de mettre en place une machine de génération qui effectuera des tests et des builds nocturnes du projet, car je comprends que c’est une bonne chose. Le problème, c’est que nous n’avons pas beaucoup de budget ici, alors je dois justifier les dépenses pour les pouvoirs en place. Alors je veux savoir:

  • De quel type d’outils / licences aurai-je besoin? En ce moment, nous utilisons Visual Studio et Smart Assembly pour construire et Perforce pour le contrôle des sources. Aurai-je besoin d’autre chose, ou existe-t-il un équivalent d’une tâche cron pour exécuter des scripts automatisés?
  • Qu’est-ce que cela m’apportera, à part une indication de construction cassée? Dois-je configurer des projets de test dans cette solution (fichier sln) qui sera exécutée par ces scripts, afin de pouvoir tester certaines fonctions? Nous avons actuellement deux tests de ce type, car nous n’avons pas eu le temps (ou franchement l’expérience) de faire de bons tests unitaires.
  • Quel type de matériel aurai-je besoin pour cela?
  • Une fois la construction terminée et testée, est-ce une pratique courante de mettre cette compilation sur un site ftp ou d’avoir un autre moyen d’access interne? L’idée est que cette machine fait la construction, et nous y allons tous, mais nous pouvons faire des mises au point si nécessaire.
  • À quelle fréquence devrions-nous faire ce genre de construction?
  • Comment l’espace est-il géré? Si nous construisons des pièces de nuit, devrions-nous garder tous les anciens bâtiments ou commencer à les laisser tomber après environ une semaine?
  • Y a-t-il autre chose que je ne vois pas ici?
  • Je me rends compte que c’est un sujet très vaste, et je commence tout juste. Je ne pouvais pas trouver une copie de cette question ici, et s’il y a un livre là-bas, je devrais juste obtenir, s’il vous plaît faites le moi savoir.

    EDIT: Je l’ai enfin fait fonctionner! Hudson est complètement fantastique et FxCop montre que certaines fonctionnalités que nous pensions avoir été implémentées étaient en réalité incomplètes. Nous avons également dû changer le type d’installateur de Old-And-Busted vdproj à New Hotness WiX.

    Fondamentalement, pour ceux qui font attention, si vous pouvez exécuter votre build à partir de la ligne de commande, vous pouvez le mettre dans hudson. L’exécution de la construction à partir de la ligne de commande via MSBuild est un exercice utile en soi, car il oblige vos outils à être à jour.

    Mise à jour: Jenkins est la version la plus récente d’Hudson. Tout le monde devrait utiliser Jenkins maintenant. Je mettrai à jour les liens en conséquence.

    Hudson est gratuit et extrêmement facile à configurer et s’exécutera facilement sur une VM.

    En partie d’un ancien poste de mien:

    Nous l’utilisons pour

    • Déployer des services Windows
    • Déployer des services Web
    • Exécutez MSTests et affichez autant d’informations que les tests de Junit
    • Gardez une trace des tâches faibles, moyennes et élevées
    • avertissements et erreurs du graphique de tendance

    Voici quelques exemples de fichiers .net intégrés supportés par Hudson

    • MSBuild
    • NAnt
    • MSTest
    • Nunit
    • Team Foundation Server
    • fxcop
    • stylecop
    • avertissements du compilateur
    • tâches de code

    Aussi, que Dieu vous en préserve, vous utilisez la source visuelle sécurisée, elle le supporte également . Je vous recommande de consulter l’article de Redsolo sur la construction de projets .net avec Hudson

    Vos questions

    • Q : Quels types d’outils / licences ai-je besoin? En ce moment, nous utilisons Visual Studio et Smart Assembly pour construire et Perforce pour le contrôle des sources. Aurai-je besoin d’autre chose, ou existe-t-il un équivalent d’une tâche cron pour exécuter des scripts automatisés?

    • R: Je viens d’installer Visual Studio sur une nouvelle copie d’une VM exécutant une nouvelle installation du système d’exploitation Windows Server. Il vous faut donc les licences pour gérer cela. Hudson s’installera sous la forme d’un service Windows et s’exécutera sur le port 8080 et vous configurerez la fréquence à laquelle vous souhaitez qu’il parsing votre référentiel de code pour le code mis à jour, ou vous pouvez lui demander de générer à un moment donné. Tous configurables via le navigateur.

    • Q: Qu’est-ce que cela va me rapporter, à part une indication de construction brisée? Dois-je configurer des projets de test dans cette solution (fichier sln) qui sera exécutée par ces scripts, afin de pouvoir tester certaines fonctions? Nous avons actuellement deux tests de ce type, car nous n’avons pas eu le temps (ou franchement l’expérience) de faire de bons tests unitaires.

      R: Vous recevrez un email la première fois qu’un build échoue ou devient instable. Une génération est instable si un test unitaire échoue ou peut être marqué comme étant instable par le nombre de critères que vous définissez. Lorsqu’un test d’unité ou de construction échoue, vous serez envoyé par e-mail et il vous indiquera où, pourquoi et comment il a échoué. Avec ma configuration, nous obtenons:

      • liste de tous les commits depuis la dernière version de travail
      • commettre des notes de ces commits
      • liste des fichiers modifiés dans les commits
      • sortie de la console à partir du build lui-même, montrant l’erreur ou l’échec du test
    • Q: Quel matériel ai-je besoin pour cela?

      A: une VM suffira

    • Q: Une fois la construction terminée et testée, est-ce une pratique courante de mettre cette compilation sur un site ftp ou d’avoir un autre moyen d’access interne? L’idée est que cette machine fait la construction, et nous y allons tous, mais nous pouvons faire des mises au point si nécessaire.

      A: Hudson peut faire tout ce que vous voulez avec cela, y compris l’identifier via le hachage md5, le télécharger, le copier, l’archiver, etc. Il le fait automatiquement et vous fournit un long historique des artefacts de construction.

    • Q: À quelle fréquence devrions-nous faire ce genre de construction?

      A: Nous avons notre sondage SVN toutes les heures, recherchant les changements de code, puis exécutant une génération. La nuit est bonne, mais une OMI sans valeur puisque ce que vous avez travaillé hier ne sera pas frais dans votre esprit quand vous entrez.

    • Q: Comment l’espace est-il géré? Si nous construisons des pièces de nuit, devrions-nous garder tous les anciens bâtiments ou commencer à les laisser tomber après environ une semaine?

      R: C’est à vous, après tant de temps que je déplace nos artefacts de construction sur le stockage à long terme ou les supprime, mais toutes les données stockées dans des fichiers texte / xml que je garde etc sur le serveur avec un espace restreint consommé. Vous pouvez également configurer Hudson pour ne garder que les artefacts d’un nombre de builds supérieur.

    • Q: Y a t-il autre chose que je ne vois pas ici?

      A: Non, allez chercher Hudson maintenant, vous ne serez pas déçu!

    Nous avons eu beaucoup de chance avec le combo suivant:

    1. Visual Studio (en particulier, en utilisant l’outil de ligne de commande MSBuild.exe et en lui transmettant nos fichiers de solution, cela supprime le besoin de scripts msbuild)
    2. NAnt (comme la bibliothèque de syntaxe / tâche XML mieux que MSBuild. Possède également des options pour les opérations de contrôle src P4)
    3. CruiseControl.net – tableau de bord Web intégré pour la surveillance et le démarrage des versions.

    CCNet a intégré des notificateurs pour envoyer des e-mails lorsque les builds réussissent / échouent

    Sur la justification: Cela prend la charge des développeurs qui font des constructions manuelles et fait beaucoup pour éliminer les erreurs humaines de l’équation. Il est très difficile de quantifier cet effet, mais une fois que vous le faites, vous ne reviendrez jamais. Avoir un processus reproductible pour créer et publier des logiciels est primordial. Je suis sûr que vous avez été des endroits où ils construisent le logiciel à la main et que ça se passe à l’état sauvage, seulement pour que votre gars de la construction dise “Oups, j’ai dû oublier d’inclure cette nouvelle DLL!”

    Sur le matériel: aussi puissant que possible. Plus de puissance / mémoire = temps de construction plus rapides. Si vous pouvez vous le permettre, vous ne regretterez jamais d’avoir une machine de qualité, quelle que soit la taille du groupe.

    Sur l’espace: aide à avoir beaucoup d’espace disque. Vous pouvez créer vos scripts NAnt pour supprimer les fichiers intermédiaires chaque fois qu’une génération démarre. Par conséquent, le véritable problème consiste à conserver l’historique des journaux et les anciens programmes d’installation des applications. Nous avons un logiciel qui surveille l’espace disque et envoie des alertes. Ensuite, nous nettoyons le lecteur manuellement. Doit généralement être fait tous les 3-4 mois.

    Sur les notifications de construction: ceci est intégré à CCNet, mais si vous souhaitez append des tests automatisés en tant qu’étape supplémentaire, intégrez-les dès le départ dans le projet. Il est extrêmement difficile d’appliquer des tests d’aptitude une fois que le projet est grand. Il y a des tonnes d’informations sur les frameworks de test disponibles (probablement une tonne d’informations sur SO), donc je vais me contenter de nommer des outils spécifiques.

    Sur mon lieu de travail précédent, nous utilisions TeamCity . C’est très facile et puissant à utiliser. Il peut être utilisé gratuitement avec certaines ressortingctions. Il y a aussi un tutoriel sur Dime Casts . La raison pour laquelle nous n’avons pas utilisé CruiseControl.NET est que nous avions beaucoup de petits projets et il est très difficile de les définir dans CC.NET. Je recommande vivement TeamCity. Pour résumer, si vous vous dirigez vers l’open source, CC.NET est le grand-père avec une courbe d’apprentissage légèrement supérieure. Si votre budget le permet, optez pour TeamCity ou consultez la version gratuite.

    Comment? Consultez le blog de Carel Lotz.

    Pourquoi? Il y a plusieurs raisons auxquelles je peux penser:

    • Une version de travail correctement implémentée signifie que tous vos développeurs peuvent construire sur leur machine lorsque la version est verte.
    • Une version de travail correctement implémentée signifie que vous êtes prêt à être déployé à tout moment
    • Une version de travail correctement implémentée signifie que tout ce que vous publiez a fait un voyage vers votre système de contrôle de code source.
    • Une mise en œuvre efficace, lorsqu’elle est correctement mise en œuvre, signifie que vous vous intégrez rapidement et souvent, réduisant ainsi le risque d’intégration.

    L’article de Martin Fowler sur l’ continuous integration rest le texte définitif. Regardez-le!

    L’argument principal en faveur est que cela réduira le coût de votre processus de développement, en vous alertant le plus rapidement possible de la fin de la construction ou de l’échec des tests.

    Le problème de l’intégration du travail de plusieurs développeurs est le principal danger de la croissance d’une équipe. Plus l’équipe est grande, plus il est difficile de coordonner son travail et de les empêcher de changer les uns avec les autres. La seule bonne solution consiste à leur dire de «s’intégrer tôt et souvent», en enregistrant de petites unités de travail (parfois appelées «histoires») au fur et à mesure de leur achèvement.

    Vous devez faire en sorte que la machine de génération se régénère CHAQUE fois certaines vérifications, tout au long de la journée. Avec Cruise Control, vous pouvez obtenir une icône dans votre barre des tâches qui devient rouge (et vous parle même!) Lorsque la construction est interrompue.

    Vous devez ensuite effectuer une compilation complète de nuit où la version source est étiquetée (avec un numéro de version unique) que vous pouvez choisir de publier pour vos parties prenantes (responsables de produits, responsables de l’assurance qualité). C’est ainsi que lorsqu’un rapport est signalé, il est associé à un numéro de build connu (c’est extrêmement important).

    Idéalement, vous devriez avoir un site interne où les versions peuvent être téléchargées et un bouton sur lequel vous pouvez cliquer pour publier la version précédente.

    J’essaie juste de construire un peu sur ce que mjmarsh a dit, depuis qu’il a jeté une grande fondation …

    • Visual Studio. MSBuild fonctionne bien.
    • NAnt
    • NantConsortingb . Cela fournira des tâches supplémentaires telles que les opérations Perforce.
    • CruiseControl.net . C’est à nouveau essentiellement votre “tableau de bord de construction”.

    Tout ce qui précède (sauf pour VS) est open source, vous ne regardez donc aucune licence supplémentaire.

    Comme Earwicker l’a mentionné, construisez tôt, construisez souvent. Il est utile de savoir que quelque chose est cassé et que vous pouvez produire un produit livrable dès le début.

    NAnt inclut également des tâches pour nunit / nunit2 , de sorte que vous pouvez réellement automatiser vos tests unitaires. Vous pouvez ensuite appliquer des feuilles de style aux résultats et, à l’aide de la structure fournie par CruiseControl.net, obtenir des résultats de test unitaires lisibles et imprimables pour chaque version.

    La même chose s’applique à la tâche ndoc . Ayez votre documentation produite et disponible pour chaque version.

    Vous pouvez même utiliser la tâche exec pour exécuter d’autres commandes, par exemple, produire un Windows Installer à l’aide d’InstallShield.


    L’idée est d’automatiser la construction autant que possible, car les êtres humains font des erreurs. Le temps passé devant vous est un gain de temps. Les gens n’ont pas besoin de garder la construction en main en passant par le processus de construction. Identifiez toutes les étapes de votre construction, créez des scripts NAnt pour chaque tâche et créez vos scripts NAnt un par un jusqu’à ce que vous ayez entièrement automatisé votre processus de construction. Il place ensuite toutes vos builds dans un seul endroit, ce qui est bon à des fins de comparaison. Quelque chose dans Build 426 qui a bien fonctionné dans Build 380? Eh bien, il existe des livrables prêts à être testés – prenez-les et testez-les.

    • Aucune licence requirejse. CruiseControl.net est disponible gratuitement et n’a besoin que du sdk .NET pour être construit.
    • Un serveur de génération, même sans tests unitaires automatisés, fournit toujours un environnement contrôlé pour la génération des versions. Pas plus “John construit habituellement sur sa machine mais il est malade. Pour une raison quelconque, je ne peux pas construire sur ma machine”
    • En ce moment, j’en ai un installé dans une session Virtual PC.
    • Oui. La construction doit être déversée dans un endroit accessible. Les mises au sharepoint développement doivent être activées. La version de publication doit être désactivée.
    • Combien de fois est à vous. Si vous le configurez correctement, vous pouvez générer très peu de temps supplémentaire après chaque enregistrement. C’est une excellente idée si vous avez (ou envisagez d’avoir) des tests unitaires en place.
    • Conservez les jalons et les versions aussi longtemps que nécessaire. Tout dépend de la fréquence à laquelle vous construisez: en continu? jeter. Du quotidien? Gardez une semaine de valeur. Hebdomadaire? Gardez deux mois.

    Plus votre projet est important, plus vous verrez les avantages d’une machine automatisée.

    Il s’agit de la santé de la construction. Ce que cela vous amène, c’est que vous pouvez configurer tout type de choses que vous voulez faire avec les builds. Parmi ceux-ci, vous pouvez exécuter des tests, des parsings statiques et des profils. Les problèmes sont traités beaucoup plus rapidement lorsque vous avez récemment travaillé sur cette partie de l’application. Si vous commettez de petits changements, cela vous dit presque où vous l’avez cassé 🙂

    Cela suppose bien sûr que vous le configuriez pour construire à chaque enregistrement (continuous integration).

    Cela peut aussi aider à rapprocher QA et Dev. Comme vous pouvez configurer des tests fonctionnels pour exécuter avec, ainsi que profileur et tout ce qui améliore la rétroaction à l’équipe de développement. Cela ne signifie pas que les tests fonctionnels s’exécutent à chaque enregistrement (cela peut prendre un certain temps), mais vous configurez des builds / tests avec des outils communs à toute l’équipe. J’ai automatisé les tests de fumée, alors dans mon cas, nous collaborons encore plus étroitement.

    Pourquoi: Il y a 10 ans, en tant que développeurs de logiciels, nous avions analysé quelque chose au troisième degré pour obtenir que les documents (écrits dans un langage humain) soient «signés», puis que le code commence à être écrit. Nous procéderions à des tests unitaires, à des tests de chaînes de caractères et ensuite nous testerions le système: la première fois que le système dans son ensemble serait exécuté ensemble, parfois des semaines ou des mois après la signature des documents. Ce n’est qu’à ce moment-là que nous avons découvert toutes les hypothèses et tous les malentendus que nous avions lorsque nous avons tout analysé.

    L’continuous integration sous forme d’idée vous amène à créer un système complet (bien que, dans un premier temps, très simple) de bout en bout. Au fil du temps, la fonctionnalité du système est construite orthogonalement. Chaque fois que vous effectuez un build complet, vous effectuez le test du système tôt et souvent. Cela signifie que vous trouvez et corrigez les bogues et les hypothèses dès que possible, lorsque le moment est le moins cher pour les résoudre.

    Comment: En ce qui concerne le comment, j’ai blogué à ce sujet il y a un peu de temps: [ cliquez ici ]

    Plus de 8 articles, étape par étape, expliquent comment configurer un serveur Jenkins dans un environnement Windows pour les solutions .NET.