Continuous Delivery mit Hilfe von Maven

In vielen Projekten habe ich bereits das Problem gehabt, dass der Transfer der Artefakte vom Repository auf eine Test-Instanz sich nur mit Mühe automatisieren lässt. Gerade das Kopieren der Artefakte ist in der Regel ein wichtiger Punkt - wie ist sichergestellt, dass die Artefakte für das Deployment mit den Artefakten aus dem Repository übereinstimmen? Eigentlich nur dann, wenn diese auch direkt aus dem Repository kommen und ohne Veränderung oder eigenen Buildprozess auf den Server kopiert werden.

Für diese Probleme existieren unterschiedliche Lösungsansätze, vom Shell- oder Powershell-Skriptbis hin zu CI-Lösungen, die direkt aus dem Buildserver Artefakte auf den Server kopieren. Nachteil ist, dass alle Lösungen in irgendeinerweise von der Plattform abhängig sind.
Eine Lösung ist, dass das Kopieren der Artefakte über das Buildtool geregelt wird. Dabei wird ausgenutzt, dass die Verbindung zwischen Buildtool und Repository bereits ohne Probleme funktioniert und auch die Ablage / der Bezug der entsprechenden Dateien erfolgt an zentraler Stelle. Natürlich ist immer noch ein kleiner Anteil an plattformabhängigem Skript notwendig, aber der Großteil der Arbeit - beispielsweise Verbindungsaufbau, Bezug der Artefakte aus dem Repository, Authentifizierung am Repository - wird durch das Buildtool erledigt. Voraussetzungen für diese Lösung sind:

• zentrales, vom Server erreichbares Repository (Nexus, Archiva, ...)
• Installation von Maven auf dem Server
• Scheduler für ein geplantes Ausführen von Tasks

Die Installation der entsprechenden Tools wird an dieser Stelle nicht genauer erläutert, diese sollte bereits bekannt sein (oder kann in der Dokumentation nachgelesen werden).

Für das Kopieren der Artefakte wird ein einfaches Maven-Projekt aufgesetzt, bestehend aus nicht mehr als einem POM. Das POM beinhaltet zum einen die Angaben zum Repository...

... als auch den zentralen Abschnitt für das Kopieren der Artefakte in das Verzeichnis für das Deployment. Für eine bessere Lesbarkeit wurden die Pfade des Servers in Properties ausgelagert und separat platziert.

Für das Kopieren wird ein spezielles Plugin genutzt, das Maven Dependency Plugin. Das Plugin bietet eine Menge nützlicher Goals und kann unter anderem für das Kopieren von *.jar Dateien aus einem Repository genutzt werden.

Es wird definiert, dass in package Phase zusätzliche Aktionen ausgeführt werden - die beiden hier definierten Artefakte werden in die entsprechenden Verzeichnisse kopiert. Im ersten Schritt wird die Webanwendung selbst kopiert, im zweiten Schritt wird der Treiber für den Zugriff auf die Datenbank kopiert (dieser wird nicht von der Webanwendung mitgeliefert, da diese nicht wissen soll auf welche Datenbank zugegriffen wird).


Neben den obligatorischen Angaben der groupId, der artifactId, der version und des type, werden weitere Angaben getätigt.

Für die Webanwendung wird definiert, dass Artefakte überschrieben werden können, das Output-Verzeichnis wird festgelegt und der Dateiname für die Anwendung wird ebenfalls definiert. Das gleiche wird für den Treiber ebenfalls angegeben.

Das Kopieren der Dateien ist somit erledigt und wird automatisch durch Maven ausgeführt. Was bleibt ist allerdings der manuelle Aufwand für die Vorbereitung des Deployments. Dafür muss ein entsprechendes, plattformabhängiges Skript erstellt werden.

Je nach Betriebssystem und der eigentlichen Installation des Tomcat unterscheidet sich das Skript in wenigen Details. Das oben angeführte Skript ist ausgelegt für das Deployment eines Artefaktes auf einem einzelnen Server, welcher als Dienst gestartet wurde. Es werden die Verzeichnisse gelöscht und danach wird mit einem einzigen Aufruf das Artefakt in das entsprechende Verzeichnis kopiert.

Dieses Skript kann dann mit dem entsprechenden Scheduler eingeplant und ausgeführt werden.

Alles in allem eine schlanke Methode für das kontinuierliche Deployment von Artefakten auf einem Server. Natürlich mit Schwächen, gerade beim Deployment auf einem Cluster oder komplexen Deployments die nacheinander erfolgen müssen, aber für einfache Anwendungen auf singulären Instanzen sicherlich eine akzeptable und vor allem stabile Lösung.