Tâche de préconfiguration - 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, un build échouera et un symptôme est qu'il existe des conflits dans la copie de travail CruiseControl.NET. Je crois que cela est dû à la façon dont j'ai configuré les solutions Visual Studio. Espérons que plus nous courrons de projets dans cet environnement, meilleure sera notre compréhension de la façon de les mettre en place, donc je ne me demande pas pourquoi les conflits se produisent à ce stade. Pour réparer les builds, je supprime la copie de travail et force une nouvelle construction - cela fonctionne à chaque fois (actuellement). Donc mes questions sont: est la suppression de la copie de travail une partie valide d'un processus de construction d'intégration continue, et comment puis-je y aller?

J'ai essayé des solutions comprenant MSTask et appelant l'effacement de la ligne de commande mais je n'ai aucune chance.

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

Answer 1

Faire 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 compilation prenne un fichier périmé. 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, je voudrais avoir un script propre dans son propre dossier avec celui que je veux supprimer et l'invoquer ensuite à partir de CC.net.

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

@pauldoo

Je préfère mon serveur CI pour faire un effacement complet que je ne veux pas une surprise quand je vais faire une version de libération, ce qui devrait toujours être fait à partir d'un état propre. Mais il devrait être capable de gérer les deux, aucune raison pourquoi pas

Answer 2

Il est très fréquent et généralement une bonne pratique pour tout processus de construction de faire un « propre » avant de faire toute accumulation significative. Cela empêche les «artefacts» des versions précédentes d'altérer la sortie.

Un nettoyage est essentiellement ce que vous faites en supprimant la copie de travail.

Answer 3

@Brad Barker

moyen propre pour essuyer juste des produits de construction.

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

En général, il est bon que votre machine de build puisse fonctionner sans effectuer de suppression complète, car cela réplique ce qu'un développeur normal fait. Tous les conflits détectés pendant la mise à jour sont un avertissement précoce de ce à quoi vos développeurs peuvent s'attendre.

---

@jamie

Pour les versions formelles oui, il est préférable de faire une caisse complètement propre. Donc je suppose que cela dépend du but de la construction.

Answer 4

@jamie: Il y a une raison pour laquelle vous ne pouvez pas être capable de faire une construction propre chaque fois que vous utilisez un serveur d'intégration continue - temps de construction.Sur certains projets sur lesquels j'ai travaillé, les générations propres prennent plus de 80 minutes (un projet intégré composé de milliers de fichiers C++ à archiver puis à compiler sur plusieurs cibles). Dans ce cas, vous devez peser le bénéfice d'une réaction rapide par rapport à la probabilité qu'une construction propre attrape quelque chose qu'une construction incrémentale ne fera pas. Dans notre cas, nous avons travaillé sur l'amélioration et la parallélisation du processus de construction tout en permettant des constructions incrémentielles sur notre machine CI. Nous avons eu quelques problèmes car nous ne faisions pas de builds propres, mais en faisant une build propre tous les soirs ou toutes les semaines, vous pouviez éliminer le risque sans perdre le feedback rapide de votre machine CI.

Answer 5

Si vous consultez le jira de CC.NET, un correctif est installé pour implémenter CleanCopy for Subversion qui fait exactement ce que vous voulez et qui place simplement CleanCopy à true dans votre bloc de contrôle source, tout comme avec TFS.