Améliorer votre processus de construction

Question

Ou, en fait, établir un processus de construction alors qu'il n'y en a pas beaucoup en place au départ.

Actuellement, c’est à peu près la situation à laquelle mon groupe est confronté.Nous faisons principalement du développement d'applications Web (mais pas de développement de bureau pour le moment).Les déploiements de logiciels sont laids et lourds, même avec nos modestes applications, et nous avons rencontré beaucoup trop de problèmes au cours des deux années où j'ai fait partie de cette équipe (et de cette entreprise).Il est grand temps de faire quelque chose à ce sujet, et le résultat est que nous pourrons faire d'une pierre deux coups à Joel Test (constructions quotidiennes et constructions en une étape, dont aucune n'existe sous quelque forme que ce soit).

Ce que je recherche ici, c'est un aperçu général du genre de choses que je dois faire ou auxquelles je dois penser, de la part de personnes qui travaillent dans le développement de logiciels depuis plus longtemps que moi et qui ont également un cerveau plus gros.Je suis convaincu que ce seront la plupart des personnes qui publient actuellement dans la version bêta.

Outils pertinents :Visual Build Source Safe 6.0 (je sais, mais je ne peux rien faire pour savoir si nous utilisons ou non Source Safe pour le moment.Ce sera peut-être la prochaine bataille que je mènerai.)

À titre provisoire, j'ai un projet Visual Build qui fait ceci :

1. Obtenez la source et l'emplacement dans le répertoire local, y compris les DLL nécessaires au projet.
2. Obtenez les fichiers de configuration et renommez-les si nécessaire (nous les stockons dans un sous-répertoire spécial qui ne fait pas partie de l'application réelle, et ils sont nommés en fonction de leur utilisation).
3. Construire à l'aide de Visual Studio
4. Précompiler en utilisant la ligne de commande, en copiant dans ce qui sera un répertoire "build"
5. Copier vers la destination.
6. Obtenez toutes les ressources supplémentaires nécessaires - principalement des éléments tels que des documents, des images et des rapports associés au projet (et placés dans le répertoire à partir de l'étape 5).Il y a beaucoup de choses de ce genre et je ne voulais pas les inclure auparavant.Cependant, je vais copier uniquement les éléments modifiés, donc cela n'a peut-être pas d'importance.Je n'étais pas sûr de vouloir vraiment inclure ces éléments dans les étapes précédentes.

J'ai encore besoin de convaincre de me déconnecter de Visual Build pour tout cela, mais je n'en suis pas encore au point où je dois le faire.

Quelqu'un a-t-il des conseils ou des suggestions à faire ?Nous n'utilisons pas actuellement de projet de déploiement, je le note.Cela supprimerait certaines des étapes nécessaires dans cette version, je suppose (comme l'échange web.config).

Answer 1

Lorsque l’on entreprend un projet qui n’a jamais eu de processus de construction automatisé, il est plus facile de le réaliser par étapes.N'essayez pas d'avaler trop de choses à la fois, sinon cela pourrait vous sembler insupportable.

1. Commencez par compiler votre code en une seule étape à l'aide d'un programme de construction automatisé (c'est-à-direnant/msbuild).Je ne vais pas débattre pour savoir lequel est le meilleur.Trouvez-en un qui vous convient et utilisez-le.Ayez les scripts de build en direct avec le projet dans le contrôle de code source.
2. Déterminez comment vous souhaitez que votre build automatisé soit déclenché.Qu'il s'agisse de le connecter à CruiseControl ou d'exécuter une tâche de construction nocturne à l'aide de tâches planifiées.CruiseControl ou TeamCity sont probablement le meilleur choix pour cela, car ils incluent de nombreux outils que vous pouvez utiliser pour faciliter cette étape.CruiseControl est gratuit et TeamCity est gratuit jusqu'à un certain point, où vous devrez peut-être payer pour cela en fonction de la taille du projet.
3. Ok, à ce stade, vous serez assez à l’aise avec les outils.Vous êtes maintenant prêt à ajouter plus de tâches en fonction de ce que vous souhaitez faire pour les tests, le déploiement, etc.

J'espère que cela t'aides.

Answer 2

J'ai un ensemble de scripts Powershell qui font tout cela pour moi.

Scénario 1 :Build - celui-ci est simple, il est principalement géré par un appel à msbuild, et il crée également mes scripts de base de données.

Scénario 2 :Package - Celui-ci utilise divers arguments pour empaqueter une version pour divers environnements, tels que le test, et des sous-ensembles de l'environnement de production, qui se compose de nombreuses machines.

Scénario 3 :Déployer - Ceci est exécuté sur chaque ordinateur individuel à partir du dossier créé par le script Package (le script Deploy est copié dans le cadre de l'empaquetage)

À partir du script de déploiement, j'effectue des vérifications d'intégrité sur des éléments tels que le nom de la machine afin que les éléments ne soient pas déployés accidentellement au mauvais endroit.

Pour les fichiers web.config, j'utilise le

<appSettings file="Local.config">

fonctionnalité pour avoir des remplacements qui sont déjà sur les machines de production, et ils sont en lecture seule afin qu'ils ne soient pas écrasés accidentellement.Les fichiers Local.config ne sont pas archivés et je n'ai pas besoin de changer de fichier au moment de la construction.

[Modifier] L'équivalent de appSettings file= pour une section de configuration est configSource="Local.config"

Answer 3

Nous sommes passés de l'utilisation d'un script Perl à MSBuild il y a deux ans et nous n'avons pas regardé en arrière.La création de solutions Visual Studio peut être effectuée en les spécifiant simplement dans le fichier XML principal.

Pour quelque chose de plus compliqué (obtenir votre code source, exécuter des tests unitaires, créer des packages d'installation, déployer des sites Web), vous pouvez simplement créer une nouvelle classe dans .net dérivée de Tâche qui remplace la fonction Execute, puis référencez-la à partir de votre fichier XML de build.

Il y a une assez bonne introduction ici :introduction

Answer 4

Je n'ai travaillé que sur quelques projets .Net (j'ai principalement fait Java), mais une chose que je recommanderais est d'utiliser un outil comme NANT.J'ai un vrai problème avec le couplage de ma build à l'EDI, cela finit par rendre très pénible la configuration des serveurs de build plus tard, car vous devez effectuer une installation VS complète sur n'importe quelle boîte à partir de laquelle vous souhaitez construire dans le avenir.

Cela étant dit, toute build automatisée vaut mieux que pas de build automatisée.

Answer 5

Notre processus de construction est un ensemble de scripts Perl locaux qui ont évolué sur une dizaine d'années, rien d'extraordinaire mais il fait le travail.Un script obtient le dernier code source, un autre le construit, un troisième le transfère vers un emplacement réseau.Nous développons des applications de bureau, notre processus de préparation crée également des packages d'installation à des fins de test et éventuellement d'expédition aux clients.

Je vous suggère de le diviser en étapes individuelles, car il y aura des moments où vous souhaiterez reconstruire mais pas obtenir la dernière version, ou peut-être simplement avoir besoin de refaire la mise en scène.Nos scripts peuvent également gérer la construction à partir de différentes branches, alors pensez-y également quelle que soit la solution que vous développez.

Enfin, nous disposons d'une machine de construction dédiée qui reconstruit les branches de tronc et de maintenance chaque nuit et envoie un e-mail en cas de problème ou si l'opération s'est terminée avec succès.

Answer 6

Une chose que je suggérerais de vous assurer que votre script de construction (et votre projet d'installation, le cas échéant dans votre cas) est dans le contrôle de source.J'ai tendance à avoir un script très simple qui vérifie simplement le script de construction "principal" puis le lance.

Je dis cela parce que je vois des équipes qui exécutent simplement la dernière version du script de construction sur le serveur, mais soit ne la mettent jamais dans le contrôle de code source, soit lorsqu'elles le font, elles ne l'enregistrent que de manière aléatoire.Si vous faites en sorte que le processus de construction "obtienne" du contrôle de code source, cela vous obligera à conserver le script de construction le plus récent et le plus performant.

Answer 7

Notre système de construction est un makefile (ou deux).Cela a été plutôt amusant de le faire fonctionner car il doit s'exécuter à la fois sur Windows (en tant que tâche de build sous VS) et sous Linux (en tant que tâche normale "make bla").Ce qui est vraiment amusant, c'est que la construction obtient la liste de fichiers réelle à partir d'un fichier .csproj, construit (un autre) makefile à partir de celui-ci et l'exécute.Dans les processus, le fichier make s'appelle lui-même.

Si cette pensée n'effraie pas le lecteur, alors (soit ils sont fous, soit) ils peuvent probablement faire travailler make + "votre mangler de cordes préféré" pour eux.

Answer 8

Nous utilisons Uppercut.UppercuT utilise NAnt pour construire et il est extrêmement facile à utiliser.

http://code.google.com/p/uppercut/

Quelques bonnes explications ici : Uppercut