Comment et pourquoi configurer une machine de compilation C #? [fermé]

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 effectuera des constructions et des tests 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 la dépense aux pouvoirs en place. Je veux donc savoir:

De quel type d'outils / de licences ai-je besoin? Pour le moment, nous utilisons Visual Studio et Smart Assembly pour construire et Perforce pour le contrôle de source. Aurai-je besoin de quelque chose d'autre ou existe-t-il un équivalent d'un travail cron pour exécuter des scripts automatisés?

Qu'est-ce que cela va me procurer exactement, mis à part l'indication d'un build cassé? Devrais-je configurer des projets de test dans cette solution (fichier sln) qui seront exécutés par ces scripts afin de pouvoir tester des fonctions particulières? Nous avons, pour le moment, deux tests de ce type, 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 ai-je besoin pour cela?

Une fois qu'une compilation est terminée et testée, est-ce une pratique courante de la mettre sur un site FTP ou de disposer d'un autre moyen pour un accès interne? L'idée est que cette machine crée la génération, et nous y allons tous, mais nous pouvons créer des versions de débogage si nécessaire.

À quelle fréquence devons-nous effectuer ce type de construction?

Comment l'espace est-il géré? Si nous faisons des constructions nocturnes, devrions-nous garder toutes les anciennes constructions ou commencer à les abandonner après environ une semaine?

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

Je réalise qu’il s’agit d’un sujet très vaste et je viens tout juste de commencer. Je ne pouvais pas trouver un duplicata de cette question ici, et s'il y a un livre que je devrais obtenir, merci de me le faire savoir.

EDIT: Je l’ai enfin mis au travail! Hudson est complètement fantastique et FxCop montre que certaines fonctionnalités que nous pensions être 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.

En gros, pour ceux qui sont attentifs, si vous pouvez exécuter votre construction à partir de la ligne de commande, vous pouvez la placer dans hudson. Faire en sorte que la compilation soit exécutée à partir de la ligne de commande via MSBuild est un exercice utile en soi, car il oblige vos outils à être à jour.

    

Answer 1

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 machine virtuelle.

En partie d'un ancien poste à moi:

Nous l'utilisons pour

• Déployer les services Windows
• Déployer des services Web
• Exécuter MSTests & amp; afficher autant d'informations que les tests junit
• Gardez une trace des tâches faibles, moyennes et élevées
• avertissements et erreurs de TrendGraph

Voici quelques-uns des éléments .net intégrés pris en charge par Hudson

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

De plus, dieu ne vous empêche pas d'utiliser des sources visuelles sûres, prend en charge cela aussi . Je vous conseillerais de consulter celle de Redsolo article sur la construction de projets .net avec Hudson

Vos questions

• Q : De quel type d'outils / de licences ai-je besoin? Pour le moment, nous utilisons Visual Studio et Smart Assembly pour construire et Perforce pour le contrôle de source. Aurai-je besoin de quelque chose d'autre ou existe-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'un ordinateur virtuel exécutant une nouvelle installation corrigée d'un système d'exploitation Windows. Vous aurez donc besoin de licences pour gérer cela. Hudson s’installera lui-même comme un service Windows et fonctionnera sur le port 8080 et vous configurerez la fréquence à laquelle vous souhaitez analyser votre référentiel de code pour rechercher le code mis à jour, ou vous pouvez lui demander de construire à un moment donné. Tous configurables via le navigateur.

• Q: Qu'est-ce que cela va me procurer exactement, mis à part l'indication d'un build cassé? Devrais-je configurer des projets de test dans cette solution (fichier sln) qui seront exécutés par ces scripts afin de pouvoir tester des fonctions particulières? Nous avons, pour le moment, deux tests de ce type, car nous n’avons pas eu le temps (ni, franchement, l’expérience) de faire de bons tests unitaires.

  A: Vous recevrez un courrier électronique la première fois qu'une création échouera ou deviendrait instable. Une construction est instable si un test unitaire échoue ou si elle peut être marquée comme instable à l'aide d'un nombre quelconque de critères que vous avez définis. Lorsqu'un test unitaire ou une construction échoue, vous recevrez un courrier électronique qui vous indiquera où, pourquoi et comment cela a échoué. Avec ma configuration, nous obtenons:

  • liste de tous les commits depuis la dernière version de travail
  • commettez des notes de ces commits
  • liste des fichiers modifiés dans les commits
  • sortie de la console à partir de la construction elle-même, affichant l'erreur ou l'échec du test

• Q: De quel type de matériel ai-je besoin pour cela?

  A: Une machine virtuelle suffira

• Q: Une fois la construction terminée et testée, est-il courant de la créer sur un site ftp ou de disposer d'un autre moyen pour un accès interne? L'idée est que cette machine crée le build, et nous y allons tous, mais nous pouvons faire des builds de débogage si nécessaire.

  R: Hudson peut en faire ce que vous voulez, y compris en l'identifiant via le hachage md5, en le téléchargeant, en le copiant, en l'archivant, etc. Il le fait automatiquement et vous fournit avec une longue histoire d'artefacts de construction.

• Q: À quelle fréquence devons-nous effectuer ce type de construction?

  R: Nous avons notre SVN de sondage toutes les heures, nous recherchons les modifications de code, puis nous exécutons une construction. Tous les soirs, ça va, mais un peu sans intérêt pour l'OMI, car ce sur quoi vous avez travaillé hier ne sera pas frais dans votre esprit le matin lorsque vous entrerez.

• Q: Comment l'espace est-il géré? Si nous faisons des constructions nocturnes, devrions-nous conserver toutes les anciennes constructions ou les abandonner après environ une semaine?

  R: C’est à vous de décider. Après tout ce temps, je déplace ou déplace mes artefacts de construction vers un stockage à long terme, mais toutes les données stockées dans des fichiers texte / xml sont conservées, Cela me permet de stocker le journal des modifications, les graphiques de tendance, etc. sur le serveur avec très peu d'espace utilisé. Vous pouvez également configurer Hudson pour ne conserver que les artefacts d'un nombre de générations final

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

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

Answer 2

Nous avons eu beaucoup de chance avec le combo suivant:

1. Visual Studio (en particulier, utiliser l'outil de ligne de commande MSBuild.exe et le transmettre à nos fichiers de solution. élimine le besoin de scripts msbuild)
2. NAnt (comme la bibliothèque de syntaxe / de tâches XML meilleure que MSBuild. Possède également des options pour les opérations de contrôle P4 src )
3. CruiseControl.net - Tableau de bord Web intégré pour surveiller / démarrer les constructions.

CCNet a intégré des notificateurs pour envoyer des courriels lorsque la construction réussit / échoue

Sur justification: les développeurs qui effectuent des constructions manuelles décongestionnent ainsi que d’é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 en arrière. Avoir un processus reproductible pour construire et publier un logiciel est primordial. Je suis sûr que vous avez déjà créé le logiciel à la main et que tout se passe dans la nature, mais votre responsable de la compilation dit: "Oups, j’ai 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 en avez les moyens, vous ne regretterez jamais d'avoir une machine de construction de premier ordre, aussi petite que soit le groupe.

Espace: permet d’avoir beaucoup d’espace disque. Vous pouvez créer vos scripts NAnt pour supprimer les fichiers intermédiaires à chaque démarrage de la génération. Le vrai problème consiste donc à conserver l'historique des journaux et les anciens programmes d'installation d'applications. Nous avons un logiciel qui surveille l'espace disque et envoie des alertes. Ensuite, nous nettoyons le lecteur manuellement. Doit normalement être fait tous les 3-4 mois.

Notifications de construction: ceci est intégré à CCNet, mais si vous souhaitez ajouter des tests automatisés comme étape supplémentaire, intégrez-les dès le début au projet. Il est extrêmement difficile de faire des tests d’ajustement une fois qu’un projet est volumineux. Il y a des tonnes d'informations sur les frameworks de test (probablement une tonne d'informations sur SO également), je vais donc différer en nommant des outils spécifiques.

Answer 3

À mon ancien lieu de travail, nous utilisions TeamCity . C'est très facile et puissant à utiliser. Il peut être utilisé gratuitement avec certaines restrictions. Vous trouverez également un didacticiel sur les Dime Casts . Si nous n’avons pas utilisé CruiseControl.NET, c’est que nous avions beaucoup de petits projets et qu’il est très pénible de les configurer dans CC.NET. Je recommande fortement TeamCity. Pour résumer, si vous êtes en faveur de l'open source, alors CC.NET est le grand papa avec une courbe d'apprentissage légèrement supérieure. Si votre budget vous le permet, rendez-vous avec TeamCity ou consultez la version gratuite.

Answer 4

Comment? Consultez le blog de Carel Lotz .

Pourquoi? Je peux penser à plusieurs raisons:

• Une version fonctionnelle, lorsqu'elle est correctement implémentée, signifie que tous vos développeurs peuvent créer sur leur ordinateur lorsque la construction est verte
.
• Une version de travail, 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 publiez a été envoyé à votre système de contrôle de source.
• Une version fonctionnelle, lorsqu'elle est correctement implémentée, signifie que vous intégrez tôt et souvent, réduisant ainsi vos risques d'intégration.

L'article de Martin Fowler sur la Intégration continue reste le texte définitif. Jetez-y un coup d'oeil!

Answer 5

L'argument principal en faveur est que cela réduira le coût de votre processus de développement en vous alertant dès que possible de la construction cassée ou des tests en échec.

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 nombreuse, plus il est difficile de coordonner son travail et de l'empêcher de jouer avec les changements des uns et des 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 "récits") au fur et à mesure de leur achèvement.

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

Vous devez ensuite créer chaque nuit une version totalement propre dans laquelle la version source est étiquetée (à partir d'un numéro de version unique) que vous pouvez choisir de publier à vos parties prenantes (chefs de produit, responsables de l'assurance qualité). C’est ainsi que lorsqu'un bogue est signalé, il est contre un numéro de build connu (c’est extrêmement important).

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

Answer 6

J'essaie juste de construire un peu sur ce que mjmarsh a dit, car il a posé de grandes fondations ...

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

Tout ce qui précède (à l'exception de VS) est open source. Par conséquent, vous ne cherchez pas de licence supplémentaire.

Comme Earwicker l’a mentionné, construisez tôt, construisez souvent. Savoir quelque chose qui ne fonctionne pas et vous pouvez produire un produit livrable est utile pour attraper des choses très tôt.

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, à l’aide du cadre fourni par CruiseControl.net, obtenir des résultats de tests unitaires lisibles et imprimables pour chaque build.

Il en va de même pour la tâche ndoc . Ayez votre documentation produite et disponible, pour chaque construction.

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

L’idée est d’automatiser autant que possible la construction, car les êtres humains font des erreurs. Le temps passé à l’avant est un gain de temps sur la route. Les gens ne doivent pas garder la construction en passant par le processus de construction. Identifiez toutes les étapes de votre construction, créez des scripts NAnt pour chaque tâche et construisez-les un à un jusqu'à ce que vous ayez entièrement automatisé votre processus de construction. Il met également toutes vos versions au même endroit, ce qui est utile à des fins de comparaison. Quelque chose de cassé dans le build 426 qui a bien fonctionné dans le build 380? Les produits à livrer sont prêts à être testés. Prenez-les et testez-les.

Answer 7

• Aucune licence requise. CruiseControl.net est disponible gratuitement et ne nécessite que le 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 les versions de génération. Plus personne ne "John construit habituellement sur sa machine, mais il est malade. Pour une raison quelconque, je ne peux pas utiliser ma machine "
• À l'heure actuelle, j'en ai un dans une session Virtual PC.
• Oui. La construction doit être déposée dans un endroit accessible. Le débogage doit être activé pour les générations de développement. La version release devrait l'avoir désactivée.
• Combien de fois dépend de vous. Si la configuration est correcte, vous pouvez créer après chaque enregistrement une très légère surcharge. C’est une excellente idée si vous avez (ou envisagez de le faire) des tests unitaires en place.
• Conservez les jalons et les communiqués aussi longtemps que nécessaire. Tout le reste dépend de combien de fois vous construisez: en continu? jeter. Du quotidien? Gardez une semaine. Hebdomadaire? Gardez deux mois.

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

Answer 8

Tout dépend de la santé de la construction. Cela vous donne la possibilité de configurer tout type de choses que vous souhaitez voir se produire avec les versions. 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, il vous dira presque où vous l'avez cassé:)

Bien entendu, cela suppose que vous l'avez configuré pour construire à chaque enregistrement (intégration continue).

Cela peut également aider à rapprocher l’assurance qualité et le développement. Comme vous pouvez configurer des tests fonctionnels pour fonctionner avec, ainsi que le profileur et tout ce qui améliore le retour d'informations à l'équipe de développement. Cela ne signifie pas que les tests fonctionnels sont exécutés à chaque enregistrement (cela peut prendre un certain temps), mais que vous configurez des versions / tests avec des outils communs à toute l'équipe. J'ai automatisé les tests de détection de fumée et, dans mon cas, nous collaborons encore plus étroitement.

Answer 9

Pourquoi: Il y a 10 ans, en tant que développeurs de logiciels, nous avions l'habitude d'analyser quelque chose dans la mesure où nous obtenions la «signature» des documents (écrits en langage humain), puis la rédaction de code. Nous effectuions des tests unitaires, des tests de chaîne, puis des tests de système: la première fois que le système dans son ensemble était exécuté ensemble, parfois une semaine ou des mois après la signature des documents. C’est alors seulement que nous avons découvert toutes les hypothèses et les malentendus que nous avions lorsque nous avons tout analysé.

L’intégration continue au fur et à mesure vous amène à construire un système complet (bien qu’initial, très simple) de bout en bout. Au fil du temps, la fonctionnalité du système est construite orthogonalement. Chaque fois que vous effectuez une construction complète, vous effectuez le test du système tôt et souvent. Cela signifie que vous trouvez et corrigez les bogues et les hypothèses le plus tôt possible, au moment le plus économique.

Comment: En ce qui concerne le comment, j’ai déjà écrit un blog à ce sujet il y a quelque temps: [ Cliquez ici ]

Sur 8 articles, il explique pas à pas comment configurer un serveur Jenkins dans un environnement Windows pour des solutions .NET.