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

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 des builds 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 les dépenses auprès des pouvoirs en place. Alors je veux savoir:

Mise à jour: Jenkins est la version la plus récente 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 à partir d'un ancien de mes messages:

Nous l'utilisons pour

• Déployer les services Windows
• Déployer des services Web
• Exécutez des MSTests et affichez autant d'informations que n'importe quel test Junit
• Gardez une trace des tâches basses, 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

En outre, Dieu nous en préserve d'utiliser le coffre-fort de source visuelle, il le prend également en charge . Je vous recommande de consulter l'article de Redsolo sur la création de projets .net à l'aide d'Hudson

Vos questions

• Q : De quel type d'outils / licences ai-je besoin? À l'heure actuelle, nous utilisons Visual Studio et Smart Assembly pour créer et Perforce pour le contrôle de code source. Aurai-je besoin de quelque chose d'autre, 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 corrigée d'un système d'exploitation Windows Server. Vous aurez donc besoin des licences pour gérer cela. Hudson s'installera en tant que service Windows et fonctionnera sur le port 8080 et vous configurerez la fréquence à laquelle vous souhaitez qu'il analyse votre référentiel de code pour le code mis à jour, ou vous pouvez lui dire de construire à un certain moment. Tous configurables via le navigateur.

• Q: Qu'est-ce que cela m'apportera exactement, à part l'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 de pouvoir faire 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.

  R: Vous recevrez un e-mail la première fois qu'une compilation échoue ou devient instable. Une génération est instable si un test unitaire échoue ou elle peut être marquée comme instable selon n'importe quel nombre de critères que vous définissez. Lorsqu'un test unitaire ou une construction échoue, vous recevrez un e-mail et il vous indiquera où, pourquoi et comment il a échoué. Avec ma configuration, on obtient:

  • 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 de la construction elle-même, montrant l'erreur ou l'échec du test

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

  R: Une VM suffira

• Q: Une fois qu'une compilation a été 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'accès interne? L'idée est que cette machine effectue la construction, et nous y allons tous, mais pouvons faire des versions de débogage si nous le devons.

  R: Hudson peut faire tout ce que vous voulez avec lui, y compris l'identifier via le hachage md5, le télécharger, le copier, l'archiver, etc. Il le fait automatiquement et vous fournit une longue histoire d'artefacts de construction.

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

  R: Nous avons le nôtre interroger SVN toutes les heures, à la recherche de changements de code, puis en exécutant une compilation. Le soir, c'est ok, mais un peu inutile IMO puisque 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 versions nocturnes, devrions-nous garder toutes les anciennes versions ou commencer à les abandonner après environ une semaine?

  R: C'est à vous de décider, après si longtemps, je déplace nos artefacts de construction vers un stockage à long terme ou je les supprime, mais toutes les données stockées dans des fichiers texte / fichiers xml que je garde, cela me permet de stocker le journal des modifications, les graphiques de tendance, etc sur le serveur avec peu d'espace consommé. Vous pouvez également configurer Hudson pour ne conserver que les artefacts d'un nombre de builds à la fin

• 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!

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 passant nos fichiers de solution. Supprime le besoin de scripts msbuild)
2. NAnt (comme la bibliothèque de syntaxe / tâches XML mieux 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 builds.

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

Sur la justification: cela allège la charge des 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 en arrière. Il est primordial d'avoir un processus reproductible pour créer et publier un logiciel. Je suis sûr que vous avez été des endroits où ils ont construit le logiciel à la main et qu'il sort dans la nature, seulement pour que votre responsable 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 construction de premier ordre, quelle que soit la taille du groupe.

Sur l'espace: permet d'avoir beaucoup d'espace sur le disque dur. Vous pouvez créer vos scripts NAnt pour supprimer les fichiers intermédiaires à chaque démarrage d'une compilation, le vrai problème est donc de conserver les historiques des journaux et les anciens installateurs d'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 effectué tous les 3-4 mois.

Sur les notifications de construction: Ceci est intégré à CCNet, mais si vous allez ajouter des tests automatisés comme étape supplémentaire, intégrez-le dans le projet dès le départ. Il est extrêmement difficile de soutenir les tests d'ajustement une fois qu'un projet prend de l'ampleur. Il y a des tonnes d'informations sur les frameworks de test (probablement une tonne d'informations sur SO), donc je vais différer de nommer des outils spécifiques.

Sur mon ancien lieu de travail, nous avons utilisé TeamCity . C'est très simple et puissant à utiliser. Il peut être utilisé gratuitement avec certaines restrictions. Il existe également 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 configurer dans CC.NET. Je recommande vivement TeamCity. Pour résumer si vous êtes vers l'open source, CC.NET est le grand-père avec une courbe d'apprentissage légèrement supérieure. Si votre budget vous le permet, optez pour TeamCity ou consultez la version gratuite.

Comment? Jetez un œil au blog de Carel Lotz .

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

• Une version fonctionnelle, lorsqu'elle est correctement mise en œuvre, signifie que tous vos développeurs peuvent construire sur leur machine lorsque la version est verte
• Une version fonctionnelle, lorsqu'elle est correctement mise en œuvre, 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 fait un voyage vers votre système de contrôle de source.
• Une version 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. Jetez-y un œil!

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

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 jouer avec les changements des autres. La seule bonne solution est de 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 qu'elles sont terminées.

Vous devez faire reconstruire la machine de construction à CHAQUE fois lors de l'enregistrement, 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 vous parle même!) Lorsque la construction est cassée.

Vous devez ensuite faire une compilation complète tous les soirs où la version source est étiquetée (avec un numéro de version unique) que vous pouvez choisir de publier à vos parties prenantes (chefs de produit, personnes chargées du contrôle 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 où les versions peuvent être téléchargées, et avoir un bouton sur lequel vous pouvez cliquer pour publier la version nocturne précédente.

J'essaie juste de construire un peu sur ce que Mjmarsh a dit, car il a jeté de bonnes bases ...

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

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

Comme l'a mentionné Earwicker, construisez tôt, construisez souvent. Savoir que quelque chose s'est cassé et que vous pouvez produire un livrable est utile pour attraper des choses 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 du framework fourni par CruiseControl.net, obtenir de jolis résultats de tests unitaires lisibles et imprimables pour chaque build.

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

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

L'idée est d'automatiser au maximum la construction, car les êtres humains font des erreurs. Le temps passé à l'avance est du temps économisé sur la route. Les gens n'ont pas à garder la build en passant par le processus de build. Identifiez toutes les étapes de votre build, 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é l'ensemble de votre processus de build. Il place également toutes vos versions au même endroit, ce qui est bon à des fins de comparaison. Quelque chose de cassé dans la Build 426 qui a bien fonctionné dans la Build 380? Eh bien, il y a les livrables prêts à être testés - saisissez-les et testez-les.

• Aucune licence requise. CruiseControl.net est disponible gratuitement et n'a besoin que du sdk .NET pour se construire.
• Un serveur de build, même sans tests unitaires automatisés, fournit toujours un environnement contrôlé pour la création de versions. Plus de "John construit habituellement sur sa machine mais il est malade. Pour une raison quelconque, je ne peux pas construire sur ma machine"
• À l'heure actuelle, j'en ai configuré un dans une session Virtual PC.
• Oui. La construction doit être sauvegardée dans un endroit accessible. Le débogage doit être activé pour les versions 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 avec très peu de frais généraux. C'est une excellente idée si vous avez (ou prévoyez d'avoir) des tests unitaires en place.
• Conservez les jalons et les versions aussi longtemps que nécessaire. Tout le reste dépend de la fréquence à laquelle vous construisez: en continu? désinvolte. Du quotidien? Gardez la valeur d'une semaine. Hebdomadaire? Gardez la valeur de deux mois.

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

Tout dépend de la santé de la construction. Cela vous permet de configurer n'importe quel type de choses que vous souhaitez faire 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 indique presque où vous l'avez cassé :)

Cela suppose bien sûr 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 à exécuter avec lui, ainsi que le profileur et tout ce qui améliore les commentaires à 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, donc dans mon cas, nous collaborons encore plus étroitement.

Pourquoi: il y a 10 ans, en tant que développeurs de logiciels, nous analysions quelque chose au nième degré, obtenions les documents (écrits dans un langage humain) `` signés '' puis commençons à écrire du code. Nous faisions des tests unitaires, des tests de chaînes et ensuite nous allions tester le système: la première fois que le système dans son ensemble serait exécuté ensemble, parfois une semaine ou des mois après la signature des documents. Ce n'est qu'à ce moment-là que nous découvrirons toutes les hypothèses et les malentendus que nous avions en analysant tout.

L'intégration continue au fur et à mesure de l'idée vous amène à construire un système complet (bien que, au départ, 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 compilation 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 moins cher pour les corriger.

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

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