Automatisches Deployment mit Ant und Jenkins

Deploy & Enjoy

Johannes Fiala


Sobald ein Build auf der Entwicklungsumgebung geprüft werden soll, finden die Build-Artefakte auf verschiedenen Wegen zum Applikationsserver. Meist muss ein Entwickler manuell auf seinem Arbeitsplatz builden und danach auf dem Entwicklungsserver einsteigen und deployen (Abb. 1). Diese Vorgangsweise ist zeitraubend und fehleranfällig. Zusätzlich kann es dabei zu nicht mehr reproduzierbaren Builds mit Uncommitted Changes des jeweiligen Entwicklers kommen. Dieser Artikel zeigt aufbauend auf dem Tutorial im Java Magazin 6.2012 die praktische Umsetzung des Deployment Cycles im Rahmen eines Continuous-Delivery-Prozesses. Mit den nachfolgenden Schritten können Sie auf Knopfdruck sauber und nachvollziehbar auf Ihrem Entwicklungsserver deployen.

Lesetipp Dieser Artikel basiert auf dem Continuous-Delivery-Tutorial mit dem Titel „Im Maschinenraum“ von Hanno Wendt und Thorsten Kamm, erschienen im Java Magazin 6.2012.

Abb. 1: Manueller Deployment-Prozess

Eindeutige Kennzeichnung der Build-Artefakte

Der erste Schritt zu sauberen, nachvollziehbaren Builds ist das eindeutige Kennzeichnen jedes Builds mit der aktuellen Revisionsnummer (z. B. aus dem Subversion-Repository). Ideal ist eine Kennzeichnung sowohl im Dateinamen jedes Build-Artefakts als auch im Manifest dieses Artefakts. Damit ist auch nach etwaigen Umbenennungen noch klar erkenntlich, mit welchem Codestand die Artefakte erzeugt wurden. Für die Kennzeichnung des Builds mit Subversion kann das Maven-Plug-in com.google.code.maven-svn-revision-number-plugin [1] genützt werden (Listing 1). Dieses ermittelt automatisch die aktuelle Revisionsnummer des Builds. Diese kann sowohl in den Dateinamen als auch in das Manifest des Builds übernommen werden.

Listing 1: Verwendung des SVN Revision Number Plugin im pom.xml${project.artifactId}-${project.version}-r${prefix.revision}${prefix.specialStatus}com.google.code.maven-svn-revision-number-pluginsvn-revision-number-maven-plugin1.12revisionprefix...

Der Dateiname der von Maven erzeugten Artefakte wird aufgrund der Angaben im Tag finalName assembliert. Dadurch ist aus dem Dateinamen klar erkenntlich, mit welcher SVN-Revisionsnummer das Artefakt gebaut wurde. Die Variable prefix.specialStat...

Automatisches Deployment mit Ant und Jenkins

Deploy & Enjoy

Johannes Fiala


Sobald ein Build auf der Entwicklungsumgebung geprüft werden soll, finden die Build-Artefakte auf verschiedenen Wegen zum Applikationsserver. Meist muss ein Entwickler manuell auf seinem Arbeitsplatz builden und danach auf dem Entwicklungsserver einsteigen und deployen (Abb. 1). Diese Vorgangsweise ist zeitraubend und fehleranfällig. Zusätzlich kann es dabei zu nicht mehr reproduzierbaren Builds mit Uncommitted Changes des jeweiligen Entwicklers kommen. Dieser Artikel zeigt aufbauend auf dem Tutorial im Java Magazin 6.2012 die praktische Umsetzung des Deployment Cycles im Rahmen eines Continuous-Delivery-Prozesses. Mit den nachfolgenden Schritten können Sie auf Knopfdruck sauber und nachvollziehbar auf Ihrem Entwicklungsserver deployen.

Lesetipp Dieser Artikel basiert auf dem Continuous-Delivery-Tutorial mit dem Titel „Im Maschinenraum“ von Hanno Wendt und Thorsten Kamm, erschienen im Java Magazin 6.2012.

Abb. 1: Manueller Deployment-Prozess

Eindeutige Kennzeichnung der Build-Artefakte

Der erste Schritt zu sauberen, nachvollziehbaren Builds ist das eindeutige Kennzeichnen jedes Builds mit der aktuellen Revisionsnummer (z. B. aus dem Subversion-Repository). Ideal ist eine Kennzeichnung sowohl im Dateinamen jedes Build-Artefakts als auch im Manifest dieses Artefakts. Damit ist auch nach etwaigen Umbenennungen noch klar erkenntlich, mit welchem Codestand die Artefakte erzeugt wurden. Für die Kennzeichnung des Builds mit Subversion kann das Maven-Plug-in com.google.code.maven-svn-revision-number-plugin [1] genützt werden (Listing 1). Dieses ermittelt automatisch die aktuelle Revisionsnummer des Builds. Diese kann sowohl in den Dateinamen als auch in das Manifest des Builds übernommen werden.

Listing 1: Verwendung des SVN Revision Number Plugin im pom.xml${project.artifactId}-${project.version}-r${prefix.revision}${prefix.specialStatus}com.google.code.maven-svn-revision-number-pluginsvn-revision-number-maven-plugin1.12revisionprefix...

Der Dateiname der von Maven erzeugten Artefakte wird aufgrund der Angaben im Tag finalName assembliert. Dadurch ist aus dem Dateinamen klar erkenntlich, mit welcher SVN-Revisionsnummer das Artefakt gebaut wurde. Die Variable prefix.specialStat...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang