Standardisierte und kontrollierte Softwarereleases mit dem Maven-Release-Plug-in

Maven-Release-Plug-in: Fehlerteufel ade!

Marcel Hallmann

Jeder Java-Entwickler, der schon einmal ein Maven-Projekt releasen musste, kennt diese Fragen: Welche Versionsnummer soll ich dem Artefakt geben? Habe ich daran gedacht, einen Tag im Repository anzulegen? Wurde das Artefakt im Maven Repository deployt? Sind nach dem erfolgreichen Release sämtliche „pom.xml“ wieder aktuell?

Solche und weitere ähnliche Fragen tauchen immer wieder auf, wenn im Laufe der Entwicklung der aktuelle Stand der Software in Form eines Releases festgehalten werden soll. Beispiele dafür sind das regelmäßige Bereitstellen der neuesten Features oder auch die Übergabe der Software an ein Testing-Team. Besonders bei Multi-Module-Projekten (Kasten: „Maven-Multi-Module-Projekt“) hat sich der manuelle Releaseprozess als mühselig, aufwändig und fehleranfällig erwiesen, da es leicht vorkommen kann, dass einzelne Schritte, wie die Pflege der pom.xml, das Taggen etc., schlicht vergessen oder unvollständig ausgeführt werden. Abhilfe schafft hier das Maven-Release-Plug-in [1]. Mit dessen Hilfe lassen sich diese Fragen leicht beantworten bzw. wiederkehrende Probleme einfach aus dem Weg räumen. Der Entwickler wird hier durch einen interaktiven und standardisierten Releaseprozess geführt und kann sich auf die Beantwortung der gestellten Fragen konzentrieren. In den folgenden Abschnitten werden die Kenaufgaben des Plug-ins vorgestellt, und es wird ein kurzer Überblick gegeben, wie es einzubinden und zu konfigurieren ist. Abschließend werden wir anhand eines kurzen Beispiels einen vollständigen Releasezyklus durchlaufen und so die Funktionsweise anschaulich beschreiben.

Maven-Multi-Module-Projekt

Maven kennt das Konzept hierarchisch strukturierter Projekte, die Multi-Module-Projekt genannt werden. Dabei können unter anderem Informationen aus dem Parent-pom.xml an die Kind-pom.xml vererbt werden (typischerweise allgemeine Informationen wie das Dependency Management). Der Clou an einem Multi-Module-Projekt ist, dass Maven-Kommandos (z. B. $mvn package, $mvn release) nicht auf jedem Modul getätigt werden müssen, sondern nur auf der höchsten Ebene (d. h. auf Ebene des Parent-Projekts). Maven führt das Kommando dann selbständig auf allen Kindern aus. Zusätzlich wird dafür gesorgt, dass die Module in der richtigen Reihenfolge gebaut und allfällige Kreisbeziehungen von Dependencies erkannt werden.

Features

Das Release eines Artefakts mithilfe des Maven-Release-Plug-ins erfolgt in zwei Phasen („Preparing“ und „Performing“): In der Preparing-Phase wird, wie der Name schon sagt, das Artefakt für das Release vorbereitet; in der Performing-Phase findet das eigentliche Release statt:

Phase 1: mvn release:prepare. In der ersten Phase, dem Preparing, werden folgende Aktionen durchgeführt:

  • Entfernen des -SNAPSHOT-Suffixes von der Versionsnummer im pom.xml des zu releasenden Artefakts
  • Ausgabe einer Warnung, falls im pom.xml noch auf eine -SNAPSHOT Dependency verwiesen wird (für eine eindeutige Version darf keine -SNAPSHOT Dependency vorhanden sein, da diese jederzeit überschrieben werden kann und der Build somit nicht reproduzierbar ist)
  • Vorschlag einer Versionsnummer
  • Durchführen der Unit Tests
  • Erstellen eines tags des Projekts im Sourcecode Repository
  • Vorbereiten für die weitere Entwicklung: Inkrementieren der Versionsnummer, Anfügen von -SNAPSHOT an die Versionsnummer und wieder Einchecken der pom.xml in den trunk

Wenn die erste Phase erfolgreich abgeschlossen wurde (Konsolenausgabe „Build Successful“) kann direkt mit der zweiten Phase, dem Deployment des Artefakts in das Maven Repository, fortgefahren werden. Phase 2: mvn release:perform: Die Perfoming-Phase enthält:

  • Auschecken des in der ersten Phase erstellten tags
  • Bauen des ausgecheckten tags (inklusive erneuter Test-Runs)
  • Deployment des erstellten Artefakts, seiner Sourcen und JavaDocs auf ein Maven Repository
Maven-Versionierung

Die Idee bei Mavens Versionierung ist, dass Artefakte, die gerade bearbeitet werden, eine so genannte Snapshot-Version erhalten. Das heißt, dass an die Versionsnummer der Postfix -SNAPSHOT angehängt wird (z. B. 1.0-SNAPSHOT). Wird das Artefakt releast, wird der Postfix entfernt und so eine eindeutige Versionsnummer erstellt (1.0). Für die nächste Iteration der Entwicklung wird die Versionsnummer erhöht und der -SNAPSHOT-Postfix wieder angehängt (1.1-SNAPSHOT).

Geschrieben von
Marcel Hallmann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.