Continuous Integration (CI) ist in der Softwareentwicklung kaum mehr wegzudenken.
Als Softwaretool kommt dabei häufig Jenkins zum Einsatz, das dann mit Apache ANT oder Maven den eigentlichen Buildprozess steuert.
Funktioniert die CI im Javaumfeld mit JUnit sehr gut und bekommt man Tests so recht schnell umgesetzt, so wird das Testing etwas komplizierter, wenn der Code zwischen Server und Client getrennt sind.
Damit eine sinnvolle Testen im Rahmen von Continuous Integration möglich wird, braucht man allerdings etwas mehr als nur Jenkins und JUnit. Beispielsweise ist die Integration von statischer Codeanalyse sinnvoll, welche dann auf Probleme im Code hinweisen soll. Aus diesem Grund wird im folgenden ein ANT Skript vorgestellt, welches folgende Softwarekomponenten verwendet:
- Apache Ant
- Apache Tomcat
- Checkstyle
- Cobertura
- FindBugs
- Jenkins
- JUnit
- JDepend
Wie man schon an der Menge der beteiligten Tools ablesen kann, ist die Koordination der Tools nicht gerade einfach. Vorausgesetzt wird hier noch eine JDK Installation und das Setzen von Umgebungsvariablen im Betriebssystem, damit während des Builds im Jenkins die Tools auch gefunden werden können (beispielsweise ANT_HOME oder JDEPEND_HOME).
Das ANT Skript, welches Jenkins für den Build heranzieht, besteht aus diversen Targets, wobei nur wenige (es sind sechs an der Zahl) so genannten Public Targets sind. Das am häufigsten verwendete ANT-Target dürft wohl „build.daily“ sein, welches neben der Durchführung der eigentlichen JUnit-Tests auch statische Code-Analysen durchführt und die Applikations-Packages (in Form von war-Dateien) baut.
Intern gliedert sich das ANT-Skript in mehrere Bereiche. Es prüft beispielsweise die Vorbedingungen für das Skript selbst (also beispielsweise, ob alle notwendigen Umgebungsvariablen gesetzt wurden) und gibt im Problemfall Warnungen aus. Des Weiteren besteht das Skript aus validation-Targets, welche die Codeanalyse durchführen, wie auch aus test-Targets, welche den Java-Code im Tomcat testen und anschließend eine Code-Coverage der Tests liefern. Dabei wird ein installierter Tomcat-Server sogar gestartet und nach dem Abschluss der Testausführung auch wieder gestoppt bzw. wird dorthin auch das Deployment der zu testenden Applikation übernommen. Allfällige Variablen, welche während des ANT-Builds notwenig werden (beispielsweise die Versionsnummer welche für die Packages verwendet werden soll oder auf welchem Port der Apache Tomcat startet), sind dabei in eine eigene build.properties Datei ausgelagert, so dass auch die JUnit-Tests Zugriff auf diese Werte haben.
Nach dem der Build durchgeführt wurde, befinden sich in einem neu generierten build-Verzeichnisse die unterschiedlichen Reports und Packages, welche durch das ANT-Skript produziert werden. Diese Reports können dann in Jenkins verwendet werden, um eine grafische Repräsentation der Ergebnisse zu erreichen.
Angefügte Dateien:
Der Start des Build kann entweder in Jenkins konfiguriert werden und zu bestimmten Zeitintervallen erfolgen (was auch dringend empfohlen wird) oder per Kommandozeile „ant build.daily -lib /opt/jdepend/lib“ erfolgen.