SAA:Hudon und Subversion

Aus THM-Wiki
(Weitergeleitet von Hudson)
Wechseln zu: Navigation, Suche

Im Rahmen der Veranstaltung Softwarearchitektur und Anwendungsentwicklung (SAA) wollen wir das DotPlot-Projekt der FH-Gießen-Friedberg von CVS nach SVN migrieren und ein System für Continuous Integration bereitstellen, das die Möglichkeit bietet mehrere Projekte zu verwalten und Metriken für diese zu erstellen.

Einleitung

TODO


Gruppenmitglieder:

  • Julian Hochstetter
  • Florian Weber
  • Alexander Ehnes
  • Benjamin Stadin

Debian Server Konfiguration

Apache2

000-default

ServerAdmin webmaster@localhost
DocumentRoot /var/www/
<Directory />
  Options FollowSymLinks
  AllowOverride None
</Directory>
<Directory /var/www/>
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
</Directory>
JkMount /hudson* hudson

jk.conf

JkWorkersFile /etc/apache2/worker.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel info
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"

worker.properties:

worker.list = hudson
worker.hudson.type=ajp13
worker.hudson.host=localhost
worker.hudson.port=8102
worker.hudson.lbfactor=50
worker.hudson.socket_keepalive=1
worker.hudson.socket_timeout=300


003-svn

Die folgende Konfiguration ist für den Betrieb von Subversion mittels WebDAV notwendig.

Die Funktionsweise der Authentifizierung befindet sich im Kommentar der Konfiguration, sowie im Abschnitt #Subversion

######################
# Authentifizierung gegen die SQLite3 Datenbank von Trac.
# Man muss sich anmelden, wenn NICHT HTTP GET, PROPFIND, OPTIONS oder REPORT macht
# sondern mit HTTP POST Änderungen übertragen möchte. Dann greift LimitExcept und macht
# eine SQL Abfrage mit Benutzername %s und vergleicht das dann zurück gegebene Passwort mit dem
# eingegebenen. Zusätzlich muss sich der Benutzer in der Gruppe "SVN Write Access" befinden!!!
#
################
DBDriver sqlite3
DBDParams "/var/trac/dotplot/db/trac.db"
#################
 
<Location /dotplot/svn>
   DAV             svn
   SVNPath         /var/svn/dotplot

   AuthType          Basic
   AuthName          "Dotplot Subversion"
   AuthBasicProvider dbd

   ErrorDocument 401 /dotplot/auth_failed.html

   <LimitExcept GET PROPFIND OPTIONS REPORT>
     AuthDBDUserPWQuery "SELECT A.value AS password FROM session_attribute AS A WHERE sid=%s AND authenticated=1 AND name='password' AND \
                         (SELECT value FROM session_attribute WHERE authenticated=1 AND sid=A.sid AND name='groups') LIKE '%%SVN Write Access%%'"
     Require valid-user
  </LimitExcept>

</Location>



004-trac

#Trac wird über das [WSGI] Apache2 Modul betrieben. Dies beschleunigt Trac immens und die Konfiguration ist denkbar einfach:

WSGIScriptAlias /dotplot/trac /var/trac/dotplot/trac.wsgi
<Location /dotplot/trac>
 WSGIApplicationGroup %{GLOBAL}
</Location>

/var/trac/dotplot/trac.wsgi:

import os

os.environ['TRAC_ENV'] = '/var/trac/dotplot'
os.environ['PYTHON_EGG_CACHE'] = '/var/trac/dotplot/.egg-cache'

import trac.web.main
application = trac.web.main.dispatch_request

MySQL

Einstellungen für den Zugriff der Slaves auf den Master. Hudson bietet die Möglichkeit einen Selenium Grid Server laufen zu lassen. Dazu wird auf allen Hudson Slaves ein Selenium Server gestartet.

Da diese Selenium Tests auch die Installation von eStudy durchführen, muss die Möglichkeit bestehen, von den Slaves aus auf dem MySQL Server Datenbankoperationen durchzuführen.

Dazu werden in der MySQL Konfiguration folgende Zugriffsrechte gesetzt:

INSERT INTO `db`
   (`Host`, `Db`, `User`, `Select_priv`, `Insert_priv`, `Update_priv`, `Delete_priv`, `Create_priv`, `Drop_priv`, `Grant_priv`,
   `References_priv`, `Index_priv`, `Alter_priv`, `Create_tmp_table_priv`, `Lock_tables_priv`, `Create_view_priv`, `Show_view_priv`, 
   `Create_routine_priv`, `Alter_routine_priv`, `Execute_priv`)
VALUES
   ('10.48.0.12', 'estudy', 'estudy', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y'),
   ('212.201.7.21', 'estudy', 'estudy', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y', 'Y');

Firewall konfiguration für den Zugriff auf den MySQL Dienst. Alle außer dem SUNX4600 und Saturn werden geblockt:

iptables -A INPUT -i eth0 -s 10.48.0.12 -p tcp --destination-port 3306 -j ACCEPT
iptables -A INPUT -i eth0 -s 212.201.7.21  -p tcp --destination-port 3306 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j DROP


Diese Regeln werden beim Systemstart über den Networkmanager von Debian neu geladen. /etc/network/if-up.d/iptables:

#!/bin/sh
iptables-restore < /etc/firewall.conf

Trac

Trac wurde als Projektmanagement Platform gewählt, da dies aus einer leicht zu bedienende Weboberfläche besteht, ein Subversion Code Browser und ein Wiki besitzt, um Dokumentation und Informationen über das Projekt anbieten zu können.

Zusätzlich war es das Ziel, die Benutzerverwaltung in Trac zu integrieren, damit sich der Benutzer, in unserem Fall die aktuellen und zukünftigen Entwickler an einer zentralen Stelle registrieren können und ihre dort hinterlegten Anmeldedaten für Trac, Subversion und Hudson verwenden können.


Für die Installation wurde ein Debian Packet erstellt, so dass sich Trac in Zukunft sehr einfach über das Packetverwaltungs-Management von Debian updaten lässt. Grundlage für das Debian Packet war die zu diesem Zeitpunkt aktuelle Version 0.11 von Trac.

Es wurde der Installationspfad /var/trac/dotplot gewält, da in Zukunft vielleicht noch andere Projekte auf dem Server ihr Zuhause finden und dann eine weitere Trac Instanz erstellt werden kann, denn der Standardpfad lautet /var/trac. Diese Einschränkung wurde so direkt aufgehoben.

Eine weitere Anpassung an das System war, dass ein kleines Plugin für Trac entwicklelt wurde, welches die Gruppenverwaltung ermöglichen soll. Trac bietet zwar eine Gruppenverwaltung an, jedoch ist diese Dateibasiert und es wird nicht die bestehende Datenbank hierfür genutzt. So haben zukünftige Administratoren nun die Möglichkeit, Benutzer und Gruppen sehr einfach über das Webinterface von Trac zu verwalten.

Es lassen sich neue Gruppen in Trac anlegen, indem man im Trac Administrationsmenü unter Accounts->Group Management geht.

SVNGroupManagementScreen1.png


Bestehende Gruppen lassen sich bearbeiten - indem Benutzer entfernt werden können oder neue Benutzer hinzugefügt werden können.

SVNGroupManagementScreen3.png


Bei der Realisierung des Plugins wurde darauf geachtet, dass die Datenbankstruktur von Trac nicht verändert wird, so dass durch ein Update von Trac, die Daten nicht gelöscht werden und das Plugin inkompatibel zu der neuen Version wird.

Darum wurden die Informationen der Gruppenzugehörigkeit nicht in einer eigenen Tabelle oder Spalte der Benutzerinformationen gespeichert, sondern eine Spalte für Attribute herangezogen, die für Informationen rund um den Benutzer verwendet werden kann: session_attribute.

Der Python Quellcode des Plugins für die Gruppenverwaltung in Trac kann hier heruntergeladen werden: GroupAdminPlugin.tar

Subversion

Die Subversion Installation wurde aus dem Debian Repository installiert.

Die Konfigurationsdaten, sowie das Repository selbst befindet sich, wie in jeder Debianumgebung unter /var/svn.

Der Zugriff auf das Repository geschieht mittels Apache2. #Apache2

Die Konfiguration erlaubt es anonymen Lesezugriff durchzuführen. Sobald jedoch ein Benutzer eine Änderung in das Repository einchecken möchte, muss er sich einloggen. Dies geschieht über die Direktive <LimitExcept GET PROPFIND OPTIONS REPORT> Diese Direktive bedeutet, alles außer den HTML Operationen GET, PROFIND,OPTIONS,REPORT muss sich authentifizieren.

Die Authentifizerung findet dann mittels Apache2 Authentifizierungsmodul DBD statt. Dieses Modul ist ein generisches Datenbank-Modul, das sich mit MySQL, PostgreSQL, Oracle oder eben auch SQLite betreiben lässt.

Apache führt nun also jedesmal, wenn sich ein Benutzer anmeldet eine Datenbankabfrage in der SQLite Datenbank von Trac durch und ermittelt so, ob der Benutzer die benötigten Rechte hat.

AuthDBDUserPWQuery "SELECT A.value AS password FROM session_attribute AS A WHERE sid=%s AND authenticated=1 AND name='password' AND \
                   (SELECT value FROM session_attribute WHERE authenticated=1 AND sid=A.sid AND name='groups') LIKE '%%SVN Write Access%%'"
Require valid-user

Dieser Code führt die Datenbankabfrage durch und sagt, es muss ein gültiger Benutzer bestehen, damit er Zugriff erhält. Die Unterabfrage war nötig, da der Platzhalter %s nur einmal verwendet werden kann, aber für die Abfrage nach der Gruppenzugehörigkeit der Benutzername ein zweites mal benötigt wird. Darum wird die erste Abfrage in A gespeichert und kann so in der Unterabfrage benutzt werden (A.sid).

Apache2 überprüft, ob Benutzername und Passwort stimmen und ob der Benutzer sich auch in der Gruppe für Subversion Schreibzugriff befindet.

Hudson

Backup

Das Backup aller wichtigen Daten findet täglich mittels rsync statt.

Der Vorteil bei rsync liegt darin, dass nur die Änderungen übertragen werden, somit entsteht nicht so viel Traffic und der benötigte Speicherplatz auf dem Backuplaufwerk weitet sich auch nicht aus.

Gespeichert wird auf das vom ITS zur Verfügung gestellte Laufwerk nas-02.its.fh-giessen.de:/ci-backup.

Das Backup umfasst folgende Daten:

  • Alle Konfigurationsdaten: /etc
  • Die Benutzerverzeichnisse: /home
  • Alle Trac Installationen: /var/trac
  • Alle Subversion Installationen: /var/svn
  • Hudson mit allen Daten: /usr/share/hudson


eMail Zustellung und Versand

Der eMail Dienst auf diesem Server kann nur lokal und von bestimmten anderen Servern genutzt werden, z.B. vom Mail Gateway der FH Giessen-Friedberg. Diese Mailserver der FH Giessen-Friedberg können auch eMails, die für den Continuous Integratrion Server bestimmt sind, ihm diese zustellen. Zur Zeit, werden alle eMails die dem Server zugestellt werden, an den Administrator weitergeleitet.


CVS to Subversion Migration

Eine Hauptaufgabe des Teams bestand darin, das Quellcode Verwaltungssystem umzustellen.

Bislang wurde der Dotplot Code im CVS Repository auf Sourceforge verwaltet. Ziel war es, den Code in das häufig genutzte Subversion zu mirgrieren.

Hauptproblem bestand darin, dass die Struktur des Repositories gewahrt werden sollte. Es waren mit der Zeit eine vielzahl an Branches und Tags entstanden, die alle unterschiedliche Entwicklungsstände von Dotplot enthielten.

Subversion bietet jedoch für die Migration ein Python Script, dass die CVS Verzeichnisstruktur nach der SVN Strukur konvertiert: cvs2svn

Nach dem ersten Test, stellten wir jedoch fest, dass leider die Kommentare der Commits auf Deutsch und mit sehr vielen Sonderzeichen waren und diese in dem neuen SVN Repository nicht richtig dargestellt wurden.

Aus diesem Grund wurde jede Datei, abhängig von der alten Codierung nach UTF-8 konvertiert. So konnten wenigstens die Kommentare der Quellcode Dateien mit allen Sonderzeichen dargestellt werden.

Da sich aber Binärdateien nicht konvertieren lassen, bleiben die Kommentare der Binärdateien im neuen SVN defekt, falls sie Sonderzeichen enthalten.


#!/bin/bash
 
cvsOutputPath="/tmp/dotplot/cvs"
svnOutputPath="/var/trac/dotplot/svn"

rsync -av rsync://dotplot.cvs.sourceforge.net/cvsroot/dotplot/* $cvsOutputPath

for file in `find $cvsOutputPath -type f`; do
	case $(file "$file") in
        	*ISO-8859* )
			echo "konvertiere $file von ISO-8859 nach UTF8";
			iconv --from-code=ISO-8859-15 --to-code=UTF-8 "$file" -o "$file".tmp;
			mv "$file".tmp "$file";
			;;
		*ASCII* )
			echo "konvertiere $file von ASCII nach UTF8";
	                iconv --from-code=ISO-8859-15 --to-code=UTF-8 "$file" -o "$file".tmp
                        mv "$file".tmp "$file"
			;;
		*UTF* )
                        echo "$file ist bereits in UTF8";
	                ;;
		* )
			echo "$file wird nicht konvertiert";
			file "$file";
	                ;;
	esac
done

rm "$cvsOutputPath/org.dotplot.plugin/html/Attic/toc.html,v"
cvs2svn -s $svnOutputPath $cvsOutputPath


Benutzerverwaltung

Wie bemerkt, befindet sich die globale Benutzerverwaltung für das Dotplot Projekt und auf für Hudson im Trac auf dem Continuous Integration Server. Link

Die Administratoren von Trac, haben dort die Möglichkeit die Benutzer- und Gruppenverwaltung durchzuführen.

Registierung

Die Registrierung befindet sich im Trac unter folgendem Link: http://ci.mni.fh-giessen.de/dotplot/trac/register

Dort müssen eine korrekte eMail Adresse, ein Benutzernamen der aus Vornamen.Nachnamen bestehen sollte angegeben werden.

Der Administrator erhält einen Bericht über die Benutzerregistrierung und kann Sie nun freischalten, indem er Sie in Gruppen aufnimmt.

TracRegister.png

Rechteverwaltung und Gruppen

Die Rechteverwaltung ist durch Gruppen realisiert. Jede Gruppe steht für ein bestimmtes Recht. z.B. existiert die Gruppe SVN Write Access.

Nach der Gruppenzugehörigkeit wird gefragt, wenn ein Benutzer eine Quellcode-Änderung in das System einchecken möchte. In diesem Moment befragt der Apache2 Server die Datenbank nach genau dieser Gruppe und wenn der Benutzer dieser Gruppe angehört, wird ihm der Zugriff erlaubt, ansonsten wird ihm eine Fehlerseite angezeigt, mit Informationen wie er sich registrieren und Zugriff erlangen kann.


Bis jetzt bestehen folgende Gruppen im System:

  • SVN Write Access
  • Hudson Admin
  • Superuser

Die Gruppe Hudson Admin ist für die Rechteverwaltung in Hudson. Wenn ein Benutzer dieser Gruppe angehört, dann hat er die Möglicheit in Hudson Änderungen vorzunehmen.

Die Gruppe Superuser ist für die das Administratorrecht. In Hudson wird es verwendet, um gravierende Änderungen am System vorzunehmen.

Da die Gruppenverwaltung datenbankbasiert ist, lassen sich in Zukunft noch andere Systeme an die Datenbank anbinden und durch hinzufügen weiterer Gruppen, die Rechte verwalten.

Hudson

Continuous Integration

Continuous_Integration


Ant Build Skripte

Die Plugins in den unten stehenden Rubriken sind Hudson Plugins. Diese Plugins sind hauptsächlich (nicht alle) für sogenannte Postbuildaktionen Verantwortlich. Plugins die Postbuildaktionen ausführen sind in der Lage die XML-Ergebnissberichte von den jeweiligen Tools zu Parsen und grafisch darzustellen. Diese Plugins können entweder direkt aus der Hudson Umgebung installiert werden oder auch alternativ von der Hudson Homepage herruntergeladen und installiert werden.

Bevor man die Ergebnisberichte parsen und darstellen kann müssen diese erstellt werden. Diese Arbeit übernehmen für uns die verschiedenen Tools. Jedes Tool berechnet eine andere Metrik des Codes. Aus diesem Grund kommt in unserem Projekt eine Vielzahl von Tool zum Einsatz. Die Liste der von uns verwendeten Tools umfasst PMD, FindBugs, Checkstyle usw. Der Zweck den die jeweiligen Tools erfüllen ist in den unterstehenden Rubriken beschrieben.

Um mit einem Tool sinnvoll und automatisiert zu arbeiten ist ein Script notwendig welches das Tool startet. Um solch ein Script für das Projekt zu erstellen kam das Ant-Build Werkzeug zum Einsatz. Dieses Werkzeug ist hervorragend geeignet um Scripte zur automatischen Erstellung von Javaprogrammen zu implementieren.

Alle Tools die wir verwendet haben unterstützen die Arbeit mit dem Ant-Werkzeug. Hier sind für die Verwendung der Jeweiligen Tools unterschiedliche Routinen zu Implementieren.


Gemeinsamkeiten der meist verwendeten Tools sind:

- Pfad zur ausführbaren Datei muss in den include Pfad mit aufgenommen werden.

- Der Pfad zu den Quellen bzw. Java-Bytecode Dateien muss dem entsprechenden Werkzeug bekannt sein.

- Ein Target welches die Ausführung des Tests startet muss implementiert werden.

- Festlegen des Ausgabeformates und Ausgabeverzeichnis.


Die genaue Implementierung unterscheidet sich Teilweise von Tool zu Tool sehr. Hinweise zur Implementierung finden Sie auf den entsprechenden Homepages der verwendeten Werkzeuge.

Im Rahmen der Umstellung des DotPlot Projekt auf die neue CI-Umgebung haben wir für die Jeweiligen Tools Startscripte erstellt. Die Genau Implementierung wie sie derzeit im Projekt verwendet wird können sie hier einsehen.

Weitere Informationen zu Ant-Werkzeug finden Sie hier.

Plugins und deren Metriken

JUnit

Testgetriebene Entwicklung mit JUnit & FIT


Hudson ist in der Lage Testergebnisse welche das JUnit-Framework liefert zu Parsen und darzustellen. Damit der neue CI-Server in der Lage ist JUnit Ergebnisse darzustellen mussten die vorhandenen Ant-Buildscripte an die neue Umgebung angepasst werden.

Die Publikation der Ergebnisse wird in den Projekteinstellungen aktiviert. Als erstes wird unter der Rubrik „Build Verfahren“ das Target eingetragen welches beim Buildprozess die JUnit-Tests Compiliert:

Ant build junit.png



Damit die JUnit-Tests Ergebnisse liefern muss beim JUnit-Target die Report Option aktiviert sein. Anschließend muss man dem Hudson sagen dass er die Testergebnisse veröffentlichen soll. Diese Einstellung ist unter der Rubrik „Post-Build Aktionen“ zu finden. Hier muss der Pfad angeben werden an dem sich die Testergebnisse befinden:

Post build action junit.png



Sind diese Einstellungen getan führt Hudson die JUnit-Tests aus und veröffentlicht die Testergebnisse. Die Metricken können nach dem Buildprozess unter der Rubrik „Job“ Testergebnis eingesehen werden:

JUnit Testergebnisse von DotPlot Projekt. Junit testergebnisse.png

Aktuelle Testergebnisse: [Testergebnisse]

PMD

Im Rahmen der Umstellung des Dotplot Projektes auf die neue CI-Umgebung würden die Quellen des bestehenden DotPlot Projektes mit dem PMD-Tool untersucht. Das PMD Tool ist ein Tool zum Scannen des bestehenden Javacode nach potentiellen Problemen. Unter potentielle Probleme ist hier drunter zu verstehen: - Mögliche Bugs: leere try,catch,finally oder switch Statements - Toter Code: unbenutzte locale Variablen, Parameter oder private Methoden - nicht optimaler Code: unnüzliche/ verschwenderische nutzung von String/Strinbuffer - Überkomplizierte Ausdrücke: Unnötige If-Anweisungen. - Duplizierter Code: Copy und Paste getriebene Anwendungsentwicklung welche zu Kopie und Paste Fehlern und Bugs führt.

Zur Darstellung der PMD Ergebnisse mithilfe von Hudson ist ein Plugin notwendig welches in der Lage ist PMD-Ergebnisse zu Parsen. Das Plugin kann direkt aus der Hudson Umgebung installiert werden.

Mehr informationen wie Download, Installation und Verwendung mit Ant finden Sie auf der PMD Homepage.

Die Vorschau welche das PMD-Tool liefert ist hier unten abgebildet.

Pmd Trend.png

Die vollständigen Metriken die das PMD-Tool ermittelt hat können hier eingesehen werden.

Findbugs

FindBugs FindBugs durchsucht Java-Bytecode nach möglichen Bugs. Beim durchsuchen sucht FindBugs nach ausdrücken die oft Fehler ergeben. „Bug-Patterns“ ergeben sich aus einer Vielzahl von gründen. Ursachen dafür können zum Beispiel das verwenden komplizierter Ausdrücke oder auch das Missverstehen von API-Funktionen sein.

Zur Überprüfung des ankommenden Java Bytestromes nach Vorkommen von „bug patterns“ verwendet FindBugs eine Statische Analyse. Statisch bedeutet in diesem Zusammenhang dass die Überprüfung nach Bugs anhand des Bytecodes erfolgt, eine Ausführung des Programmes ist nicht notwendig. Zur Überprüfung sind die Quellcode Dateien eines Programmes nicht notwendig, es reicht schon ein Compilierte Version einer Anwendung.

Weitere informationen finden Sie unter: FindBug

Im Rahmen der Umstellung auf die neue Umgebung wurde FindBugs verwendet um den Code nach Bugs zu Überprüfen. Damit FindBugs die Überprüfung des Bytestromes nach dem Copiliervorgang korrekt duchführen kann wurde der Ant-Script für den automatischen Buildprozess angepasst. Anschließend musste der Hudson-CI mit dem FindBugs-Plugin erweitert werden damit Hudson in der lage ist die Testergebnisse des FindBug-Tools zu Parsen und grafisch darzustellen.


Die Vorschau die sich auf der Hudson DotPlot-Projektseite befindet ist unten abgebildet.


Find bugs trend.png

Die Vollstendigen Metriken die das FindBugs-Tool ermittelt hat können hier eingesehen werden.

Checkstyle

Checkstyle ist ein Entwicklungstool welches dem Programmierer hilft bei der Programmierung bestimmte Codierrichtlinien einzuhalten. Checkstyle überprüft automatisch den Java-Code nach Verletzungen von Coderichtlinien. Dieses Werkzeug ist sehr anpassungsfähig, es kann beinahe auf alle denkbaren Coderichtlinien konfiguriert werden. Checkstyle ist in der Lage viel Aspekte eines Codes zu überprüfen. Früher wurde es verwendet um Codelayouts zu überprüfen, seit der Änderung der internen Architektur seit der Version 3 wurden mehrere „Checks“ für andere Zwecke eingeführt. In der aktuellen Version ist Checkstyle in der Lage den Code nach Klassendesign Problemen, nach doppeltem Code oder auch nach „Bug-Patterns“ zu überprüfen. Eine Menge an Standardcheck können auf des Checkstyle Homepage eingesehen werden. In Fällen in denen Individuelle Richtlinien verfolgt werden kann man Checkstyle mit selbst geschriebenen Richtlinien erweitern. Individuelle „Checks“ werden als Module implementiert, diese Module werden Anschließend von Checkstyle verwendet.

Weitere Informationen zu Checkstyle finden Sie auf der Checkstyle Homepage.

Im Rahmen der Umstellung auf die neue CI-Umgebung wurden mit dem Portierten DotPlot Projekt Checkstyle-Tests durchgeführt. Für die automatische Testausführung nach dem Buildprozess würde das Bestehende Ant-Buildscript mit den notwendigen Checkstyle Targets ergänzt. Bei der Überprüfung der Codes wurde die Sun Code Conventions eingesetzt. Dies ist auch der Hauptgrund dafür dass in dem Dotplot Projekt soviele Warnungen gezählt wurden.


Die Vorschau die sich auf der Hudson DotPlot-Projektseite befindet ist unten abgebildet.


Checkstyle trend.png


Die vollstendigen Metriken die das Checkstyle-Tool ermittelt hat können hier eingesehen werden.

Crap

Crap4j ist ein Open-Source Tool um Java-Code nach C.R.A.P. zu untersuchen. C.R.A.P steht für Change Risk Analysis and Predictions. Crap untersucht den Code auf seine Komplexität und führt ein Risokoanalyse bzw. Prognose im Falle von Änderungen durch. Wie Crap4j den C.R.A.P. Faktor berechnet können Sie aus dem FAQ auf der Crap4j-Homepage entnehmen. Die Interpretation der Werte erfolgt nach der folgenden Übersicht.


Interpretation.png


Das DotPlot Projekt wurde im Rahmen der Umstellung auf die neue CI-Umgebung mit dem Crap4j Tool untersucht. Für die Darsellung der Crap Testergebnisse im Hudson ist ein Plugin norwendig. Dieses Plugin kann auf der Hudson Homepage heruntergeladen werden. Die Vorschau die Sich auf der DotPlot-Projektseite befindet ist hier unten abgebildet.

Crap trend.png

Die vollständigen Metriken die mit dem Crap4j-Tool ermittelt wurden können hier einsehen werden.

Task Scanner

Das Task Scanner Plugin durchsucht das Workspace nach offenen Aufgaben wie FIXME, BUG, TODO oder @deprecated. Das Plugin erlaubt es Dateien zu spezifizieren welche nach Abschluss eines Buildprozesses durchsucht werden sollen. Unter anderem unterstützt der Task Scanner drei Priorität Stufen(high = FIXME, normal = ToDo, low = @deprecated ). Nach dem Scanvorgang erstellt das Plugin ausfürliche Testergebnisse mit grafischen Übersichten im HTML-Format. Das Plugin kann direkt über den Hudson installiert werden und in der Projektkonfiguration einfach konfiguriert werden.

Das Task-Scanner Plugin liefert folgende Vorschau nach dem Scannen der DotPlot-Sourcen.

Task scanner trend.png

Die vollständigen Ergebnisse können hier eingesehen werden.

Simian

Simian ist ein Tool zum untersuchen von Softwareprojekten nach doppelt vorkommenden Code.

- Simian unterstützt über 10 Sprachen.

- Weiterhin unterstützt das Tool Berichterstattung in XML oder HTML Format.

- Unterstützt das Aufsuchen doppelter Codezeilen.

- Ant Unterstützung.

Weitere Informationen finde Sie hier.

JavaNCSS

JavaNCSS ist ein einfaches Kommandozeilenwerkzeug dass eingesetzt wird um zum Beispiel den Umfang des eigenen Projektes zu erfassen oder auf den Projektfortschritt zu ermitteln. Die Metriken werden global für jede Klasse und/oder für jede Funktion gesammelt.

Funktionen und Metriken von JavaNCSS:

- Metricken können auf globaler, Classen, oder Funktion-Ebene erfasst werden.

- Nicht Auskommentierte Anweisungen.

- Cyclomatic Complexity Number (Metrik).

- Packete, Klassen, Funktionen werden gezählt.

- Usw.


Ausführliche Informationen erhalten sie auf der JavaNCSS Homepage.

Eine Beispielausgabe die Das Tool Liefert kann hier eingesehen werden. Hier wurde Die Sun JDK 1.1.5 mit dem JavaNCSS-Tool untersucht.

Cobertura

Testgetrieben Anwendungsentwicklung in der Programmierung war in den Vergangenen 10 Jahren die wichtigste Innovation, obwohl die „Test-First“-Programmierung und Unit-Tests neu sind. Jedoch ist die Testgetriebene Anwendungsentwicklung nur so gut wie die Tests. Tests verbessern die Codequalität aber nur in den Bereichen des Codes welche getestet sind, bzw. mit parallel entwickelten Tests abgedeckt sind. Man benötigt ein Tool dass ein Programm scannt nach Bereichen die nicht mit Tests abgedeckt sind. Coberatura ist solch ein freies Java-Tool. Coberatura berechnet den Prozentualen Anteil an Code der von Test abgedeckt ist und das Tool ist auch in der Lage Code der nicht mit Tests abgedeckt ist zu Identifizieren.


Coberatura verfügt über folgende Merkmale:

- Ausführung mit Ant oder mit Konsole

- Verarbeitung von Java-Bytecode nach der Compilierung

- Ausgabe von Ergebnissen in HTML oder XML Format. (Zum darstellen der Ergebnisse im XML-Format durch Hudson ist ein Plugin notwendig. Das Plugin ist auf der Hudson Projektpage erhältlich und ist in der Lage die Berichte zu Parsen und in der Hundson-CI Umgebung grafisch darzustellen)

- Zeigt Prozentualen Anteil an abgedeckten Zeilen und Branches für jede Klasse, Packet und für das gesamte Projekt.

- Zeigt die cyclomatic code complexity für jede Klasse, einen gemittelten Cyclomatic code complexity für jedes Packet und für das gesamte Projekt.

Weitere Informationen Über da Coberatura-Tool finden Sie aus der Couberatura-Homepage.

Coberatura angewandt auf das Dotplot-Projekt lieferte folgende Trendansicht. Die aktuelle Übersicht kann auf der DotPlot-Projektseite eingesehen werden.


CoberaturaTrend.png


Die vollständigen Testergebnisse können hier eingesehen werden.

EMMA

Bis vor kurzer Zeit wurde die Welt der Javaentwickler von einer absurden Deskripanz. Javaentwickler hatten excelente IDEs, freie Comiler, freie Test-Frameworks jedoch hatten Sie keine kostengünstigen Code-Coverage Tools. Aus diesem Grunde wurde EMMA-Codecoverage Tool entwickelt.

EMMA ist ein Open-Source-Tool zur Messung und zur Berichterstattung von Java-Code-Coverage. EMMA unterscheidet sich von anderen Tool in ihrer einzigartigen kombination von Merkmalen: Es bietet Unterstützung für große Software-Entwicklungsunternehmen, während die Einzelnen Entwickler schnell und iterativ ihre Arbeit fortsetzen können. Jeder Entwickler eines Teams kann Code coverage Trends frei und schnell erhalten.

Merkmale von EMMA-Codecoverage:

- Emma ist in der Lage Klassen zu verarbeiten sowohl offline (bevor sie geladen werden) als auch online (nach dem Laden mit dem Classloadee)

- Unterstützt: Klassen, Methoden, Codezeilen, und einfache Anweisungsblöcke

- Ausgabe als HTML, XML


Weitere Informationen zu EMMA-Codecoverage erhalten Sie auf der EMMA-Homepage.

Im Rahmen der Umstellung des DotPlot-Projektes auf die neue CI-Umgebung wurden EMMA-Codecoverage Tests durchgeführt. Der Trend ist hier unten abgebildet.


Emma trend.png


Die vollständigen und aktuellen Testergebnisse können hier eingesehen werden.

Testability Explorer

Der Testability-Analyzer überprüft den compilierten Java-Bytestrom auf seine Testbarkeit. Dabei werden von der geprüften Bibliothek oder Projekt die Metriken individuell für jede Klasse berechnet. Bei der Überprüfung werden die Klassen in drei Kategorien eingeordnet: „exzellent“, „gut“ „Überarbeitung notwendig“.

Die Metriken sind Berechnungen der Fertigkeiten des Entwicklungsteams in der Kategorie Testbarkeit ihrer Software. Die Testergebnisse sagen nicht aus ob ein Projekt besser ist als ein Vergleichbares, sie sagen auch nichts über die Bedienbarkeit einer Bibliothek aus. Die Testergebnisse sagen aus wie engagiert ein Team war testbare Software zu entwickeln.

Das Dotplot-Projekt wurde auch mit diesem Tool überprüft, die Testergebnisse können sie hier einsehen.

Weitere informationen über den Testability Explorer finden sie hier.

CI Game

Das Continuous Integration Game Plugin ist ein Spiel bei dem Entwickler Punkte sammeln können, indem sie den Buildprozess verbessern. Die Idee die dahinter steckt ist die Anzahl der fehlgeschlagenen Builds zu reduzieren. Um zu gewinnen muss der Entwickler Code Commiten und den bestehenden Code mit weiteren Unit-Tests ergänzen.

Jeder Entwickler (derjenige der Comittet) der für einen Build Verantwortlich ist bekommt für diesen Build Punkte. Die Punkte werden nach Regeln vergeben. Das Spiel ist mit folgenden Basisregeln konfiguriert:

- - 10 Punkte für einen Felgeschlagenen Build

- 0 Punkte für einen fehlgeschlagenen Build der bereits fehlerhaft war

- + 1 Punkt für erfolgreiches erstellen

- - 1 Punkt für jeden neu fehlgeschlagenen Test

- + 1 Punkt für jeden neuen erfolgreichen Test

Darüberhinaus verfügt das Spiel auch über regeln die von anderen Hudson-Plugins wie zum Beispiel PMD, FindBugs oder Checkstyle usw.. Ein genaue Auflistung des Tools und die Punktevergabe bei Regeln die von diesen Tools abhängig sind finden sie auf der CI-Game Pluginseite.

Das Spiel bietet auch die Möglichkeit die Regeln anzupassen und neue zu definieren. Jeder Programmierer der am Spiel teilnimmt kann sich durch seine Verbesserungen für das Leader Board Qualifizieren.


Leader board.png


Den aktuellen Stand können Sie hier einsehen.

Weitere Informationen über das Spiel und Hinweise zur Installation und Konfiguration finden auf der CI-Game Pluginseite.

Plugin für Authentifizierung

Hudson bietet eine Integrierte Benutzerverwaltung an und aber auch die Möglichkeit, durch so genannante Extension Points, ein Plugin zu entwickeln, dass eine eigene Benutzerveraltung ermöglicht.

Das Ziel war nun, eine zentrale Benutzerverwaltung zu schaffen, an der sich der Benutzer registrieren und den gewählten Benutzernamen sowie Passwort an mehreren Stellen verwenden kann.

Da das Projektmanagement und Code Browsing, sowie Ticketverwaltung Trac die ideale Plattform für dieses Problem ist, haben wir uns dafür entschieden, die Benutzerverwaltung mit Trac vorzunehmen.

Vorteile sind:

  • Zentrale Datenbank zur Speicherung der Daten
  • Einfache Benutzerverwaltung
  • Gruppenverwaltung


Idee war nun, die schon vorhandene Benutzerdatenbank von Trac zu verwenden und die Authentifizierung anhand der Informationen in der Benutzerverwaltungs-Datenbank von Trac vorzunehmen.

Mit dem Plugin ist es nun möglich, sich gegen eine in der Hudson angegebene SQLite Datenbank zu authentifizieren und zusätzlich Informationen zur Gruppenzugehörigkeit abzufragen.

So lassen sich sehr fein getrennt Rechte in Trac, Subversion und auch Hudson vergeben, die der Benutzer hat und der Gedanke, dass sich der Benutzer an einer zentralen Stelle registieren kann und den gewählten Benutzernamen sowie Passwort an vielen Stellen benutzen kann, wurde durch dieses Plugin für Hudson erreicht.

TracAuthScreen1.png


Die Quellen dieses Plugins können unter folgendem Link heruntergeladen werden: http://ci.mni.fh-giessen.de/data/TracAuth.tar

Plugin für eMail Lookup

Die vorliegende Problematik ist, dass Hudson die Möglichkeit bietet, gezielt eMails an denjenigen zu versenden, der den Build fehlschlagen ließ, jedoch die eMail Adresse Hudson nicht bekannt ist.

Über das Source Code Management Subversion ist nur der Benutzername ersichtlicht, der den Code in das System übertragen hat.

Die eMail Adresse ist nur in der Benutzerverwaltungs-Datanbank von Trac vorhanden, der Projektverwaltungsplatform und Code Browser. Dort haben sich die Benutzer mit Benutzernamen und eMail registriert. In dem vorliegenden Fall, war es sogar so, dass unterschiedliche Projekte, nämlich eStudy und Dotplot, die Continuous Integration Engine Hudson nutzen - und die Projekte unterschiedliche Datenbanken für die Benutzerverwaltung verwenden.

Aus diesem Grund wurde ein Plugin für Hudson entwickelt, das die Möglichkeit bietet, eine beliebige Anzahl an Datenbanken anzugeben, die zu dem vorhandenen Benutzernamen die eMail Adresse enthalten und Hudson so die eMail Adresse ermitteln kann.

TracEmailLookupScreen1.png


Es lassen sich in der Konfiguration von Hudson nun beliebig viele SQLite Datenbanken von Trac angeben. Das Plugin versucht mit einer SQL Query anhand des Benutzernamens nun die eMail Adresse des Benutzers zu ermitteln, um gezielt eMails versenden zu können. (Siehe unterster Punkt in folgendem Bild.)

TracEmailLookupScreen2.png


Die Quellen dieses Plugins können unter folgendem Link heruntergeladen werden: http://ci.mni.fh-giessen.de/data/TracEmailLookup.tar

Plugin für Extreme Feedback

Das Plugin für Extreme Feedback gibt allgemeine Statusinformationen über den aktuellen Zustand der Projekte aus. Im Rahmen dieses Projekts wurde das Plugin DotFeed für Hudson implementiert, das die aktuellen Statusinformationen der Projekte als RSS Feed aufbereitet.

Das DotFeed Plugin steht nach Installation in Hudson unter der URL http://ci.mni.fh-giessen.de/hudson/plugin/DotFeed/rss zur Verfügung. Die Quellen sowie ein Build für Hudson des Projekts befinden sich in DotFeed.tar

Dotfeed.jpg

Weitere Informationen zu Metriken und Statusinformationen sind im Abschnitt Jobs erläutert.

Für weitere Informationen zum Projekt CI Visualisierung siehe CIVisualisierung.

Projekte in Hudson

Jobs

Ein Job beschreibt ein Software Projekt, das in Hudson verwaltet wird.

Ein Job besteht aus:

  • Subversion-Revsion des Projektes
  • Zeitliche Einstellungen, wenn Hudson Builds ausführen soll
  • Buildscripte (Ant, Maven, shell script, batch file, usw.)

Auf ein Projekt werden verschiedene Metriken angewandt und je nach Einstellung das Ergebnis eines Jobs aufbereitet wiedergegeben. Generell kann man sich einen Job als Abarbeitung verschiedener Aufgaben betreffend eines Projektes verstehen.

  • Zuerst wird das Build-Script ausgeführt
  • Danach folgt die Auswertung je nach Konfiguration
    • Hier sind verschiedenste Tools denkbar. Hudson ist hier sehr offen und erweiterbar.

HudsonJobs.png

Hudson interpretiert die wichtigsten Metriken eines Jobs als allgemeine Statusinformationen, d.h. unabhängig vom verwendeten Compiler, der Programmiersprache (PHP, Java, C++, etc) oder des Test-Frameworks (PHPUnit, JUnit, etc). Die detaillierten Informationen, z.B. der Unit-Tests, bleiben neben diesen allgemeinen Statusinformationen natürlich erhalten und werden vom jeweiligen Hudson Modul aufbereitet.

Die wichtigsten allgemeinen Statusinformationen sind:

  • Build Nr.: Die fortlaufende ID des Builds
  • Build Health: Diser Wert zeigt an, ob beim Kompilieren Fehler oder Warnungen aufgetreten sind.
  • Build Result: Gibt wie Build Health das Ergebnis des Build-Vorgangs an, allerdings als Text und mit eventuellen zusätzlichen Statusinformationen. Build Result liefert eines der folgenden Ergebnisse:
    • ABORTED: Der Job wurde absichtlich per Hand unterbrochen wurde
    • UNSTABLE: Der Kompiliervorgang wurde vollständig durchlaufen, aber es beim Kompilieren kam es zu Fehlern bzw. Warnungen
    • FAILURE: Der Kompiliervorgang wurde wegen einem kritischen Fehler im Quellcode abgebrochen, oder der Kompiliervorgang selbst hat nicht geklappt (z.B. wegen einem Fehler in der Konfiguration)
    • SUCCESS: Der Kompiliervorgang wurde erfolgreich abgeschlossen
  • Unit Test Health: Dieser Wert gibt an, wie viel Prozent der Unit Tests erfolgreich absolviert wurden (0..100, oder -1 falls kein Test definiert)
  • Build Time: Datum und Uhrzeit des Kompiliervorgangs
  • Build Duration: Benötigte Zeit des Kompiliervorgangs

Diese allgemeinen Statusinformationen wurden im Rahmen des DotFeed Projekts auch als übersichtlicher RSS Feed aufbereitet (siehe Abschnitt Plugin für Extreme Feedback).

Konfiguration

Wenn der Nutzer die entsprechenden Rechte hat kann er zu einem Projekt Einstellungen treffen. Hier kann ein Projektname und eine Projektbeschreibung angegeben werden. Weiterhin wird hier auch die Webseite des Tracs angegeben. Diese Änderungen sind nur durch einen entsprechend privilegierten Nutzer möglich.

HudsonKonfig.png

Unter der Rubrik Source Code Management wird die URL des Subversions angegeben. Alternativ kann hier auch CVS eingetragen werden.

HudsonKonfig2.png

Unter der Rubrik Build Verfahren werden Build Scripte angegeben. Hierbei können beliebig viele Scripte angegeben werden. Man sollte allerdings im Auge behalten, dass jede Auswertung Zeit beansprucht und deshalb darauf geachtet werden sollte das nicht viele unnötige Scripte mit aufgenommen werden die den Buildprozess unnötig verlangsamen.

In unserem Fall sind das:

  • compile
  • JUnit
  • Junit-Cobertura
  • pmd
  • cpd
  • checkstyle
  • findbug
  • crap4j
  • javancss
  • simian
  • cobertura
  • emma
  • testability

Diese Aufrufe stoßen das kompilieren an und erzeugt die Daten für die Metriken. Die Rubrik Post-Build Aktionen beschreibt die Aktionen die nach dem Build durchgeführt werden sollen.

HudsonKonfig3.png

Hier werden auch die Einstellungen für die Metriken vorgenommen. Jede Metrik bekommt hier eine Datei in der die entsprechenden Auswertungen bereitgestellt werden zugewiesen.

Detailliertere Informationen sind unter hudson.dev.java.net zu finden.

Benachrichtigungen

Wird ein Projekt mit fehlerhaftem Code eingecheckt, erkennt Hudson diesen Fehler beim nächsten Build Prozess. Das ist je nach Einstellungen zu verschiedenen zeit punkten möglich, so kann eine Einstellung das Projekt erlauben, dass ein Projekt nach jedem Checkin neu Kompiliert wird. Alternativ kann auch um Rechenzeit zu sparen der Build zu speziellen Zeiten erfolgen. So ist es hier möglich das ein Build z.B.:

  • Alle 2 Stunden
  • einmal am Tag
  • usw.

erfolgt.

Tritt nun bei einem der Build ein Fehler auf, wobei die art der Fehler auch wieder abhängig von der Hudson Konfiguration ist, wird der Autor des Fehlerhaften Codes benachrichtigt.

Hierzu wird eine Email automatisch von Hudson versendet. Hierbei sind aber auch andere Arten der Benachrichtigung denkbar. z.B.:

  • IM Nachrichten
  • Extreme Feedback
  • usw.

Fehler können je nach Konfiguration z.B.:

  • Code Fehler
  • Verstösse gegen die Coding conventions
  • Unnötig komplizierte Konstrukte
  • usw.

sein.


eStudy Integration

Hudson ist eine Continuous Integration Engine, die selbst in Java geschrieben ist. Selbstverständlich, dass dann die Metriken für Java Programme erfasst und ausgewertet werden können.

Doch Hudson soll nicht nur Java Projekte hosten, sondern auch Projekte in anderen Programmiersprachen. Durch das Plugin Konzept von Hudson und die recht große Community gibt es viele Erweiterungen für andere Sprachen wie PHP, C++, Ruby, Python etc.

Ziel war es nun, die vorhandenen PHPUnit Tests sowie die vorhandenen Selenium GUI Tests in Hudson so zu integrieren, dass diese durchgeführt und visualisiert werden.

Dazu wurde ein weiteres ANT Build Script entworfen, das von Hudson aufgrerufen wird um die Tests durchzuführen. Link

Da aber das eStudy Projekt sehr umfangreich an PHP Code ist, ist es den meisten Programmen zur Erfassung der Software Metriken nicht möglich ihre Analyse fertig zu stellen, da der Speicher für dieses große Projekt nicht ausreicht.


Die Metriken

Alle Metriken, zusätzlich zu den Unit Tests sind hier einsehbar.

PHPUnit

PHPUnit führt Unit Tests für PHP durch. Es werden die schon vorhandenen Unit Tests von eStudy verwendet und in Hudson visualiert: Link


Code Coverage

Diese Metrik sagt aus, wieviel Code der zu testeneden Klasse durch den Test abgedeckt wird.

Das Ergebnis ist hier zu finden: Link


PHPMD

PHPMD -PHP Mess Detector ist ein Programm, das PHP Code untersucht und generelle Fehler finden soll. PHPMD ist der Pendant zu PMD, das Java Code Untersucht. Siehe auch #PMD.

PHPMD befindet sich in einem sehr frühen Stadium und erfasst deshalb erst sehr wenig Metriken.

Um den PHP Code zu untersuchen bedient sich PHPMD dem Programm PDepend.

Leider ist der Code von eStudy schon so groß, dass PHPMD nicht den gesamten Code durchlaufen kann um ihn zu analysieren. Selbst mit 3GB Memory Limit gibt es einen Absturz, da PDepend den Code auf Tokenbasis untersucht und sich so sehr viel merken muss. Und mehr als 3GB Speicher steht für den Test leider nicht zur Verfügung, so dass dieser - und leider auch weitere Tests nicht in Hudson visualisiert werden können.


PHPCPD

PHPCPD von Sebastian Bergmann ist ein Werkzeug um Duplizierten Quelltext im PHP Code zu finden.

Diese Metrik wird durch den CI Server erfasst und durch Hudson visualisiert. Die Ergebnisse sind hier zu finden.


PHP_CodeSniffer

PHP_CodeSniffer untersucht PHP Code nach vorgegebenen Regeln, genau wie #Checkstyle.

In der Standardkonfiguration wird jedoch sehr viel getestet und es werden viel zu viele Teile im Code bemängelt, ungefähr 60 000.

Aus diesem Grund wurde ein Coding Standard mit nur den nötigsten Tests geschrieben, dieser wird von PHP_CodeSniffer und Hudson verwendet, um den eStudy Code nach diesen Konventionen zu überprüfen. Dieser Coding Standard umfasst bis jetzt nur die Richtlinien zur Dokumentation des Codes.

Wenn weitere Überprüfungen stattfinden sollen, kann dies hier eingetragen werden.

Checkstyle Ergebnisse

PDepend

PHPDepend misst ähnlich wie JDependdie Qualität des Codes anhand folgender Metriken:

  • Cyclomatic Complexity: Misst die Komplexität des Code indem es einen Kontrollflussgraphen bestimmt. Je mehr Möglichkeiten es gibt, sich durch das Programm zu bewegen, desto komplizierter ist es und ab einem bestimmten Grad, ist dies schlecht. Unter anderem wird die Tiefe der Verschachtelung gemessen. Siehe auch McCabe-Metrik
  • NPath Complexity: Auch diese Metrik bestimmt die Komplexität einer Funktion, indem es die Anzahl der möglichen Pfade bestimmt.
  • CodeRank: Ähnlich wie der Algorithmus von Google um den PageRank zu bestimmen.
  • Lines Of Code: Diese Metrik erfasst das Verhältnis von Kommentaren im Code zu reinem Code sowie weitere Verhältnisse wie z.B. Anzahl der Methoden und Funktionen pro Klasse usw.

Die folgenden Grafiken sind die Ergebnisse eines PDepend Testlaufes auf dem lokalen Rechner. Die Berechnung dauerte 30 Minuten und verbrauchte während dieser Zeit über 3.8GB an Hauptspeicher sowie mehrere Gigabyte an Festplattenkapazität.

Jdepend-chart-estudy.svg

Jdepend-pyramid-estudy.svg

Artikel zu Metriken der Komplexität in der Software


Sloccount

Sloccount zählt die Anzahl der Code Zeilen und unterscheided dabei die Sprache der Quelltexte. Diese Metrik wird erfasst und mit Hudson visualisiert: Link

Vision Statement

Vision: Produktives Continuous Integration System mit folgenden Features

  • Hudson CI mit folgenden Testvisualisierungen
    • Checkstyle
    • Findbugs
    • PMD
    • TaskScanner
    • EMMA Codecoverage
  • Trac für Wiki und Codebrowser, welcher auch im Hudson verwendet wird um Code Auszüge anzuzeigen
  • SVN mit anonymous read und write access, wenn man sich authentifiziert.
  • Die Benutzerverwaltung geschieht über die Administration in Trac, hier können Gruppen und Rechte verwaltet werden.
  • Hudson Plugin für Zugriff auf Benutzerdatenbank im Trac, um sich mit den Benutzerdaten aus dem Trac im Hudson anmelden zu können
  • Hudson Plugin für Zugriff auf Benutzerdatenbank im Trac, um gezielt eMails versenden zu können.
  • Hudson Plugin für extreme Feedback über eine Anzeigetafel, die der FB EI macht.

Lehrvideo

Lehrvideo SVN

Lehrvideo von Stadin und Weber, als bz2, da zip abgelehnt wurde. Datei:Lernvideo SVN.tar.bz2

Wurde aber auch als CD abgegeben.

Entwurfsmuster Visitor

Vorübergehen werden die Lernvideos zum Entwurfsmuster Visitor hier aufgeführt, demnächst wird ein eigener artikel zu Entwurfsmuster entstehen.

Allgemeine Informationen zum Entwurfsmuster Visitor Visitor_pattern_teilA.swf

Referenzen