Maven Release über Hudson

Question

Ich richte Hudson ein, um das Batch-Task-Plugin zu verwenden, um maven-Releases zu unserem internen Repository zu machen. Ich mache es über:

mvn --batch-mode release:prepare 
mvn --batch-mode release:perform 

Ich habe Interesse an anderen Methoden Menschen verwendet haben und die Vor- und Nachteile dieser Methoden. Außerdem sind alle möglichen Probleme, denen die Leute begegnet sind, aufgetreten.

Answer 1

ich dazu neigte, für ein paar Gründe, die Meldungen immer von Hand zu tun. Erstens, wenn Sie ein Rollback durchführen müssen, ist es einfacher, wenn Sie zum ursprünglichen Veröffentlichungsort zurückkehren und es tun können. Zweitens, weil Sie alle Snapshot-Abhängigkeiten als Teil des Prozesses auflösen müssen.

Durch unseren Entwicklungsprozess verlassen wir Abhängigkeiten, die außerhalb des aktuellen Builds der vorherigen Release-Version liegen, bis ein Fix ein Upgrade erfordert. Das heißt, wenn ich Nexus, Maven, etc. herausbringe, dann sehe ich Snapshots und es bedeutet, dass ich diese zuerst veröffentlichen muss. Dieser Prozess ist nicht wirklich automatisierbar, da er sich aufgrund der Änderungen seit der letzten Version ändert.

Das heißt, wir haben eine spezielle Maschine (bei Sonatype ist es nur ein vm) Setup nur für Builds. Dies geschieht, um sicherzustellen, dass keine Umgebungsänderungen auftreten, die einen Build versehentlich beeinflussen könnten (wie bei einer jdk-Änderung). Es macht es auch für jeden einfacher, den Freigabe-Prozess zu erlernen, weil es immer bereit ist zu gehen.

Answer 2

Ich habe immer die Menge ausgelöst Release manuell mit offensichtlichen Vor- und Nachteilen :-)

Answer 3

Wir haben mit dem Hudson Maven Release-Plugin experimentiert, obwohl ich ein bisschen herausgefordert bin, es den Releases richtig zuzuschreiben, ohne böse Dinge, wie das Kennzeichnen von Passwörtern in unsere Build-Dateien.

Answer 4

Kürzlich kam ein M2release-Plugin zu meiner Aufmerksamkeit. Sah nett aus. Allerdings hätte ich mir gewünscht, dass mein Release-Prozess komplett "pom-tweaking-free" wäre. Was ich damit meine ist, dass wir vier Eingangsparameter zur Verfügung zu stellen haben eine vollständige Freigabe zu verarbeiten: (Bsp. 1.0.0)

1. die Release-Version
2. die neue Entwicklungsversion (ex 1.0.1-. SCHNAPPSCHUSS)
3. die Freisetzung in SCM-Tag (ex. release 1.0.0 oder 1.0.0)
4. die Tag-Basis-Strecke in SCM

die ersten 2 akzeptable Standardwerte haben. Die Version, die an der Versionsnummer der Bug-Fix-Version anstößt, ist vollkommen in Ordnung für mich.

Nummer 4 kann in der POM angegeben werden. Es wird sich nicht ändern.

Es ist der dritte, der mich von einer vollständigen Automatisierung einer Freigabe auf Knopfdruck hindert. Das Standard-Release-Tag-Etikett wird es nicht für uns, so dass wir es an:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-release-plugin</artifactId> 
    <configuration> 
     <tag>release-${pom.version}</tag> 
     <tagBase>https://example.com/svn/myProject/releases</tagBase> 
    </configuration> 
</plugin> 

Jetzt, während dies nur sein könnte, was ich brauchte, ich am Ende mit dem -snapshot bei der einen SVN-Tag mit Ende. :(Also muss ich den Tag-Parameter in der Hudson-Job-Konfiguration übergeben. Außerdem muss ich es für jede Version, die wir machen, ändern ... was nicht genau das ist, was ich brauche.

---

Also, am Ende, in der hudson ein maven2 Typ Projekt mit + die m2release hudson Plugin + Maven Release Plugin richtig konfiguriert ist die Mutter aller Freigabeprozess die ich bisher gesehen habe. Obwohl es nicht perfekt war, hat es mir viel Arbeit gespart.

JS.