Category

Jazz ist nicht nur eine Musikrichtung,

sie kümmert sich auch um Software Projekte.

Jazz ist eine von IBM entwickelte CLM Plattform. Dort können Requirements, Issues (Tasks and Defects) und Dokumentationen auf einer Plattform verwaltet, verlinkt und in verschiedenen Project Areas verwendet werden. Eines der Anwendungen ist das IBM Rational Team Concert (RTC), welches sich um all die Themen kümmert, die in der Software Entwicklung vorkommen:
Iterations und Release Planung, Change Management, Defects Überwachung, Source Control und Build Automation (RTC Build). Jazz bietet eine grosse Möglichkeit an kundenspezifischer Konfiguration. Es eignet sich gut um das agile Framework SAFe 4.0 einzusetzen. Erwähnenswert ist auch, dass Jazz bis zu 10 Nutzern kostenlos ist.

RTC build

Vor kurzem durfte ich in einem neuen Projekt einen Build Server mittels der Jazz Build Engine (JBE) einrichten. Das war für mich ein komplett neues Thema und auch eine Herausforderung. Bisher war ein Build Server immer vorhanden und ich musste nur prüfen, dass er nach meinem Checkin weiterhin fehlerlos durchlief. Dadurch musste ich mich in einige Themen neu einarbeiten oder war auf vorhandenes Know How angewiesen. Trotz der aktiven Jazz Community war die Lösungsfindung für meine .Net – Jazz (JBE) spezifischen Fragen sehr langwierig.

RTC-Plugin für Eclipse

Um die Build Definition für die Jazz Build Engine zu konfigurieren, stellt Jazz ein RTC-Plugin für Eclipse bereit. Dies unterstützt dabei, die benötigten Pfade und anderen Properties zu definieren, wie zum Beispiel die Email Notifications, der Build Scheduler, Pre- und Post Build Events und das Nutzen von Test Frameworks.

Build Server konfigurieren

Auf dem Build Server müssen die benötigten Versionen verfügbar sein:

Nachdem der Build lief, wandte ich mich unseren Unit Tests zu und damit kam für mich eine richtig harte Nuss. Beim Test Framework haben wir uns vorerst für MSTest entschieden. Wir hatten uns auch nunit3 angesehen, jedoch haben uns die Vorteile von MSTest für unser Projekt überzeugt. Das RTC-Plugin bietet eine scheinbar einfache Konfiguration für MSTest an, der Build Server hatte es schon einsatzbereit und ein Schwesterprojekt setzt es schon erfolgreich ein.

Nach einiger Recherche habe ich herausgefunden, dass die benötigte .vsmdi Datei, welche das RTC-Plugin forderte, veraltet ist und es keine neuere Möglichkeit für MSTest in dieser Konfiguration gibt. Nun haben wir im Team noch einmal diskutiert, ob wir nicht doch auf Nunit wechseln sollten. So ergab sich ein neuer Anlauf mit Nunit3, aber auch hier stellt uns das RTC-Plugin vor eine verschlossene Türe – es fordert das «nunit configuration test file».

Als erster Link unter google für «nunit configuration test file» erscheint die nunit.org Seite, die gleich darauf hinweist, dass dieses config file veraltet ist und nicht für nunit3 gilt.

Nun war die Frage, sollen wir wegen unserem Build Server auf ein veraltetes Test-Framework bauen?

Die Antwort war «Ant».

Ant Script für RTC build

Anstatt bei der Build Definition Microsoft Build auszuwählen, bietet das RTC-Plugin auch eine Ant Configuration:

In dieser Configuration wird ein Ant Script erwartet. Mithilfe dessen werden abhängige und unabhängige Prozesse/Tasks gestartet. Nun braucht man nur noch ein Ant Script, welches all diese Tasks beinhaltet. Die Tasks kann ich in einzelne Targets und Activities unterteilen, so dass in der RTC Weboberfläche der Buildprocess in Schritten dargestellt wird. Wie im unteren Bild dargestellt, sehen wir so die einzelnen Tasks und die Zeit der Ausführung. Falls ein Task fehlschlägt, wird dieser gekennzeichnet und wir sehen sofort wo ein Problem besteht.

Wir nutzen nun das Ant Script um nuget packages zu laden, npm packages zu installieren, unsere Projekte zu builden und nunit Tests durchzuführen. Hätten wir noch MSTest Tests, könnten wir diese auch darüber starten.
Nachdem die nunit Tests durchgelaufen sind, kann das Resultfile ins Repository geladen werden. Die Weboberfläche im Build zeigt dann das Ergebnis an.
Die nunit Tests generieren jedoch xml Dateien, welche nunit Syntax enthalten. Die JBE versteht aber nur Junit. Damit die JBE das Ergebnis auch interpretieren kann, gibt man eine Übersetzungsdatei (.xslt) im commando an, so konvertiert nunit3 die Ergebnisdatei zu einer junit xml.

Ein Nachteil für uns mit Ant Script ist, dass man jedes Test Projekt einzeln aufrufen muss. Deswegen müssen wir das Ant Script bei jedem neuen nunit Test Projekt erweitern. Momentan ist es für uns keine Option, die Liste mit einer Wildcard auszutauschen, da wir noch nicht alle Test Projekte über den Automation Build starten möchten.

Hier ein Beispiel, wie der Aufruf der nunit3-console.exe im Ant Script aussehen kann:

<property name="nunit.transformedfile" value="junitout.xml"/>
<property name="nunit.transformation" value="nunit3-junit.xslt"/> 
<property name="nunit.resultfile" value="testresults.xml"/> 


<startBuildActivity activityIdProperty="runNunitTests"
      label="run nunit runNunitTests..."
      buildResultUUID="${buildResultUUID}"
      repositoryAddress="${repositoryAddress}"
      userId="${userId}"
      passwordfile="${passFilePath}" />

<exec executable="C:/.../nunit-console/nunit3-console.exe" failOnError="false">
	<arg value="com.asdf.qwe.Unit/bin/RTCConfig/qweTest.dll" />
	<arg value="com.asdf.asdf.Unit/bin/RTCConfig/asdf.Unit.dll" />
	<arg value="com.asdf.asdf.Test/bin/RTCConfig/asdf.Test.dll" />
	<arg value="--result:${nunit.transformedfile};transform=${nunit.transformation}" />
</exec>

<junitLogPublisher filePath="${nunit.transformedfile}"
			 buildResultUUID="${buildResultUUID}"
			 repositoryAddress="${repositoryAddress}"
			 userId="${userId}"
			 passwordFile="${passFilePath}" /> 

<delete file="${nunit.transformedfile}"/>

<completeBuildActivity activityId="${runNunitTests}"
      buildResultUUID="${buildResultUUID}"
      repositoryAddress="${repositoryAddress}"
      userId="${userId}"
      passwordfile="${passFilePath}" />
</target>

Links..

Der erste Einstieg für mich waren diese zwei Seiten: How To Use Jazz Ant Tasks For Microsoft VisualStudio und Continuous Integration with Rational Team Concert and Microsoft Visual Studio
Und eine gute Unterstützung für das Ant Script war dann folgender Blog: Getting Started with Ant scripts and RTC Build Ant Tasks

Wäre mir eher bewusst geworden, dass ich Ant für mein Problem einsetzen kann, hätte ich mir einige Zeit und Nerven gespart. Aber man lernt ja nie aus und wächst mit seinen Herausforderungen, die einem Noser Engineering ermöglichen ;-).