Ein Build-Tool sollte verwendet werden, wenn Ihr Build-Prozess länger als ein Befehl dauert. Es sollte verwendet werden, um Ihren Standard-Build-Prozess wieder in einen einzigen Befehl umzuwandeln. Wenn Ihr Build-Prozess länger als ein Befehl ist, haben Sie die Möglichkeit, dass Fehler aus verpassten / duplizierten / falschen Befehlen während eines Builds entstehen.
Eine Anfängerfrage, bitte: Ich frage mich nur, unter welchen Umständen man ein Build-Tool wie nant oder msbuild verwenden sollte? Ich arbeite an einer mittelgroßen Anwendung (.net 3.0), jeder Entwickler macht seine Arbeit und baut auf seinem Rechner auf, während er seine Codeänderungen in das Repository prüft. Sobald wir fertig sind, werde ich den gesamten Code aus dem Repository holen, einen sauberen Build auf meinem Rechner erstellen und die Binärdateien bereitstellen. Nur aus Neugier, wo kommt das Build Tool?
Die kurze Antwort ist immer.
Jeder Entwickler sollte das Build-Skript erstellen, bevor er den Code eincheckt. Die Leute, die das Release erstellen, sollten das Build-Skript verwenden, um das Release zu erstellen. Ihre Buildbots sollten das Build-Skript verwenden, um den Code zu erstellen und zu testen, der eingecheckt wurde.
Dies ermöglicht allen Entwicklern, Testern und Buildbots einen konsistenten, wiederholbaren Build. Immerhin Der F5-Schlüssel ist kein Build-Prozess .
Es klingt wie Sie eine IDE verwenden, um Ihren Build zu erstellen. Es ist im Wesentlichen ein Build-Tool; Du benutzt bereits eins. Sie sollten die Tools wechseln, wenn das von Ihnen verwendete Problem eher ein Problem als eine Lösung darstellt.
Ich denke, jede nicht-triviale Anwendung benötigt ein "Build-Tool". Wir verwenden den Begriff Continuous Integration, wo ich arbeite. Es gibt sehr außergewöhnliche Fälle (z. B. ich baue eine Beispiel-App, um zu erfahren, wie Feature X funktioniert), aber abgesehen davon werden Sie es nie bereuen, einen soliden Build-Prozess zu haben.
Ich denke, wenn das Entwicklungsteam aus einer Person besteht ... würde ich immer noch ein Build-System einrichten, das ein Repository, ein Bauwerkzeug und mehrere Testsuiten enthält. Ja, die Wartung des Build-Systems kostet Zeit und Geld, aber es wird sich auszahlen (ich arbeite seit 40 Monaten an einem Projekt, das mit 6 Entwicklern begann und jetzt etwa 30 Entwickler umfasst; es hat sich für uns bezahlt gemacht der Zeiten) in Bezug auf die Qualitätskontrolle, und je früher Qualitätsprobleme erkannt werden, sind die Kosten, die sie beheben müssen.
Wenn Sie alles automatisieren wollen, ist es gut, nant / msbuild zu verwenden. Beispielsweise: 1. einchecken 2. bauen 3. Test- und Codeabdeckung
Wenn Sie mit der Veröffentlichung von Releases beginnen oder wenn Ihr Build eine bestimmte Anzahl von manuellen Schritten überschreitet (Sie werden bemerken, wenn es anfängt, nervig zu werden.) Ich habe ein altes blog Eintrag zu diesem Thema, das Sie vielleicht interessant finden.
Zustimmung und Erweiterung der Antwort von zacherates ... Ja, Sie sollten immer einen wiederholbaren Build-Prozess haben. Während Visual Studio-Projekte technisch MSBuild-Dateien sind, ist es besser, wenn der "offizielle" Build-Prozess von der Entwicklungsumgebung getrennt ist.
In meinen Augen ist das wahr, egal wie groß (oder klein) das Team ist. Ich benutze NAnt und CruiseControl.NET zu Hause , wo ich nur an Scratch-Projekten und Experimenten arbeite. Bei der Arbeit verwenden wir ein ähnliches Setup, aber ein bisschen strukturierter in der Art, wie die NAnt-Skripte zusammengefügt werden.
Es ist definitiv Ihre Zeit wert, sich damit zu beschäftigen. Es ist kein Allheilmittel, aber es ist eine Best Practice, genau zu wissen, welcher Build wann veröffentlicht wurde und was in der Wildnis ist. In der Lage zu sein, Ihren kompilierten Code zu identifizieren, ist die halbe Fehlerbehebung! :)
Entwickeln Sie mit Visual Studio? In diesem Fall verwenden Sie bereits msbuild, da dies die zugrunde liegende Build-Engine von Visual Studio ist. Eine Visual Studio-Projektdatei ist eigentlich nichts anderes als ein Msbuild-Skript.
Abgesehen davon können Sie die Build-Engine in einem dedizierten Build-System verwenden, damit Ihre Binärdateien unbeaufsichtigt und ohne Visual Studio installiert werden können. Sie können das auch für Komponententests verwenden.