Tâche de pré-construction : suppression de la copie de travail dans CruiseControl.NET

Question

Je suis actuellement en train de mettre en place un environnement d'intégration continue au travail.Nous utilisons VisualSVN Server et CrusieControl.NET.Parfois, une construction échoue et un symptôme est qu'il existe des conflits dans la copie de travail de CruiseControl.NET.Je pense que cela est dû à la façon dont j'ai configuré les solutions Visual Studio.Espérons que plus nous exécutons de projets dans cet environnement, meilleure sera notre compréhension de la manière de les mettre en place. Je ne me demande donc pas pourquoi les conflits surviennent à ce stade.Pour corriger les builds, je supprime la copie de travail et force une nouvelle build – cela fonctionne à chaque fois (actuellement).Mes questions sont donc :la suppression de la copie de travail est-elle une partie valide d'un processus de création d'intégration continue, et comment dois-je procéder ?

J'ai essayé des solutions, notamment MSTask et l'appel de delete depuis la ligne de commande, mais je n'ai pas de chance.

Désolé d'être si verbeux - bon travail, c'est une version bêta :)

Answer 1

Effectuer une suppression complète avant ou après votre build est une bonne pratique.Cela signifie qu'il n'y a aucune chance que votre environnement de build récupère un fichier obsolète.Votre bâtiment exactement par rapport à ce qui se trouve dans le référentiel.

La suppression de la copie de travail est possible comme je l'ai fait avec Nant.

Dans Nant, j'aurais un script propre dans son propre dossier en dehors de celui que je souhaite supprimer et je l'invoquerais ensuite depuis CC.net.

Je suppose que cela devrait également être possible avec un fichier batch.Jetez un œil à la commande rmdir http://www.computerhope.com/rmdirhlp.htm

@pauldoo

Je préfère que mon serveur CI effectue une suppression complète car je ne veux pas de surprise lorsque je vais créer une version, qui doit toujours être effectuée à partir d'un état propre.Mais il devrait être capable de gérer les deux, sans aucune raison.

Answer 2

@Jamie:Il y a une raison pour laquelle vous ne pourrez peut-être pas effectuer une build propre à chaque fois lorsque vous utilisez un serveur d'intégration continue : le temps de build.Sur certains projets sur lesquels j'ai travaillé, les versions propres prennent plus de 80 minutes (un projet intégré composé de milliers de fichiers C++ à extraire puis à compiler sur plusieurs cibles).Dans ce cas, vous devez peser l'avantage d'un retour rapide par rapport à la probabilité qu'une version propre détecte quelque chose qu'une version incrémentielle ne détectera pas.Dans notre cas, nous avons travaillé sur l'amélioration et la parallélisation du processus de build tout en autorisant les builds incrémentielles sur notre machine CI.Nous avons eu quelques problèmes parce que nous ne faisions pas de builds propres, mais en effectuant une build propre tous les soirs ou toutes les semaines, vous pouviez supprimer le risque sans perdre le retour rapide de votre machine CI.

Answer 3

Si vous consultez CC.NET jira il existe un correctif archivé pour implémenter CleanCopy pour Subversion qui fait exactement ce que vous voulez et définissez simplement CleanCopy égal à true dans votre bloc de contrôle de source, tout comme avec celui de TFS.

Answer 4

Il est très courant et généralement une bonne pratique pour tout processus de construction d'effectuer un « nettoyage » avant de procéder à une construction importante.Cela empêche tout « artefacts » des versions précédentes d’entacher la sortie.

Un nettoyage consiste essentiellement à supprimer la copie de travail.

Answer 5

@Brad Barker

Nettoyer signifie simplement effacer les produits de construction.

La suppression de la copie de travail supprime également tout le reste (fichiers source et projet, etc.).

En général, c'est bien si votre machine de construction peut fonctionner sans effectuer de suppression complète, car cela reproduit ce que fait un développeur normal.Tout conflit détecté lors de la mise à jour constitue un avertissement précoce de ce à quoi vos développeurs peuvent s'attendre.

---

@Jamie

Pour les versions officielles, oui, il est préférable d'effectuer une vérification complètement propre.Donc je suppose que cela dépend du but de la construction.