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

Question

Ich bin derzeit dabei, bei der Arbeit eine kontinuierliche Integrationsumgebung einzurichten.Wir verwenden VisualSVN Server und CrusieControl.NET.Gelegentlich schlägt ein Build fehl und ein Symptom ist, dass es Konflikte in der CruiseControl.NET-Arbeitskopie gibt.Ich glaube, das liegt an der Art und Weise, wie ich die Visual Studio-Lösungen eingerichtet habe.Je mehr Projekte wir in diesem Umfeld durchführen, desto besser verstehen wir hoffentlich, wie man sie auf die Beine stellt, sodass ich nicht in Frage stelle, warum es zu diesem Zeitpunkt zu Konflikten kommt.Um die Builds zu reparieren, lösche ich die Arbeitskopie und erzwinge einen neuen Build – das funktioniert (derzeit) jedes Mal.Meine Fragen sind also:Ist das Löschen der Arbeitskopie ein gültiger Teil eines Continuous-Integration-Build-Prozesses und wie gehe ich vor?

Ich habe Lösungen wie MSTask und den Aufruf von „Delete“ über die Befehlszeile ausprobiert, hatte aber kein Glück.

Tut mir leid, dass ich so wortreich bin – gute Arbeit, das ist eine Beta :)

Answer 1

Es empfiehlt sich, vor oder nach dem Build eine vollständige Löschung durchzuführen.Dies bedeutet, dass keine Gefahr besteht, dass Ihre Build-Umgebung eine veraltete Datei abruft.Ihr Gebäude entspricht genau dem, was sich im Repository befindet.

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

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

Ich gehe davon aus, dass dies auch mit einer Batchdatei möglich sein sollte.Schauen Sie sich den Befehl rmdir an http://www.computerhope.com/rmdirhlp.htm

@pauldoo

Ich bevorzuge, dass mein CI-Server eine vollständige Löschung durchführt, da ich keine Überraschungen möchte, wenn ich einen Release-Build durchführe, der immer in einem sauberen Zustand erfolgen sollte.Aber es sollte in der Lage sein, beides zu bewältigen, es gibt keinen Grund, warum nicht

Answer 2

@jamie:Es gibt einen Grund, warum Sie bei Verwendung eines Continuous-Integration-Servers möglicherweise nicht jedes Mal einen sauberen Build durchführen können: die Buildzeit.Bei einigen Projekten, an denen ich gearbeitet habe, dauern saubere Builds mehr als 80 Minuten (ein eingebettetes Projekt, das aus Tausenden von C++-Dateien besteht, die ausgecheckt und dann für mehrere Ziele kompiliert werden müssen).In diesem Fall müssen Sie den Vorteil eines schnellen Feedbacks gegen die Wahrscheinlichkeit abwägen, dass ein sauberer Build etwas erkennt, was ein inkrementeller Build nicht erkennt.In unserem Fall haben wir daran gearbeitet, den Build-Prozess zu verbessern und zu parallelisieren und gleichzeitig inkrementelle Builds auf unserer CI-Maschine zu ermöglichen.Wir hatten zwar ein paar Probleme, weil wir keine sauberen Builds durchgeführt haben, aber indem Sie jede Nacht oder wöchentlich einen sauberen Build durchführen, können Sie das Risiko beseitigen, ohne das schnelle Feedback Ihrer CI-Maschine zu verlieren.

Answer 3

Wenn Sie sich CC.NET ansehen jira Es ist ein Patch eingecheckt, um CleanCopy für Subversion zu implementieren, der genau das tut, was Sie wollen, und CleanCopy einfach in Ihrem Quellcodeverwaltungsblock auf true setzt, genau wie beim TFS-Patch.

Answer 4

Es ist weit verbreitet und im Allgemeinen eine gute Vorgehensweise für jeden Build-Prozess, vor der Durchführung eines größeren Builds eine „Reinigung“ durchzuführen.Dadurch wird verhindert, dass „Artefakte“ aus früheren Builds die Ausgabe verfälschen.

Bei einer Bereinigung handelt es sich im Wesentlichen um das Löschen der Arbeitskopie.

Answer 5

@Brad Barker

Sauber bedeutet, Build-Produkte einfach zu entfernen.

Durch das Löschen der Arbeitskopie wird auch alles andere gelöscht (Quell- und Projektdateien usw.).

Im Allgemeinen ist es schön, wenn Ihre Build-Maschine ohne einen vollständigen Löschvorgang ausgeführt werden kann, da dies dem entspricht, was ein normaler Entwickler tut.Alle während der Aktualisierung festgestellten Konflikte sind eine Frühwarnung darüber, was Ihre Entwickler erwarten können.

---

@jamie

Ja, für formelle Veröffentlichungen ist es besser, einen völlig sauberen Checkout durchzuführen.Ich vermute also, dass es vom Zweck des Builds abhängt.