|
|
Das AIT Build Package besteht aus einer Reihe von Erweiterungen für das Build System des Team Foundation Servers. Diese erleichtern die Tasks, die mit dem Build Package ausgeliefert werden, viele Standardabläufe, die bei vielen Kunden benötigt werden. Bei der aktuellen Erweiterung des Build Package sind die nachfolgenden Erweiterungen hinzugekommen:
Die Ausführung von Unit Tests im Buildprozess kann komfortabel über Testlisten verwaltet werden. In manchen Fällen ist das aber nicht anwendbar, z.B. wenn zu viele Solutions gebaut werden und die Tests in Form von Test-Assemblies vorliegen. Hierbei sollen alle Tests ausgeführt werden, die im Source Ordner eines Projektes stecken. Gleichzeitig sollen Code Coverage Werte ermittelt werden.
Dabei treten folgende Fragestellungen auf:
Dieser Beitrag soll die Antworten aufzeigen.
Die zentralen Builds im Team Foundation Server legen ihr Ergebnis in Form der Binaries, Log-Dateien und Ähnlichem in einer dedizierten Freigabe ab. Welche Freigabe im Netzwerk verwendet werden soll, lässt sich selbstredend konfigurieren. Allerdings ist das mit Einschränkungen verbunden. Wie man diese Einschränkungen überwinden kann, soll dieser Artikel zeigen.
Wer bereits die Targets BeforeCompileSolution und AfterCompileSolution verwendet hat, um eigene Aktionen während eines Buildprozesses im TFS auszuführen, wird das Problem kennen. Eigene Properties besitzen keine Werte mehr, sie schein nicht definiert zu sein. Und tatsächlich ist das auch das Problem. Aus Gründen der Rückwärtskompatibilität wird zwischen den Targets BeforeCompile und AfterCompile das Target CallCompile aufgerufen. Dieses nutzt den MSBuild-Task, um CoreCompile aufzurufen, welches letztendlich die SolutionsToBuild kompiliert. Hier ein Code-Ausschnitt aus der Datei Microsoft.TeamFoundation.Build.targets:
<Target Name=”CallCompile” DependsOnTargets=”$(CoreCompileDependsOn)”>
<!– Backwards Compatibility –>
[...]
<!– Pass in all properties that users might want during the course of the compile targets. –>
<MSBuild Projects=”$(MSBuildProjectFile)”
Properties=”BuildAgentName=$(BuildAgentName);BuildAgentUri=$(BuildAgentUri);BuildDefinitionName=$(BuildDefinitionName);BuildDefinitionUri=$(BuildDefinitionUri);
BuildDirectory=$(BuildDirectory);BuildNumber=$(BuildNumber);CompilationStatus=$(CompilationStatus);CompilationSuccess=$(CompilationSuccess);
[...]
SolutionRoot=$(SolutionRoot);BinariesRoot=$(BinariesRoot);TestResultsRoot=$(TestResultsRoot);
$(CustomPropertiesForBuild)”
Targets=”CoreCompile”>
<Output TaskParameter=”TargetOutputs” ItemName=”CompilationOutputs” />
</MSBuild>
<OnError ExecuteTargets=”SetBuildBreakProperties;OnBuildBreak;” />
</Target>
Der durch Team Foundation Build vorgegebene Buildablauf gestaltet sich wie folgt (Einstiegspunkt ist das Target Compile):
Es fällt ein Property namens CustomPropertiesForBuild auf. Tatsächlich dient es dazu, eigene Properties in den Build (Target Compile) “einzuschleusen”. Dazu definiert man spätestens im Target BeforeCompile folgende PropertyGroup:
<PropertyGroup>
<CustomPropertiesForBuild>
MyCustomProperty1=Value1;
MyCustomProperty2=ValueFirstPart%3BValueSecondPart;
</CustomPropertiesForBuild>
</PropertyGroup>
MyCustomProperty2 enthält im Wert ein Semikolon. Dieses würde aber beim Aufruf von MSBuild als Trennungszeichen für das nächste Property interpretiert werden. Daher müssen Semikolons, die im Property enthalten sein sollen (z.B. bei Datenbank-Connection-Strings) mit %3B escaped werden (Kommandozeilen-Escape).
Mit diesen Properties kann man dann in den Targets BeforeCompileSolution und AfterCompileSolution arbeiten…
Viele Kunden, die aus stark diversifizierten Entwicklungsumgebungen zum Visual Studio Team System migrieren, stehen vor der Herausforderung, auch ihre gesamte Testplattform entweder zu integrieren oder neu aufzubauen. Der Neuaufbau fällt schwer, wenn sehr viele Tests auf Basis von Legacy-Code existieren. Wenn bereits die vollständige Migration des Legacy-Codes nicht in Betracht kommt, so werden auch die Tests nicht ohne Aufwand und weitere Risiken zu migrieren sein. Dennoch liegt der Nutzen einer solchen Migration z.B. von NUnit-Tests nach MSTest auf der Hand. Können die Testergebnisse von MSTest doch komfortabel mit Visual Studio ausgewertet werden.
Zudem lassen sich die Testergebnisse in Form von .trx-Dateien direkt an den TFS publizieren. So erhält man ein vollständiges Reporting über die gelaufenen Tests. Zum Beispiel im Quality-Indicators-Report:
Für die einfache Integration von NUnit-Tests haben wir ein Tool namens Unit Test Result Converter geschrieben, welches Ergebnisdateien aus den verschiedenen Legacy-Testplattformen nach MSTest konvertiert.
Ziel eines Pilotprojektes bei der AIT AG rund um den TFS war die automatisierte Erfassung reproduzierbarer Kennzahlen für das Software-Management. Dabei wurde ein Messprozess auf Basis der Anforderungen von CMMI v1.2 und ISO/IEC 15939 erarbeitet und mit dem Visual Studio Team System umgesetzt werden. Desweiteren entstand ein Framework zur einfacheren Integration von Drittherstellerwerkzeugen in das Visual Studio Team System. Im Rahmen eines ersten Pilotprojektes wurden für das Management wesentliche Softwaremaße ermittelt und ausgewertet. Die Ergebnisse sollen in naher Zukunft auf ein laufendes Software-Entwicklungsprojekt übertragen und ausgereift werden. Während in einem Artikel Anfang des Jahres die ersten Ansätze veröffentlicht wurden, sollen im folgenden die Ergebnisse des Pilotprojektes kurz umrissen werden.
Kürzlich stellte sich uns die Anforderung, Unit-Tests auf einem virtuellen PC während des Buildprozesses auszuführen und die Ergebnisse im Build sichtbar zu machen - sprich die Testergebnisse auf den TFS zu pulbizieren. Der Kunde, der die Anforderung stellte, wollte damit umfangreiche Smoke-Tests auf mehreren Zielplattformen automatisieren. So sollte es z. B. möglich sein, eine Applikation auf einem Windows XP und Vista zu testen. Dazu wurden mehrere virtuelle PCs (hier mit VM-Ware) erstellt und Snapshots erzeugt. Im Buildprozess sollen diese gestartet und für das Applikationsdeployment verwendet werden. Nach einiger Zeit der Evaluierung mit dem Visual Studio Load Test Agent, entschieden wir uns für eine Scripting-Lösung. Wir wollten mstest.exe remote auf dem VPC ausführen.
Um ein verteiltes Test-Szenario umzusetzen, muss man evtl. mit mehreren Testlauf-Konfigurationen (Abb. Solution mit mehreren testrunconfig-Dateien) arbeiten und diese in einem Build ausführen. Der Standard-Buildprozess kann nur die in der .vsmdi-Datei aktivierte Testrunconfig verwenden. Dies ist für Tests auf mehreren VSTT-Controllern (Visual Studio Team System Load Test Controller) aber nicht ausreichend. Wir haben daher den Buildtypen angepasst, um auch dieses Szeanrio zu unterstützen.
Das Programm tf.exe ist ein Kommandozeilenwerkzeug, mit dem auf den TFS zugegriffen werden kann. Mit diesem können beispielsweise Branches und Merges von der Kommandozeile heraus ausgeführt werden. Wenn das Tool weitere Informationen vom Benutzer benötigt, so werden diese mittels eines grafischen Dialogs abgefragt. Um dies zu vermeiden kann man das Tool mit der Option /noprompt ausführen. Dabei beendet sich das Programm mit einer Fehlermeldung, wenn es weitere Informationen bräuchte. Diese Option ist besonders interessant, wenn man das Tool innerhalb eines Teambuild Prozesses verwenden möchte.
Wenn man tf.exe jedoch lokal und ohne die /noprompt Option aufruft, erscheint nicht wie erwartet ein Dialog, wenn das tf.exe weitere Daten vom Benutzer erwartet. Stattdessen beendet sich tf.exe mit einer Fehlermeldung. Das Abfragen von Daten kann bei einem lokalen Build jedoch explizit erwünscht sein. Für diesen Fall kann auf die Option /prompt zurückgegriffen werden, die jedoch nicht dokumentiert ist.
