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

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 build qui fera les builds et les 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 aux pouvoirs en place. Je veux donc savoir:

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 des sources. Aurai-je besoin d'autre chose, ou y a-t-il un équivalent d'une tâche cron pour exécuter des scripts automatisés?

Qu'est-ce que cela m'apportera exactement, à 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 de pouvoir tester des fonctions particulières? Nous avons, pour le moment, deux de ces tests, 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 build est terminée et testée, est-ce une pratique courante de mettre cette build sur un site ftp ou d'avoir un autre moyen d'accès interne? L'idée est que cette machine crée la build, et nous y allons tous, mais pouvons faire des builds de débogage si nous le devons.
À quelle fréquence devrions-nous faire ce genre de construction?
Comment l'espace est-il géré? Si nous faisons des constructions nocturnes, devrions-nous conserver 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 me rends compte que c'est un sujet très vaste et je ne fais que commencer. Je n'ai pas pu trouver de duplicata de cette question ici, et s'il y a un livre là-bas que je devrais me procurer, faites-le moi savoir.

EDIT: J'ai enfin 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 en fait incomplètes. Nous avons également dû changer le type d'installation de vdproj Old-And-Busted à 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. Faire exécuter la construction à partir de la ligne de commande via MSBuild est un exercice utile en soi, car il oblige vos outils à être à jour.

Allen Rice · Accepted Answer

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écutez MSTests et affichez autant d'informations que les tests Junit
Gardez une trace des tâches faibles, moyennes et élevées
avertissements et erreurs de tendance

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

En outre, Dieu nous en préserve, vous utilisez une source visuelle sûre, il prend également en charge cela . Je vous recommande de jeter un œil à article de Redsolo sur la construction de projets .net en utilisant 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 des sources. Aurai-je besoin d'autre chose, ou y a-t-il un équivalent d'une tâche cron pour exécuter des scripts automatisés?
A: Je viens d'installer Visual Studio sur une nouvelle copie d'un VM exécutant une nouvelle installation corrigée d'un système d'exploitation de serveur Windows. Il vous faudrait donc Hudson s'installera en tant que service Windows et s'exécutera 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. Tout configurable via le navigateur.
Q: Qu'est-ce que cela m'apportera exactement, à 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 de pouvoir tester des fonctions particulières? Nous avons, pour le moment, deux de ces tests, car nous n'avons pas eu le temps (ou franchement, l'expérience) de faire de bons tests unitaires.

A: Vous recevrez un e-mail la première fois qu'une construction échoue ou devient instable. Une génération est instable si un test unitaire échoue ou elle peut être marquée comme instable à travers un certain nombre de critères que vous définissez. Lorsqu'un test unitaire ou une construction échoue, vous recevrez un e-mail et il vous dira où, pourquoi et comment il a échoué. Avec ma configuration, on obtient:
- liste de toutes les validations depuis la dernière version de travail
- valider les notes de ces validations
- liste des fichiers modifiés dans les commits
- sortie de la console à partir de la build elle-même, montrant l'erreur ou l'échec du test
Q: De quel type de matériel ai-je besoin pour cela?

A: A VM suffira
Q: Une fois qu'une build a été finie et testée, est-ce une pratique courante de mettre cette build sur un site ftp ou d'avoir un autre moyen d'accès interne? L'idée est que cette machine crée la build, et nous y allons tous, mais pouvons faire des builds de débogage si nous le devons.

A: Hudson peut faire ce que vous voulez avec, 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 devrions-nous faire ce type de construction?

A: Nous avons notre sondage SVN toutes les heures, recherchant les changements de code, puis exécutant une construction. Tous les soirs, c'est ok, mais un peu sans valeur, car ce sur quoi vous avez travaillé hier ne sera pas frais dans votre esprit le matin lorsque vous entrerez.
Q: Comment est géré l'espace? Si nous faisons des constructions nocturnes, devrions-nous conserver toutes les anciennes constructions ou commencer à les abandonner après environ une semaine?

A: C'est à vous, après si longtemps, je déplace nos artefacts de construction vers un stockage à long terme ou les supprime, mais toutes les données qui sont stockées dans des fichiers texte/fichiers xml que je garde, ce me permet de stocker le changelog, les graphiques de tendance, etc. sur le serveur avec un espace très restreint. Vous pouvez également configurer Hudson pour qu'il ne conserve que les artefacts d'un nombre de builds final.
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!

Mike Marshall · Answer

Nous avons eu beaucoup de chance avec le combo suivant:

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)
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)
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 justification: cela évite aux développeurs d'effectuer des builds manuels 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. Il est primordial d'avoir un processus reproductible pour créer et publier des logiciels. 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 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, peu importe la taille du groupe.

Sur l'espace: Aide à 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 génération, donc le vrai problème est de conserver les historiques 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 généralement être fait tous les 3-4 mois.

Sur les notifications de build: elles sont intégrées à CCNet, mais si vous souhaitez ajouter des tests automatisés comme étape supplémentaire, intégrez-les dans le projet dès le départ. Il est extrêmement difficile de sauvegarder les 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 la nomination des outils spécifiques.

Jeff · Answer

Sur mon ancien lieu de travail, nous utilisions TeamCity . C'est très simple 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 avions beaucoup de petits projets et qu'il est assez pénible de les configurer dans CC.NET. Je recommande fortement 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 plus élevée. Si votre budget vous le permet, optez définitivement pour TeamCity ou consultez la version gratuite.

Trumpi · Answer

Comment? Jetez un oeil à Carel Lotz blog .

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

Une build fonctionnelle, lorsqu'elle est correctement implémentée, signifie que tous vos développeurs peuvent construire sur leur machine lorsque la build 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 publiez a fait un voyage vers votre système de contrôle de source.
Une version fonctionnelle, lorsqu'elle est correctement implémentée, signifie que vous vous intégrez tôt et souvent, ce qui réduit vos risques d'intégration.

L'article de Martin Fowler sur Intégration Continue reste le texte définitif. Jetez-y un œil!

Daniel Earwicker · Answer

L'argument principal 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 s'agrandit, plus il est difficile de coordonner son travail et de l'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 archivant de petites unités de travail (parfois appelées "histoires") au fur et à mesure de leur réalisation.

Vous devez faire reconstruire la machine de construction CHAQUE fois à chaque vérification, 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 version est interrompue.

Vous devez ensuite effectuer une génération complète et propre tous les soirs où la version source est étiquetée (en fonction d'un numéro de version unique) que vous pouvez choisir de publier auprès de vos parties prenantes (chefs de produit, QA). 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.

The Lazy DBA · Answer

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

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

Comme Earwicker l'a mentionné, 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 tôt.

NAnt inclut également des tâches pour nunit / nunit2 , vous pouvez donc réellement automatisez 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 génération.

Il en va de même pour la tâche ndoc . Faites produire et mettre à disposition votre documentation pour chaque build.

Vous pouvez même utiliser la tâche exec pour exécuter d'autres commandes, par exemple, en produisant 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é à l'avant est un gain de temps sur la route. Les gens n'ont pas à garder la build en passant par le processus de build. Identifiez toutes les étapes de votre génération, créez des scripts NAnt pour chaque tâche et générez vos scripts NAnt un par un jusqu'à ce que vous ayez entièrement automatisé l'ensemble de votre processus de génération. 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 fonctionnait bien dans la build 380? Eh bien, il y a des livrables prêts à être testés - saisissez-les et testez-les.

Kenneth Cochran · Answer

Aucune licence requise. CruiseControl.net est disponible gratuitement et n'a besoin que du SDK .NET pour être construit.
Un serveur de build, même sans tests unitaires automatisés, fournit toujours un environnement contrôlé pour les versions de build. Plus "John construit généralement 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 configuré dans une session Virtual PC.
Oui. La version doit être sauvegardée dans un endroit accessible. Les versions de développement devraient avoir le débogage activé. La version Release devrait l'avoir désactivée.
La fréquence dépend de vous. S'il est correctement configuré, vous pouvez créer après chaque enregistrement 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.
Gardez les jalons et les versions aussi longtemps que nécessaire. Tout le reste dépend de la fréquence à laquelle vous construisez: en continu? jeter. Du quotidien? Gardez la valeur d'une semaine. Hebdomadaire? Gardez une valeur de deux mois.

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

eglasius · Answer

Tout dépend de la santé de la construction. Ce que cela vous apporte, c'est que vous pouvez configurer tout type de choses que vous souhaitez que les générations se produisent. Parmi ceux-ci, vous pouvez exécuter des tests, des analyses statiques 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 le configuriez pour construire à chaque enregistrement (intégration continue).

Cela peut également aider à rapprocher QA et Dev. Comme vous pouvez configurer des tests fonctionnels pour l'exécuter, 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.

Andrew Gray · Answer

Pourquoi: il y a 10 ans, nous, développeurs de logiciels, avions l'habitude d'analyser quelque chose au nième degré, de "signer" les documents (écrits dans un langage humain), puis de commencer à écrire du code. Nous ferions un test unitaire, un test de chaîne, puis nous frapperions le test du 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 que les documents ont été approuvés. Ce n'est qu'à ce moment-là que nous découvririons toutes les hypothèses et les malentendus que nous avions en analysant tout.

L'intégration continue au fur et à mesure que l'idée vous fait construire un système complet (bien que, au début, 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, lorsque c'est le moment le moins cher pour les corriger.

Comment: Quant au comment, j'ai blogué à ce sujet il y a un petit moment: [ Cliquez ici ]

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