[C#] Comment et pourquoi est-ce que je mets en place une machine de construction C #?



Answers

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, supprime le besoin de scripts msbuild)
  2. NAnt (mieux que la bibliothèque de syntaxe / tâche XML que MSBuild) Possède également des options pour les opérations de contrôle src P4
  3. CruiseControl.net - construit dans le tableau de bord web pour surveiller / démarrer les builds.

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

Sur la justification: Cela enlève la charge aux développeurs qui font des constructions manuelles et fait beaucoup pour éliminer l'erreur humaine 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 construire et libérer un logiciel est primordial. Je suis sûr que vous avez été des endroits où ils construisent le logiciel à la main et il sort dans la nature, seulement pour que votre gars de construction dise "Oups, je dois avoir oublié 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 construction de premier ordre, peu importe 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 démarrage d'une génération. Le véritable problème consiste donc à conserver les historiques 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. Habituellement doit être fait tous les 3-4 mois.

Sur les notifications de build: Ceci est intégré à CCNet, mais si vous souhaitez ajouter des tests automatisés en tant qu'étape supplémentaire, intégrez-le dans le projet dès le début. Il est extrêmement difficile d'ajuster les tests une fois qu'un projet devient important. Il y a énormément d'informations sur les frameworks de test (probablement aussi une tonne d'infos sur le SO), donc je vais différer de nommer des outils spécifiques.

Question

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 construction qui fera les builds et les tests du projet tous les soirs, parce que je comprends que c'est une bonne chose. Le problème est que nous n'avons pas beaucoup de budget ici, donc je dois justifier les dépenses pour les pouvoirs en place. Donc je veux savoir:

  • De quel type d'outils / licences aurai-je besoin? À l'heure actuelle, nous utilisons Visual Studio et Smart Assembly pour construire, et Perforce pour le contrôle des sources. Ai-je besoin d'autre chose ou y a-t-il un équivalent d'un travail cron pour exécuter des scripts automatisés?
  • Qu'est-ce que ça va me donner, sinon une indication d'une construction cassée? Dois-je configurer des projets de test dans cette solution (fichier sln) qui seront exécutés par ces scripts, afin que je puisse tester certaines fonctions? Nous avons, en ce moment, deux tests de ce genre, car nous n'avons pas eu le temps (ou franchement, l'expérience) de faire de bons tests unitaires.
  • De quel type de matériel aurai-je besoin pour cela?
  • Une fois qu'une construction a été terminée et testée, est-ce une pratique courante de mettre cette construction sur un site FTP ou d'avoir un autre moyen d'accès interne? L'idée est que cette machine fait la construction, et nous y allons tous, mais nous pouvons faire des builds de débogage si nous le devons.
  • Combien de fois devrions-nous faire ce genre de construction?
  • Comment l'espace est-il géré? Si nous faisons des constructions nocturnes, devrions-nous garder autour de toutes les anciennes constructions, ou commencer à les abandonner après environ une semaine ou deux?
  • Y a-t-il autre chose que je ne vois pas ici?

    Je me rends compte que c'est un très grand sujet, et je ne fais que commencer. Je ne pourrais pas trouver un double 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: J'ai finalement réussi à le faire fonctionner! Hudson est complètement fantastique, et FxCop montre que certaines fonctionnalités que nous pensions avoir été implémentées étaient réellement 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 depuis la ligne de commande, vous pouvez le mettre dans hudson. Rendre la construction exécutée à partir de la ligne de commande via MSBuild est un exercice utile en soi, car il oblige vos outils à être à jour.




  • Juste essayer de construire un peu sur ce que mjmarsh a dit, puisqu'il a jeté une grande fondation ...

    • Visual Studio. MSBuild fonctionne bien.
    • NAnt .
    • NantContrib . Cela fournira des tâches supplémentaires telles que les opérations Perforce.
    • CruiseControl.net . Ceci est encore fondamentalement votre "tableau de bord de construction".

    Tout ce qui précède (sauf pour VS) est open source, donc vous ne cherchez pas de licences supplémentaires.

    Comme l'a mentionné Earwicker, construisez tôt, construisez souvent. Sachant que quelque chose s'est cassé, et vous pouvez produire un livrable est utile pour attraper des choses au début.

    NAnt inclut également des tâches pour nunit / nunit2 , ce qui vous permet d'automatiser vos tests unitaires. Vous pouvez ensuite appliquer des feuilles de style aux résultats, et avec l'aide du framework fourni par CruiseControl.net, avoir des résultats de tests unitaires lisibles et imprimables pour chaque build.

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

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

    L'idée est d'automatiser la construction autant que possible, parce que les êtres humains font des erreurs. Le temps passé à l'avant est le temps économisé sur la route. Les gens ne sont pas obligés de garder le build 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 met également toutes vos constructions dans un seul endroit, ce qui est bon à des fins de comparaison. Quelque chose a cassé dans Build 426 qui a bien fonctionné dans Build 380? Eh bien, il y a les livrables prêts pour les tests - attrapez-les et testez.




    Comment? Jetez un oeil sur le blog Carel Lotz.

    Pourquoi? Il y a plusieurs raisons que je peux penser à:

    • Une construction fonctionnelle, lorsqu'elle est correctement implémentée, signifie que tous vos développeurs peuvent construire sur leur machine lorsque la construction est verte
    • Une version fonctionnelle, lorsqu'elle est correctement implémentée, signifie que vous êtes prêt à déployer à tout moment
    • Une version fonctionnelle, lorsqu'elle est correctement implémentée, signifie que tout ce que vous libérez a fait un tour à votre système de contrôle de source.
    • Une construction fonctionnelle, lorsqu'elle est correctement mise en œuvre, signifie que vous intégrez tôt et souvent, ce qui réduit votre risque d'intégration.

    L'article de Martin Fowler sur l' intégration continue reste le texte définitif. Regardez-le!




    Tout est sur la santé de la construction. Ce que vous obtenez est que vous pouvez configurer tout type de choses que vous voulez arriver avec les builds. Parmi ceux-ci, vous pouvez exécuter des tests, une analyse statique et un profileur. 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 dira presque où vous l'avez cassé :)

    Cela suppose, bien sûr, que vous le configuriez à chaque vérification (intégration continue).

    Cela peut également aider à rapprocher QA et Dev. Comme vous pouvez configurer des tests fonctionnels pour fonctionner avec, ainsi que profiler et tout ce qui améliore la rétroaction à l'équipe de développement. Cela ne signifie pas que les tests fonctionnels se déroulent à chaque vérification (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, donc dans mon cas, nous collaborons encore plus étroitement.




    Links