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





build continuous-integration build-automation hudson (9)


Mise à jour: Jenkins est la version la plus à jour de 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 fonctionnera facilement sur une machine virtuelle.

En partie d'un ancien poste de la mienne:

Nous l'utilisons pour

  • Déployer les services Windows
  • Déployer des services Web
  • Exécutez MSTests et affichez autant d'informations que n'importe quel test de junit
  • Gardez une trace des tâches basses, med, high
  • avertissements et erreurs trendgraph

Voici quelques-unes des choses intégrées .net que Hudson prend en charge

En outre, Dieu vous interdise d'utiliser la source visuelle en toute sécurité, il prend également cela en charge . Je vous recommande de jeter un oeil à l'article de Redsolo sur la construction de projets .net en utilisant Hudson

Vos questions

  • Q : De quel type d'outils / de 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?

  • R: Je viens d'installer Visual Studio sur une nouvelle copie d'une machine virtuelle exécutant une nouvelle installation d'un système d'exploitation Windows Server. Donc, vous auriez besoin des licences pour gérer cela. Hudson s'installe en tant que service Windows et s'exécute sur le port 8080 et vous configurerez la fréquence à laquelle vous voulez qu'il scanne votre référentiel de code pour le code mis à jour, ou vous pouvez le configurer pour le construire à un certain moment. Tout est configurable via le navigateur.

  • Q: Qu'est-ce que ça va me donner, à part 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.

    R: Vous recevrez un email la première fois qu'un build échoue ou devient instable. Une construction est instable si un test d'unité échoue ou qu'elle peut être marquée comme instable par n'importe quel nombre de critères que vous avez définis. Quand un test ou une construction échoue, vous recevrez un email et il vous dira où, pourquoi et comment il a échoué. Avec ma configuration, nous obtenons:

    • liste de tous les commits depuis la dernière construction de travail
    • commettre des notes de ces commits
    • liste des fichiers modifiés dans les commits
    • sortie de la console de la construction elle-même, montrant l'erreur ou l'échec du test
  • Q: De quel type de matériel aurai-je besoin pour cela?

    A: Une VM suffira

  • Q: 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.

    R: Hudson peut faire ce que vous voulez, y compris l'ID via le hachage md5, le télécharger, le copier, l'archiver, etc. Il le fait automatiquement et vous fournit un historique des artefacts de construction.

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

    R: Nous avons notre sondage SVN toutes les heures, en cherchant les changements de code, puis en exécutant une build. Nightly est ok, mais un peu OMI peu utile puisque ce que vous avez travaillé hier ne sera pas frais dans votre esprit le matin quand vous entrez.

  • Q: 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?

    R: Cela dépend de vous, après si longtemps je déplace nos artefacts de construction vers le stockage à long terme ou les supprime, mais toutes les données stockées dans les fichiers texte / xml me permettent de stocker le changelog, les graphiques de tendance, etc sur le serveur avec verrrry peu d'espace consommé. Vous pouvez également configurer Hudson pour ne conserver que les artefacts d'un nombre final de builds

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

    R: Non, va chercher Hudson maintenant, tu ne seras pas déçu!

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.




  • Dans mon ancien lieu de travail, nous avons utilisé TeamCity . C'est très facile et puissant à utiliser. Il peut être utilisé gratuitement avec certaines restrictions. Il y a aussi un tutoriel sur Dime Casts . La raison pour laquelle nous n'avons pas utilisé CruiseControl.NET est que nous avons eu beaucoup de petits projets et qu'il est assez pénible de les mettre en place dans CC.NET. Je recommande vivement TeamCity. Pour récapituler si vous êtes vers l'open source alors CC.NET est le grand papa avec la courbe d'apprentissage légèrement supérieure. Si votre budget vous permet d'aller avec TeamCity ou consultez la version gratuite.




    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!




    Pourquoi: il y a 10 ans, en tant que développeurs de logiciels, nous analysions quelque chose au nième degré, obtenions des documents (écrits dans un langage humain), puis nous commençions à écrire du code. Nous ferions un test unitaire, un test de chaîne et ensuite nous passerions au test du système: la première fois que le système dans son ensemble fonctionnerait ensemble, parfois une semaine ou des mois après la signature des documents. Ce n'est qu'alors que nous avons découvert toutes les hypothèses et les malentendus que nous avions quand nous avons analysé tout.

    L'intégration continue sous forme d'idée vous permet de construire un système complet (bien que très simple au départ) de bout en bout. Au fil du temps, la fonctionnalité du système est construite orthogonalement. Chaque fois que vous faites une construction complète, vous faites le test du système tôt et souvent. Cela signifie que vous trouvez et réparez les bugs et les suppositions le plus tôt possible, quand c'est le moment le moins cher pour les réparer.

    Comment: En ce qui concerne le comment, j'ai blogué à ce sujet il y a quelques temps: [ Cliquez ici ]

    Plus de 8 articles vont pas à pas sur la façon de configurer un serveur Jenkins dans un environnement Windows pour les solutions .NET.




    Le principal argument en faveur est qu'il va réduire le coût de votre processus de développement, en vous alertant dès que possible que vous avez une construction cassée ou des tests qui échouent.

    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 l'empêcher de jouer les uns avec les autres. La seule bonne solution consiste à leur dire «d'intégrer tôt et souvent», en vérifiant de petites unités de travail (parfois appelées «histoires») à mesure qu'elles sont complétées.

    Vous devriez faire en sorte que la machine de compilation reconstruise CHAQUE fois des contrôles, tout au long de la journée. Avec Cruise Control, vous pouvez obtenir une icône sur votre barre des tâches qui devient rouge (et même vous parle!) Lorsque la construction est cassée.

    Vous devriez ensuite faire une compilation complète et nocturne où la version source est étiquetée (avec un numéro de build unique) que vous pouvez choisir de publier à vos parties prenantes (chefs de produit, responsables de l'assurance qualité). C'est ainsi que lorsqu'un bug est signalé, c'est contre un numéro de build connu (c'est extrêmement important).

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




    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.




    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.




    Une autre fonction, pas par moi mais trouvée sur le web et affinée un peu:

    public static int GetAge(DateTime birthDate)
    {
        DateTime n = DateTime.Now; // To avoid a race condition around midnight
        int age = n.Year - birthDate.Year;
    
        if (n.Month < birthDate.Month || (n.Month == birthDate.Month && n.Day < birthDate.Day))
            age--;
    
        return age;
    }
    

    Juste deux choses qui me viennent à l'esprit: Qu'en est-il des gens de pays qui n'utilisent pas le calendrier grégorien? DateTime.Now est dans la culture spécifique au serveur, je pense. Je n'ai absolument aucune connaissance sur le fait de travailler avec les calendriers asiatiques et je ne sais pas s'il existe un moyen facile de convertir les dates entre les calendriers, mais juste au cas où vous vous poseriez des questions sur les chinois de l'année 4660 :-)





    c# build continuous-integration build-automation hudson