Was sollte in einem MSBuild-Skript außer Kompilierung gehen?

Question

Ich versuche gerade, CruiseControl.net einzurichten, und so frage ich mich, wie ich meine Aufgaben aufteilen soll.

Im Allgemeinen möchte ich Komponententests (xUnit.net), Help File Generation (Sandcastle) und FxCop ausführen.

Jetzt frage ich mich nur, ob ich ein neues Ziel in der Msbuild-Konfiguration ("Dokumentation") angeben und damit SandCastle ausführen soll, oder ob das in einem separaten Skript gehört? Außerdem ist msbuild dafür gedacht, etwas zu bauen, also denke ich, dass ncover, xunit und FxCop nicht dazu gehören sollten, oder sollten sie?

Was ist der vorgesehene Umfang von Msbuild?

Answer 1

Fügen Sie fast alles in MSBuild-Skripts ein, damit Sie und andere Entwickler dieselben Schritte lokal über die Befehlszeile ausführen können. Andernfalls, wenn etwas mit dem Build schief geht, müssen Sie es auf dem CC-Server debuggen. Keine nette Debugging-Erfahrung. Außerdem möchten Sie den Build lokal vor ausführen, um sicherzustellen, dass es funktioniert.

Die wenige Dinge, die ich nicht in MSBuild Scripts setzen würde:

• SVN-Update, wie CC dies trotzdem zu tun hat, und Sie in der Regel nicht wollen, zu aktualisieren, wenn eine lokale Build zu tun. (Nun, ich tun Typ svn up && msbuild ziemlich oft, aber das ist so kurz, dass ich nicht in ein Skript setzen muss.)
• Erstellung und Veröffentlichung von Build-Berichte; Auch in diesem Domäne des CC ist, und nicht lokal nützlich

Als Ihre MSBuild-Dateien für die Strukturierung, werden Sie ein „Master“ Skript erstellen, die Sie alles oder nur einige Ziele verwenden können, zu bauen, z.B.

• MSBuild /t:Build nur den Code zu bauen inkrementell
• MSBuild /t:Rebuild für einen sauberen Wiederaufbau
• MSBuild /t:UnitTest Einheit nur laufen zu testet
• MSBuild für die häufigste Wahl, sagen wir, das entspricht t:Build;UnitTest
• MSBuild /t:All zu Erstellen Sie Code, Dokumentation und Setup sauber, führen Sie alle Tests aus und verpacken Sie die Ergebnisse

Sie können auch "Verknüpfung" Ziele für beliebte Variationen hinzufügen.

Eine einzelne Master-Builddatei zu haben bedeutet nicht, dass alles in dieser einzigen Datei definiert ist; Sie können andere msbuild-Dateien einschließen und/oder msbuild rekursiv aufrufen, um Ihren Build zu organisieren. Zum Beispiel:

• Die Masterdatei .proj sollte relativ einfach sein; vor allem sollte es projektspezifisches Zeug wie die Liste der zu erstellenden Lösungen und projektspezifische Überschreibungen definieren
• Lassen Sie die Master-Datei eine einzelne .targets-Datei enthalten, die Ziele und Standardeigenschaften enthält; bemühen sich, dieses Projekt neutral und wiederverwendbar zu halten.
• Wenn die .targets-Datei zu groß wird, teilen Sie sie in separate Dateien auf, z. eine für Code, eine für Hilfe und Dokumentation, eine für Setup und Verpackung. Lassen Sie Ihre Haupttargets-Datei diese Unterdateien enthalten, so dass Ihre .proj-Datei immer noch nur eine Datei enthalten muss
• Ebenso können Sie die Master-.proj-Datei bei Bedarf aufteilen, z. nach Subsystem.

Answer 2

ich einen Build-Skript für einzelne Projekte, und ich die Kette einfach diejenigen, die aus einer Sekunden Build-Datei, wenn eine Suite bauen ... zum Beispiel meiner protobuf-net-Build-Datei behandelt Versionierung (SVN), Zusammenstellung (MSBuild + NAnt für Mono), Testen (NUnit), Verpackung (zip), etc. Es ist Ihr Build-Prozess; tun, was Sie brauchen; -p Wenn Sie beispielsweise auch die Bereitstellung und Dokumentation durchführen könnten.

Es hängt auch davon ab, wie Sie arbeiten; Wenn Sie CruiseControl verwenden, kann dies viel für Sie erledigen. Für mich selbst mag ich einen Befehlszeilen- "Build" -Schritt.