Pre-Build-Aufgabe - Löschen der Arbeitskopie in CruiseControl.NET

Question

Ich bin gerade dabei, eine Continuous Integration Environment bei der Arbeit einzurichten. Wir verwenden VisualSVN Server und CrusieControl.NET. Gelegentlich schlägt ein Build fehl, und ein Symptom besteht darin, dass es Konflikte in der Arbeitskopie von CruiseControl.NET gibt. Ich glaube, das liegt an der Art und Weise, wie ich die Visual Studio-Lösungen eingerichtet habe. Hoffentlich, je mehr Projekte wir in diesem Umfeld durchführen, desto besser werden wir verstehen, wie sie aufgebaut werden, damit ich nicht in Frage stelle, warum die Konflikte in diesem Stadium passieren. Um die Builds zu reparieren, lösche ich die Arbeitskopie und erzwinge einen neuen Build - das funktioniert jedes Mal (momentan). Meine Fragen sind also: Löscht die Arbeitskopie einen gültigen Teil eines kontinuierlichen Integrations-Build-Prozesses, und wie gehe ich vor?

Ich habe versucht, Lösungen einschließlich MSTask und Aufruf von delete von der Befehlszeile, aber ich habe kein Glück.

Es tut uns so wortreich zu sein - gute Arbeit ist dies eine Beta :)

Answer 1

Ein vollständiges Löschen vor oder nach dem Erstellen ist eine gute Übung. Das bedeutet, dass Ihre Build-Umgebung keine veraltete Datei aufnehmen kann. Dein Gebäude genau gegen das, was im Repository ist.

Löschen der Arbeitskopie ist möglich, wie ich es mit Nant getan habe.

In Nant hätte ich ein sauberes Skript in einem eigenen Ordner außer dem, den ich löschen möchte und würde es dann von CC.net aufrufen.

Ich nehme an, dies sollte auch mit einer Batch-Datei möglich sein. Werfen Sie einen Blick auf dem rmdir Befehl http://www.computerhope.com/rmdirhlp.htm

@pauldoo

ich meinen CI-Server bevorzuge eine voll zu tun, löschen, da ich keine Überraschung tun will, wenn ich gehe, um ein Release-Build zu tun, was immer getan werden soll aus einem sauberen Zustand. Aber es sollte in der Lage sein, beide zu behandeln, kein Grund, warum nicht

Answer 2

Es ist sehr häufig und in der Regel eine gute Übung für jeden Build-Prozess eine ‚saubere‘ zu tun, bevor eine signifikante Build zu tun. Dies verhindert, dass Artefakte von früheren Builds die Ausgabe beeinträchtigen.

Ein sauberes ist im Wesentlichen, was Sie tun, indem Sie die Arbeitskopie löschen.

Answer 3

@Brad Barker

reinigen Mittel wischen nur Produkte bauen aus.

Das Löschen der Arbeitskopie löscht auch alles andere (Quell- und Projektdateien usw.).

Im Allgemeinen ist es schön, wenn Sie Build-Maschine funktionieren kann, ohne eine vollständige Löschung zu tun, da dies repliziert, was ein normaler Entwickler tut. Alle Konflikte, die während des Updates gefunden werden, sind eine frühe Warnung, was Ihre Entwickler erwarten können.

---

@jamie

Für formelle Veröffentlichungen ja, es ist besser, eine völlig saubere Kasse zu tun. Ich denke, das hängt vom Zweck des Builds ab.

Answer 4

@jamie: Es gibt einen Grund, warum Sie nicht in der Lage sein können, jedes Mal, wenn Sie einen Continuous Integration Server - Build-Zeit verwenden.Bei einigen Projekten, an denen ich gearbeitet habe, benötigen saubere Builds mehr als 80 Minuten (ein eingebettetes Projekt, das aus tausenden von C++ - Dateien besteht, die auschecken und dann gegen mehrere Ziele kompilieren). In diesem Fall müssen Sie den Nutzen eines schnellen Feedbacks mit der Wahrscheinlichkeit abwägen, dass ein sauberer Build etwas fängt, das ein inkrementeller Build nicht erfasst. In unserem Fall haben wir daran gearbeitet, den Build-Prozess zu verbessern und zu parallelisieren, während wir gleichzeitig inkrementelle Builds auf unserer CI-Maschine zulassen. Wir hatten ein paar Probleme, weil wir keine sauberen Builds gemacht haben, aber indem wir jeden Abend oder wöchentlich einen Clean Build machen, können Sie das Risiko entfernen, ohne die schnelle Rückmeldung von Ihrem CI-Gerät zu verlieren.

Answer 5

Wenn Sie überprüfen die CC.NET jira gibt es einen Patch in geprüft CleanCopy für Subversion zu implementieren, die genau das tut, was Sie wollen und nur gesetzt CleanCopy gleich wahr in Ihrer Blocksteuerquelle genau wie mit dem einem TFS.