Maven Release für Nexus

1. Übersicht

Im vorherigen Artikel dieser Serie haben wir einen Bereitstellungsprozess mit Maven für Nexus eingerichtet . In diesem Artikel konfigurieren wir den Freigabeprozess mit Maven - sowohl im POM des Projekts als auch in einem Jenkins-Job.

2. Repository im POM

Damit Maven auf einem Nexus-Repository-Server freigegeben werden kann, müssen die Repository- Informationen über das DistributionManagement- Element definiert werden:

  nexus-releases //localhost:8081/nexus/content/repositories/releases  

Das gehostete Release-Repository ist in Nexus sofort einsatzbereit, sodass es nicht explizit erstellt werden muss.

3. SCM im Maven Pom

Der Freigabeprozess interagiert mit der Quellcodeverwaltung des Projekts. Dies bedeutet, dass wir zuerst die definieren müssen Element in unserer pom.xml :

 scm:git://github.com/user/project.git //github.com/user/project scm:git://github.com/user/project.git 

Oder mit dem Git-Protokoll:

 scm:git:[email protected]:user/project.git scm:git:[email protected]:user/project.git scm:git:[email protected]:user/project.git 

4. Das Release Plugin

Das Standard-Maven-Plugin, das von einem Release-Prozess verwendet wird, ist das Maven-Release-Plugin - die Konfiguration für dieses Plugin ist minimal:

 org.apache.maven.plugins maven-release-plugin 2.4.2  [email protected]{project.version} true releases  

Was hier wichtig ist , ist , dass die releaseProfiles Konfiguration tatsächlich ein Maven Profil zwingen - die Versionen Profil - die während des Freigabeprozesses aktiv zu werden.

In diesem Prozess wird das Nexus-Staging-Maven-Plugin verwendet, um eine Bereitstellung für das Nexus- Release- Nexus- Repository durchzuführen :

  releases    org.sonatype.plugins nexus-staging-maven-plugin 1.5.1   default-deploy deploy  deploy     nexus-releases //localhost:8081/nexus/ true      

Das Plugin ist so konfiguriert, dass der Release-Prozess ohne den Staging-Mechanismus wie zuvor für den Deployment-Prozess ausgeführt wird ( skipStaging = true ).

Ähnlich wie beim Bereitstellungsprozess ist die Freigabe für Nexus ein sicherer Vorgang. Daher werden wir das Out-of-the-Box- Bereitstellungsbenutzerformular Nexus erneut verwenden.

Wir müssen auch die Anmeldeinformationen für den Nexus-Releases- Server in der globalen Datei settings.xml ( % USER_HOME% /. M2 / settings.xml ) konfigurieren :

  nexus-releases deployment the_pass_for_the_deployment_user  

Dies ist die vollständige Konfiguration

5. Der Freigabeprozess

Teilen wir den Release-Prozess in kleine und fokussierte Schritte auf. Wir führen ein Release durch, wenn die aktuelle Version des Projekts eine SNAPSHOT-Version ist - beispielsweise 0.1-SNAPSHOT .

5.1. Release: Reinigen

Das Reinigen einer Version wird:

  • Löschen Sie den Release-Deskriptor ( release.properties ).
  • Löschen Sie alle Backup-POM-Dateien

5.2. Release: vorbereiten

Der nächste Teil des Freigabeprozesses ist das Vorbereiten der Freigabe . dieser Wille:

  • Führen Sie einige Überprüfungen durch - es sollten keine nicht festgeschriebenen Änderungen vorhanden sein und das Projekt sollte von keinen SNAPSHOT-Abhängigkeiten abhängen
  • Ändern Sie die Version des Projekts in der POM-Datei in eine vollständige Versionsnummer (entfernen Sie das SNAPSHOT-Suffix) - in unserem Beispiel - 0.1
  • Führen Sie das Projekt Testsuiten
  • Übernehmen und pushen Sie die Änderungen
  • Erstellen Sie das Tag aus diesem nicht SNAPSHOT-versionierten Code
  • Erhöhen Sie die Version des Projekts im POM - in unserem Beispiel - 0.2-SNAPSHOT
  • Übernehmen und pushen Sie die Änderungen

5.3. Release: durchführen

Der letzte Teil des Freigabeprozesses ist das Durchführen der Freigabe . dieser Wille:

  • Checkout-Release-Tag von SCM
  • Erstellen und Bereitstellen von freigegebenem Code

Dieser zweite Schritt des Prozesses basiert auf der Ausgabe des Vorbereitungsschritts - den release.properties .

6. Auf Jenkins

Jenkins kann den Release-Prozess auf zwei Arten ausführen: Entweder kann es seine eigenen Release-Plugins verwenden oder es kann einfach ausgeführt werden, um das Release mit einem Standard-Maven-Job auszuführen, der die richtigen Release-Schritte ausführt.

Die vorhandenen Jenkins-Plugins, die sich auf den Release-Prozess konzentrieren, sind:

  • Plugin freigeben
  • M2 Release Plugin

However, since the Maven command for performing the release is simple enough, we can simply define a standard Jenkins job to perform the operation – no plugins necessary.

So, for a new Jenkins job (Build a maven2/3 project) – we”ll define 2 String parameters: releaseVersion=0.1 and developmentVersion=0.2-SNAPSHOT.

At the Build configuration section, we can simply configure the following Maven command to run:

Release:Clean release:prepare release:perform -DreleaseVersion=${releaseVersion} -DdevelopmentVersion=${developmentVersion}

When running a parametrized job, Jenkins will prompt the user to specify values for these parameters – so each time we run the job we need to fill in the right values for releaseVersion and developmentVersion.

Also, it's worth using the Workspace Cleanup Plugin and check the Delete workspace before build starts option for this build. However keep in mind that the perform step of the Release should necessarily be run by the same command as the preparestep – this is because the latter perform step will use the release.properties file created by prepare. This means that we cannot have a Jenkins Job running prepareand another running perform.

7. Conclusion

Dieser Artikel zeigte, wie der Prozess der Freigabe eines Maven-Projekts mit oder ohne Jenkins implementiert wird . Ähnlich wie bei der Bereitstellung verwendet dieser Prozess das Nexus-Staging-Maven-Plugin für die Interaktion mit Nexus und konzentriert sich auf ein Git-Projekt.