Oh, Mühe. Visual Studio 2003 und Cruise Control.NET. Schlicht und elegant. Ein einfaches NAnt-Skript zum Erstellen der Lösung und schon kann es losgehen. Führen Sie NUnit aus, die Ausgabe erfolgt in einem Format, das CC und Bobs Onkel verstehen können. Lassen Sie mich das quantifizieren. Unser Kreuzfahrtserver verfügt über einen Subversion-Client (Befehlszeile) und das .NET 1.1 SDK. Visual Studio ist nicht installiert, da es sich tatsächlich um einen Server handelt und Cruise lediglich etwas benötigt, mit dem er das System erstellen kann.
Starten Sie Visual Studio 2005. Ich habe CI erst kürzlich für unsere 2005-Projekte eingerichtet, aber es ist in vielerlei Hinsicht einfach hässlich. Zuerst wurde versucht, das System mit MSBuild zum Erstellen zu bringen. Das war in Ordnung, weil Sie einfach Folgendes eingeben können:
msbuild /t:rebuild Lösungsname.sln
(oder welches Ziel auch immer Sie möchten, z. B. Debug oder Release).
Wie gesagt, wenn das alles ist, war es kein Problem, aber es wird sehr schnell sehr hässlich.
Zuerst gibt es VSTS-Unit-Testprojekte. Das gesamte Team ist mit der Visual Studio Team Suite ausgestattet. Ein teurer Vorschlag, der aber vor langer Zeit von jemandem gemacht wurde, der klüger ist als ich. Aber kein Problem. Wir verwenden den Test Manager nicht wirklich oft, es gibt keine automatisierten Webtests, also schreiben wir nur Unit-Tests (und führen sie mit Jamie Cansdales ausgezeichnetem TestDriven.NET aus). Wenn MSBuild jedoch eine Lösung erhält, die ein VS-Unit-Testprojekt enthält, benötigt es einige zusätzliche Assemblys (Assemblys, die im GAC_MSIL und an anderen Stellen vergraben sind). Der Ausschnitt in der Datei „ccnet.config“, um MSBuild zum Laufen zu bringen, war ziemlich einfach:
Durch rohe Gewalt (MSBuild ausführen, herausfinden, welche Assembly benötigt wird, suchen, aufschäumen, ausspülen, wiederholen) konnte ich eine 2005-Lösung (mit Unit-Test-Projekten) zum Kompilieren bringen. Die tatsächliche Durchführung der Tests ist jedoch eine andere Geschichte. Auch hier herrschte rohe Gewalt, als ich ein oder zwei Stunden lang MSTest.exe ausführte, um ein paar hundert Unit-Tests zum Ausführen zu überreden. Der cc.config-Eintrag zum Abrufen einiger Komponententests sieht etwa so aus:
Denken Sie daran, dass ich gesagt habe, dass auf diesem Server Visual Studio nicht installiert ist. Für die VS2005-Lösungen habe ich gerade das .NET SDK 2.0 installiert und das war gut genug. Obwohl MSTest.exe nicht enthalten ist, habe ich mir die Datei (und es ist ein verrückter Satz zusätzlicher DLLs, die über die gesamte Festplatte verstreut sind) von einem anderen System geschnappt und sie dort abgelegt, wo sich die EXE-Datei befand, damit sie problemlos funktioniert.
Keine Probleme beim Ausführen von MSTest für ein Unit-Test-Projekt. Es begann mit der Ausführung des Tests, aber dann trat ein verrückter COM-Fehler auf (CLSID nicht registriert) und das reichte mir. Auf keinen Fall werde ich all die dummen COM-Registrierungseinstellungen für Visual Studio 2005 aufspüren. Und was zum Teufel war das? COM? Ich dachte, wir hätten das vor etwa drei Compilern abgeschafft?
Daher blieb ich bei der Installation einer vollständigen Team Suite auf dem Server. Okay, ich werde beißen. Ich meine, ich brauche nicht alles, also wird es in Ordnung sein (rede ich mir immer wieder, während ich zuschaue, wie sich eine Million Registrierungseinträge füllen). Ein paar Stunden später starre ich wieder auf meine Eingabeaufforderung und gebe meinen MSTest.exe-Befehl ein. Und es erscheint ein Dialogfeld. Ja, ein modales Dialogfeld, das mir mitteilt, dass etwas nicht stimmt (ich erinnere mich nicht an die Einzelheiten, aber es war nicht sehr informativ).
Visual Studio wurde einwandfrei installiert und ich konnte die Lösung, die ich wollte, kompilieren, ausführen und erstellen, aber das Testen über die Befehlszeile mit MSTest.exe war ein No-Go. Egal wie sehr ich es versuchte, wie viel ich aufräumte oder wie viele Jungfrauen ich opferte, es wird einfach nicht gehen. Und es gibt noch ein weiteres Problem. Mit 2003 und unseren NUnit-Tests liefern wir einige schöne Statistiken. Zeitpläne, informative Nachrichten, all das gute Zeug. Mit MSTest bekommen wir nichts (außer x Anzahl ausgeführter Tests und vielleicht einem Fehler, aber ich konnte nicht so weit kommen, um zu sehen, ob es die Details des Fehlers liefern würde). Darüber hinaus beißt und produziert der MSBuild-Logger etwa 10.000 Zeilen Kauderwelsch, was nicht sehr nützlich ist. Ja, ich könnte meine Zeit damit verbringen, neues XSLT zu schreiben, um es hübsch zu machen, und die „Alles war in Ordnung“-Zeilen herausschneiden, die den MSBuild-Aufgabenlogger füllen, aber ich denke, dass das bei meinen Tarifen keinen Mehrwert bringt.
Hier ist eine Beispiel-E-Mail, die ich vom Build erhalten habe und die Ihnen eine Vorstellung davon gibt, wie nutzlos eine CC.NET/MSBuild/MSTest-Kombination ist:
BUILD SUCCESSFUL
Projekt: PROJEKTNAME
Erstellungsdatum: 08.12.2006 08:08:30 Uhr
Laufzeit: 00:00:55
Integrationsanforderung: IntervalTrigger hat einen Build ausgelöst (ForceBuild)
Fehler (1)
D:ccnetprojectsPROJECTNAMESourceReportsServerReportsServerReports.rptproj (2,1): Fehler MSB4041: Der Standard-XML-Namespace des Projekts muss der MSBuild-XML-Namespace sein. Wenn das Projekt im MSBuild 2003-Format erstellt wurde, fügen Sie bitte xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " zum <Project> hinzu. Element. Wenn das Projekt im alten 1.0- oder 1.2-Format erstellt wurde, konvertieren Sie es bitte in das MSBuild 2003-Format.
Warnungen (1)
SourceReportsServerReportsServerReports.rptproj (,): Warnung MSB4122: Das Scannen von Projektabhängigkeiten für das Projekt „SourceReportsServerReportsServerReports.rptproj“ ist fehlgeschlagen. Der Standard-XML-Namespace des Projekts muss der MSBuild-XML-Namespace sein. Wenn das Projekt im MSBuild 2003-Format erstellt wurde, fügen Sie bitte xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 " zum <Project> hinzu. Element. Wenn das Projekt im alten 1.0- oder 1.2-Format erstellt wurde, konvertieren Sie es bitte in das MSBuild 2003-Format. D:ccnetprojectsBRMSSourceReportsServerReportsServerReports.rptproj
Tests ausgeführt: 0, Fehler: 0, Nicht ausgeführt: 0, Zeit: 0 Sekunden
Es werden keine Tests ausgeführt
Dieses Projekt hat keine Tests
Änderungen seit dem letzten Build (0)
Es ist hässlich. Wirklich hässlich. MSBuild erzeugt eine Menge verrückter Ausgaben. Das Schreiben einer neuen MSBuild-Datei ist kein Kinderspiel, und selbst für jemanden wie mich, der sich mit NAnt recht gut auskennt, frage ich mich immer noch, wie MSBuild die Dinge macht. Ich musste eine spezielle Konfiguration innerhalb von Visual Studio erstellen, um unser Berichtsprojekt wegzulassen, da MSBuild sie nicht erstellen kann (daher das obige Ziel AutomatedBuild, das nicht dieselbe Konfiguration ist, die unsere Entwickler verwenden, und etwas, das ich nicht gerne mache, weil das eines ist Punkt eines CI-Servers, konsistente Builds für alle).
Aus der obigen Ausgabe geht hervor, dass Cruise der Build in Ordnung war, aber vom MSBuild-Logger (unserem Berichtsprojekt) kam eine Fehlermeldung. Da es sich um ein Projekt aus dem Jahr 2005 handelt, ergeben die Informationen keinen Sinn (ich glaube, es handelt sich um einen protokollierten Fehler, aber wer weiß, wann er möglicherweise behoben wird). Und ich kann die MSTest-Ausgabe wirklich nicht in die E-Mail integrieren, weil es ja keine gibt. In diesem Projekt gibt es ungefähr hundert Tests, aber der Logger produziert nichts.
Darüber hinaus gibt es einige Projekttypen, mit denen MSBuild nicht umgehen kann, und auch hier ist ein Raketenwissenschaftler erforderlich, um eine MSBuild-Datei zu erstellen (sogar mit etwas Coolem wie MSBuild Sidekick), die eine andere MSBuild-Aufgabe aufrufen und bestimmte Projekte ausschließen kann. Das ist sicherlich nicht mehr so einfach wie im Jahr 2003, als Sie einfach eine Ausschlussliste erstellt haben (wir haben unsere Client-App ausgeschlossen, da es keine zusätzliche Lizenz für die Rastersteuerung gab und ein modales Dialogfeld angezeigt wurde, als die Testversion überhaupt angeschaut wurde). des Compilers).
Okay, das ist größtenteils eine Schimpftirade, aber hier steckt eine gewisse Weisheit drin. Kontinuierliche Integration muss nicht so schwierig sein. CruiseControl.NET ist ein hervorragendes Tool und sehr flexibel mit neuen Tools und der Integration der Ausgabe dieser Tools. Wenn diese Tools jedoch eine Million Registrierungseinstellungen und noch mehr DLLs erfordern (an ganz bestimmten Orten abgelegt, glauben Sie mir, Sie können sie nicht einfach in den GAC werfen und Schluss machen) und Unmengen von XML-Dateien ausgeben, die kein Normalsterblicher (nun ja) kann vielleicht könnte DonXml übersetzen, es ist einfach falsch. Und was den integrierten Team Build betrifft, den Sie uns anbieten könnten, ist er ebenso nutzlos, da a) Sie Builds nicht so planen können, dass sie durch Code-Checkins ausgelöst werden, und b) wiederum die Installation eines vollständigen Team Suite-Clients auf dem Server erforderlich ist . Im schlimmsten Fall dauerte es 4 Stunden, als ich mit der Einrichtung von CC.NET-Servern begann. Jetzt kann ich es in einer Stunde erledigen (einschließlich des Testens des Builds des ersten Projekts). Ich habe bereits einen guten Tag damit verbracht, einfach zu versuchen, etwas zum Kompilieren zu bekommen. Es wird gerade kompiliert, aber die Ausgabe ist Mist und es werden keine Tests ausgeführt, und das ist einfach nicht gut genug für mich. Sie können MSBuild und (vielleicht) MSTest mit CruiseControl.NET zum Laufen bringen. Es ist nicht unmöglich. Wenn Sie den vollständigen Client installieren und Ihre Projekte „genau richtig“ sind, funktioniert es, aber die Ausgabe ist nicht so heiß und Sie werden zusehen, wie die CPU Ihres Servers beim Kompilieren überlastet wird.
Mein Rat: Versuchen Sie nicht, MSBuild, MSTest und CruiseControl zu kombinieren, und bleiben Sie bei NAnt und NUnit (verwenden Sie MSBuild, wenn Sie 2005-Lösungen erstellen müssen).
Unnötig zu erwähnen, dass ich gerade über eine Option nachdenke. Dumping der Installation von VS2005 auf dem Server, Umstellung aller unserer Unit-Tests zurück auf NUnit und Verwendung von NAnt für alles (und Aufrufen von MSBuild einfach als Exec-Task für VS2005-Projekte). Ich muss noch 2003-Projekte ausführen, damit unser CI-Server wie ein Frankenstein-Monster aussieht, wenn ich damit fertig bin, VS2003- und VS2005-Projekte zu erstellen, NUnit, MSBuild, NAnt, Simian, FxCop und was auch immer wir sonst noch in unserem haben, auszuführen mischen. Auch wenn die Ausgabe mit NAnt einfacher ist (und sich gut in CC.NET integrieren lässt), wird die Testausgabe nützlich und informativ sein und ich muss keine 15.000-Dollar-Software auf einem Server installieren, der diese Möglichkeit bietet um eines Tages einen modalen Dialog aufzurufen, wenn ein Registrierungsschlüssel nicht gefunden werden kann.
Grrr. Argh.