Hier sind die Slides von meinen Vortrag auf der Tools 4 Agile Teams 2012 in Wiesbaden.

In unserem aktuellen Projekt werden ziemlich viele Selenium Tests erstellt und ausgeführt. Selenium Tests bedürfen einer besonders Intensiven Wartung und Pflege. Der Kunde wünschte sich ein Monitoring über den Zustand der Tests in zeitlicher Hinsicht. Jenkins bietet einige Plugins zur Visualisierung an, aber das reichte uns nicht. Ziel war es eine Gesamtsicht  und Einzelsicht auf alle Test Module zu haben. Bei jeden Test sollte erkennbar sein bei welchen Build Lauf er erfolgreich war oder nicht.

UnitTH ist ein kleines Java Tool das aus den Unit Test Ergebnis Dateien einen Report erzeugen kann.

Das Tool untersucht bestehende Unit Test Report XML Dateien und erzeugt daraus ein einen Report. Die zeitliche Achse wird durch Build Läufe erzeugt. UnitTH erkennt die Build Läufe anhand von Ordnern.

Die Reports muss in dieser Struktur vorliegen:

/build1/junit_log1.xml
/build1/junit_log2.xml
/build2/junit_log1.xml
/build2/junit_log2.xml

In den Ordnern können beliebig viele XML Dateien liegen.

Testsuiten sind für das Tool sogenannte Module. Damit wird der Report gegliedert. Man muss also darauf achten das die Suiten in den Reports eindeutige Namen haben und nicht verschachtelte Suiten haben. Meine Report Dateien haben nicht ganz dem Schema entsprochen. Ich wandel die Dateien mit XSLT um.

Der Aufruf erfolgt so:

java -jar -Dunitth.report.dir=/…/unitth/report unitth.jar /…/unitth/xml/*

Man gibt also nur das Ziel Verzeichnis für die Reports und den Pfad zu den XML Dateien.

In den Report bekommt man eine praktische Übersicht über den aktuellen Stand der Tests und den Trend.

Über die Graphen kann man erkennen, wie sich die Testdauer verhält und ob sich die Anzahl der Tests verändert.

Man bekommt eine Liste der Build Läufe und darin zusammengefasst wie deren Status war. Hier sieht man auch schön die aktuellen Trends.

Die Module (Testsuiten) werden auch zusammengefasst dargestellt und man kann sich auf einer Unterseite den Verlauf auf Testcase Basis anschauen. Dadurch kann man besonders kritische Testfälle erkennen und dann stabilisieren.

Das spannendste Feature ist die Spread Ansicht. Hier sieht man, bei welchen Build die Testfälle fehlgeschlagen sind. Damit kann man sogenannte "Blinker" Test finden. Um diese dann zu Isolieren.

Es kann relativ aufwendig sein einen sinnvollen und realistischen Testplan mit JMeter zu erstellen. In unseren Fall wollte ich diesen Testplan auf verschiedenen Testumgebungen einsetzen und mal mit der JMeter Gui und mal auf der Konsole mittels Jenkins laufen lassen. Hierbei unterscheiden sich die Urls, Userdaten und Laufzeiten des Tests. Wenn ich den Plan kopiert hätte, wäre die Wartung sehr aufwendig.

JMeter Properties

Es gibt bei JMeter die Möglichkeit eine Properties Datei für den Testplan anzugeben.

jmeter –p dev.properties –t testplan.jmx

In dieser Datei kann man beispielsweise die Domain definieren.

domain=example.com

Im Testplan kann man auf diesen Wert dann wie folgt zugreifen:

${__P(domain)}

Man kann auch einen Default Wert angeben.

${__P(domain,www.example.com)}

JMeter Funktionen

Mit dem JMeter Funktionen kann man noch einiges mehr machen. Beispielsweise: Daten aus einer CSV lesen oder Zufallszahlen verwendet.

http://jakarta.apache.org/jmeter/usermanual/functions.html

Im Hilfe Menü gibt es ein ganz praktisches Tool um mit den Funktionen zu arbeiten. Hierbei wird einem auch der richtige Code generiert.

Berechnungen

Es lassen sich auch Berechnungen durchführen. Diese werden mit der Javascript Funktion gemacht:

${__javaScript(${DURCHSATZ}/100*38.5)}

Wir hatten die Aufgabe für eine Webseite Lasttests zu erstellen. Die zu erzeugende Last sollte sehr real sein. Da man mit einen einzigen Rechner nicht so eine hohe Last erzeugen kann haben wir uns für die Amazon Cloud entschieden. Dort kann man für einen kurzen Zeitraum eine hohe Zahl an Rechnern verwenden und das mit sehr geringen Kosten.

Als Lasttest Tool wird JMeter verwendet. Mit JMeter kann man sehr granulare Testpläne erstellen und damit ein relativ gutes Abbild der realen Last simulieren.

http://jakarta.apache.org/jmeter/

JMeter ist in der Lage die Tests über verteilte Rechner auszuführen. Dadurch kann man eine sehr große Last erzeugen.

http://jakarta.apache.org/jmeter/usermanual/remote-test.html

JMeter ist in der Lage alle Anfragen über einen Proxy laufen zu lassen. So kann man IP geschützte Seiten testen indem man die IP vom Proxy freischaltet. In unseren Fall verwenden wir den Squid Proxy mit einer geschützten Authentifizierung.

Vorbereitung

Proxy Server AMI erstellen

In der Amazon Cloud gibt es sogenannte AMI (Amazon Machine Images). Das sind Abbildungen von Systemen die man erstellen kann um diese immer wieder zu verwenden.

AMI erstellen

AWS Management Console https://console.aws.amazon.com/ec2/ auf den Reiter ec2 wechseln und eine Instanz starten. Den  Rechner nach eigenen Wünschen anpassen und dann über das Menü „Instance Action“ eine AMI erstellen. Amazon erstellt dann von dem aktuellen System ein Abbild das man wiederverwenden kann.

Squid Proxy in der Cloud installieren:

http://home.engineering.iastate.edu/~hawklan/squidProxy/squidProxy.html

Dieser Proxy muss natürlich abgesichert werden, da er sonst missbraucht werden könnte.

Passwort Authentifizierung einrichten

In der Squid Konforgurations Datei (/etc/squid/squid.conf) muss als erstes das Authentifizierungs Programm eingestellt werden. Es gibt diverse Möglichkeiten. ncsa_auth ist wahrscheinlich die einfachste. Man erzeugt mit htpasswd eine Passwort Datei (/etc/squid/squid_user) und gibt diese in der Konfiguration an.

auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/squid_user

Der Proxy lässt sich damit nur noch mittels Usernamen und Passwort aufrufen.

Caching auschalten

Squid speichert die Anfragen normalerweise. Das würde aber das Ergebniss verfälschen. Deshalb muss man noch das Caching ausschalten. Dazu genügt es folgende Zeile in die Squid Konforgurations Datei (/etc/squid/squid.conf)  einzufügen.

cache deny all

Proxy automatisch starten

Damit der Proxy automatisch mit dem Starten der Instanz mit gestartet wird kann man in der Datei /etc/rc.local diesen Befehl eintragen /etc/init.d/squid start .

Proxy starten

In der AWS Management Console starten wir die vorgefertigte AMI.

JMeter Master Server

Für den JMeter Master Server verwenden wir einen vorgefertigte Windows AMI bei der JMeter vorinstalliert ist. Dieser Rechner kann dann über Remote Desktop bedient werden.

Auf den Master Server muss dann der Testplan kopiert werden.

Auf dem Master Server wird die Testausführung gesteuert.

JMeter Slaves

Die JMeter Slaves sind beliebig viele Linux Rechner auf denen der JMeter im Server Modus gestartet ist. Dafür benötigt man eine AMI auf der JMeter vorhanden ist und dieser Befehl Autostart (/etc/rc.local) ist

{pathtojmeter}/bin/jmeter-server

Dafür steht auch die öffentliche AMI zur Verfügung: ami-823f0df6

Die Adressen der Slave Rechner müssen in die JMeter Properties Datei auf den Master Server eingetragen werden. So das dieser seine Remote Maschinen kennt.

jmeter.properties

remote_hosts=...,....

Starten der Tests

Wenn die Slaves hochgefahren sind kann der Testplan auf den Remote Servern gestartet werden.

Hier ein kurzer Rückblick auf die Typo3 Konferenz in Hanau und die PHP Konferenz in Mainz.

Typo3 Konferenz

Die Konferenz fand dieses Mal in Hanau statt und hatte angenehmere Räume als die letzten Jahre. Das Catering hat sich aber leider extrem verschlechtert und war ungenießbar.

Sonar

Es gab einen Vortrag über Sonar,  ein Tool mit dem man sehr übersichtlich Metriken darstellen kann. Es war für mich neu, dass es unter http://metrics.typo3.org/ einen Sonar Server mit den Metriken zu allen Typo3 Extension gibt.

Ein Mitarbeiter der d.k.d  plant eine neue TER Plattform in der man diese Sonar Daten mit einer Suche verknüpfen kann und darüberhinaus die Extension noch mit Sozialen Daten anreichern kann. Eine schöne Vision die eventuell Ende des Jahres verfügbar ist.

Flow3

Das Flow3 Framework steht vor der ersten stabilen Version. In einem Talk wurden die Erfahrungen mit Flow3 in der Praxis präsentiert. Als Fazit kann man sagen das Flow3 schon einsatzfähig ist und sich der Einsatz lohnt. Wenn man schon mit Extbase gearbeitet hat, ist der Einstieg extrem leicht. Das kann ich nur bestätigen, da wir Flow3 auch in der Praxis einsetzen und keinerlei Probleme hatten.

IPC11

Die PHP Konferenz fand wieder mal in Mainz statt und hier war das Catering richtig gut.

PHP 5.4

Traits

Die schönste Neuerung in PHP 5.4 sind für mich die Traits. Damit kann man quasi eine Mehrfachvererbung einsetzen. Ich hatte immer mal wieder Stellen bei denen das notwendig gewesen wäre.

Class Produkt {
    Public function getPreis(){}
}
Class UserItem {
    Public function getItemId(){}
}
Class UserProdukt extends UserItem use Produkt(){
}

In diesen Fall habe ich ein Produkt aus einen Katalog und ein gekauftes Produkt eines Kunden. Mit Hilfe der Traits kann ich bei meinen Kunden Objekten in meiner Vererbungslinie bleiben, aber trotzdem die Produkt Methoden verwenden. Man kann das Vererbungsverhalten auch noch konfigurieren und die Namen der Methoden überschreiben oder deren Sichtbarkeit ändern.

Arrays in Rückgaben verwenden

Es ist jetzt möglich Arrays aus Rückgabewerten direkt zu verwenden ohne die Variable zwischen zu speichern:

foo()[42]

Neuer Typehint

Leider gibt es immer noch keine Typehints für scalare Werte. Dafür gibt es einen neuen Typehint callable.

Integrierter Webserver

PHP hat jetzt einen integrierten Webserver für Development Zwecke. Dieser ist sehr einfach gestrickt und mir ist der Sinn dessen nicht ganz klar geworden.

JsonSerializable

Über das neue Interface JsonSerializable kann man steuern welche Daten beim json_encode indem man die Daten über die Methode jsonSerialize zurück gibt.

Openstreetmap

Es gab einen spannenden Vortrag über Geo Berechnungen mit vielen Formeln einiges an Theorie zu diesen Thema. Es wurde besonders das Projekt Openstreetmap hervorgehoben. Dieses bietet eine gute Alternative zu Google Maps, da man die Daten lokal speichern kann und somit auch mit Karten ohne Internet Verbindung arbeiten kann.

Slides

Liquibase

Über Liquibase wurde ja vor kurzem im PHP Magazin berichtet. Hier hatte ein Entwickler von Mayflower seine Erfahrungen mit Liquibase geteilt. Mit Liquibase kann man die Datenbank Änderungen versionieren und sehr komfortabel deployen. Es ist ein sehr mächtiges Java Tool das sich gut in Continuus Deployment Prozesse integrieren lässt.  Besonders interessant, finde ich die Roleback Möglichkeit. Auch andere Teilnehmer in den Talk berichteten von ihren Positiven Erfahrungen mit dem Tool.

Unter dieser Adresse findet man alle Links zu den Slides der Konferenz
http://joind.in/event/view/806

Serverumzug mit Kunagi

Um Kunagi auf einen neuen Server zu transferieren muss man keine Datenbank kopieren, da Kunagi ausschließlich XML Dateien zur Speicherung der Daten verwendet. Es gibt aber 2 Dinge die beachtet werden müssen:

1. Url Änderung
   Wenn sich die URL ändert muss das auch in in der Datei /webapps/kunag/iconfig.properties angepasst werden.
2. Starten des Kunagi
   Das Startup Script muss immer von dem gleichen Verzeichniss aus gestartet werden damit Kunagi die richtigen XML Dateien findet. Mann muss das Script auf den neuen Server vom gleichen Verzeichniss starten wie auf den alten Server. Oder relativ gesehen zum /webapps/kunagi Verzeichnis.

Fehlender Burndown Chart unter Linux

Unter Linux kann es beim Erzeugen des Burndown Chart zu folgenden Fehler kommen:

FATAL AHttpServlet         GET failed: scrum.server.sprint.SprintBurndownChartServlet -> 
java.lang.NoClassDefFoundError: Could not initialize class org.jfree.chart.JFreeChart

Das Problem liegt nicht an Kunagi sondern an Java und kann behoben werden in dem man beim Starten des Tomcat folgende Optionen mitgibt:

-Djava.awt.headless=true

Kunagi  http://kunagi.org/ ist eine art digitales Whiteboard zu Unterstützung von Scrum Prozessen.

Das Tool ist webbasiert und kostenlos. Es basiert auf der GWT http://code.google.com/intl/de-DE/webtoolkit/ von Google und benötigt einen Tomcat.

Kunagi hält sich streng an die Regeln von Scrum. So kann im Backlog auch nur der Product Owner eine Story anlegen.

Die Story kann erst in den Sprint aufgenommen werden wenn es geschätzt wurde.  Dafür kann man das Planing Poker starten. Dann erscheint bei allen Usern dieser Poker Screen.

Die Storys können dann in den Sprint übernommen werden. Dort sieht man dann alles Story und die Zusammenfassung

der Punkte.

Dreh und Angel Punkt beim Scrum ist das Whiteboard. Dieses bekommt man in Kunagi mit den 3 Spalten angezeigt und kann zu jeder Story Tasks erstellen. Das sind dann die Notizzettel die man nehmen kann und schließen kann. Hier sieht man auch wer an welchen Punkten arbeitet.

In den Task kann man auch angeben wie viel man davon schon gemacht hat.

Kunagi generiert auf dieser Daten Basis den Burndown Chart.

Hier kann man sehen ob man noch in dem Zeitplan ist und ob man noch Punkte aufnehmen kann oder entfernen muss.

Wir nutzen das Tool jetzt seit einem Sprint und ich bin begeistert. Man hält sich viel strenger an die Scrum Regeln und der Burndown Chart hat wirklich einen Mehrwert. Dem Kunden gefällt das Tool auch da er immer den Überblick hat was das Team gerade macht und ob zeitlich alles hinhaut. Ab und zu kommen mal kleine Fehlermeldungen aber es nichts Gravierendes. Das Tool macht einen professionellen Eindruck.