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 ;-).

This is actually something I learned from my creative writing education. Whenever you have a sentence, you think is most beautiful, but doesn’t really fit into the whole text, than you will have to delete it. As a writer this was the hardest lesson to learn for me. I always, always stuck to my darlings and didn’t want to let them go. I wanted to create a happy place for them and what happens was, that I destroyed the rest of the text just to keep them. If you really love them so much, give them a place in your notebook and save them for later. But we all know what later means, yes?, later means never. That’s why it’s best to just kill them. “Killing” because it’s a brutal act for yourself and you might shed some tears. Maybe it helps you to remember, that it was you, who created that wonderful sentence or had that wonderful idea and then get over it.

Why do I talk about this? Because this week – it was a real hacking week with high code output from my part – I realized that this principle also applies to coding.

In our current sprint we had to develop a synchronization of documents. Doesn’t sound all too difficult, though. The web service interface to the other system wasn’t entirely clear and we had to wait for the access users, a query to gather all documents and stuff, so I decided we start with the writing to our database part. I designed a nice separation of concern architecture were we could inject the web service later when we had the saving part up and running as well as unit tested. That worked out pretty well and took more than half of our sprint. When we finally got access to the documents server in our last days of the sprint, we found out that opening a connection to the system was slow and the documents were big. We could have guessed that from the beginning, but at least I didn’t. When I tried to fit the service into our nice architecture, I got horrible performance and memory exceptions.

It was Tuesday afternoon, only 3 days in the sprint to go and I didn’t want to let go of the design and the work we had done so far, so I tried several different ways to still fit the service in. None of them really made me happy. The solutions I came up with killed the separation of concern anyways and weren’t much faster either. I discussed with my team member and told him, it might be best for him to go home, because I might have to redesign the whole thing. It was just then when I remembered the killing your darlings lesson I learned from writing. At 6pm I decided to throw the work of two team members away, as well as all the unit tests and code a whole new approach.

Please don’t misunderstand me, I delete, undo and throw away code all the time. I actually have no big problem with that. My problem was that I had to redesign the whole architecture of the code and throw away the unit tests! Ok, actually I just wanted to keep the unit tests! If I just could have kept the whole interfaces and redesign the black box inside, I could have nicely use my unit tests to see that still all is up and running as expected. And the unit tests took so much time to write! And I did such a nice TDD approach with them. It was really hard to let them go, but they are history now. And with history I don’t mean that there are no unit tests now, I just had to rewrite them too.

I rewrote the code in one day and made it work. Performance is good now and the goal is reached.

The end of the story? If you ever cry about throwing away your code or unit tests, you might just remember me and kill your darlings right away. Maybe it helps you to remember, that it was you, who created that wonderful code or architecture and then get over it.