Wir veröffentlichen ein Java-Projekt mit Maven auf eine neue Art und Weise

Wir alle sind seit langem an Maven gewöhnt, an die Versionierung und das Abhängigkeitsmanagement. Maven wurde geboren, als die tägliche Versammlung des Projekts das Wagemutigste war, als es als normal angesehen wurde, mindestens ein paar Mal im Jahr veröffentlicht zu werden. Jenkins hieß dann Hudson und die Bäume waren groß ...

Die Ideen, die maven in die Entwicklungswelt brachte, waren äußerst beliebt und wurden schnell populär: Definieren eines Standard-Workflow-Projekts, eines Standard-Verzeichnismodells und vieles mehr, was seit langem als selbstverständlich angesehen wird.

Als eine der Innovationen führte maven ein Standard-Versionsverwaltungssystem ein. Die Version wurde in der Projektdatei gespeichert und bei jeder Veröffentlichung einer neuen Version geändert. In einer Welt, in der es nicht jedermanns Sache war, einen Zweig und seinen Merjunt zu schaffen, war ein solcher Ansatz weit verbreitet.

All dies vereinfachte die Entwicklung, den Start neuer Projekte, die Einführung von Entwicklern in das Projekt, die Veröffentlichung der Version und das Abhängigkeitsmanagement erheblich.

Aber die Welt steht nicht still und trotz der Tatsache, dass viele von maven umgesetzte Ideen immer noch leben und von einem Projekt zum anderen wechseln, ist die Versionierung von maven eher ein Problem als ein Vorteil geworden.

Als nächstes werden wir versuchen, die Welt zum Besseren zu verändern und unser Leben zu vereinfachen.


In der modernen Realität wird die Veröffentlichung mehrerer Versionen pro Woche und sogar pro Tag als Ziel betrachtet, wenn nicht sogar als Norm. Unter solchen Bedingungen führt das Speichern der Version in der Projektdatei zu einem sehr hohen Overhead.

Jede Version führt zu zwei Commits für das Repository. Infolgedessen gibt es bei der aktiven Entwicklung und Freigabe des Projekts mehr solche technischen Commits als nützliche. Die Geschichte des Projekts ist übersät und schwer zu verstehen.
Dieser Ansatz führt auch zu doppelten Informationen: Es ist üblich geworden, die Version nicht nur in der Projektdatei, sondern auch in Form eines Repository-Tags zu speichern.

Außerdem stellte sich die Sicherheitsfrage: Wenn Sie ein großes Projekt haben, benötigt die Build-Maschine nur Zugriff darauf. Wenn es viele Projekte gibt, ist der Zugriff auf viele Projekte erforderlich, und wir erstellen entweder einen Superuser mit Zugriff auf alle Projekte mit dem Recht zu schreiben, oder wir erhalten eine zusätzliche Belastung durch die Verwaltung einer großen Anzahl von Benutzern mit einem engen Satz von Rechten, aber dennoch mit dem Recht, in das Repository zu schreiben, und häufig und das Recht, sich ohne Anforderungspool und Überprüfung an den Master zu binden.

Bei Verwendung von maven mit dem Release-Plugin wird eine weitere interessante Funktion angezeigt: Die Neuerstellung wird nicht mit denselben Befehlen wie in der Originalversion durchgeführt.

Vielleicht scheinen all diese Probleme für jemanden weit hergeholt zu sein, aber bei einer mehr oder weniger großen Anzahl von Projekten wird das Verwalten und Konfigurieren von CI / CD zu einem äußerst unangenehmen und verwirrenden Prozess.

Nachdem das Problem nun sichtbar ist, versuchen wir, es zu lösen, um die Tools, Prozesse und im Allgemeinen nicht so zu ändern, dass es selbst irgendwie funktioniert.

Was ist erforderlich:

• Die Version wird einmal als Repository-Tag gespeichert
• Die Neuerstellung einer beliebigen Version ist möglich. Die Schritte sollten mit denen einer neuen Version identisch sein
• Ich benötige keine Schreibberechtigungen für das Repository
• Wir verwenden Maven immer noch als Projektmanager

Angenommen, CI / CD erhält ein Tag für uns und checkt ein Projekt aus.

Angenommen, das Tag für uns ist mit CI / CD in der Umgebungsvariablen RELEASE_TAG gefüllt. Um die Version freizugeben, müssen wir die folgenden Befehle ausführen:

mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2) 

1 - Aktualisiert Versionen in POM-Dateien des Projekts und seiner Module
2 - Erstellt und lädt bei korrekter Konfiguration des Projekts Artefakte in das Repository hoch

Vergessen Sie nicht, das Flag -B zu setzen, sonst verwandelt sich das Ausführungsprotokoll in einen Kürbis.

Wichtig: Um Verwirrung zu vermeiden und klar zu zeigen, wie und woher die Assembly stammt, müssen Sie die Projektversion in einer abstrakten Form installieren, z. B. DEVELOPMENT-SNAPSHOT. Sie können denselben Befehl verwenden: version: set. Die Operation ist eine einmalige Operation, da wir die Version des Projekts nicht mehr in einer Datei speichern.

Aufgrund der Änderungen können Sie die Konfiguration des Maven-Release-Plugins und des SCM-Blocks aus der POM-Datei entfernen.

»Von den Minuspunkten:
Wenn Sie die SNAPSHOT-Versionen irgendwo verwenden, kann es zu Verwirrung kommen. Jetzt sehen alle SNAPSHOT-Versionen gleich aus. Und vielleicht ist diese Art, Projekte freizugeben, nichts für Sie.

Es mag scheinen, dass das Artefakt, das aus demselben Commit, aber mit unterschiedlichen Tags gesammelt wurde, dasselbe ist, aber leider ist dies nicht der Fall. Wir machen immer noch die Version in der Datei verfügbar und daher werden die gesammelten Pakete unterschiedlich sein.

»Von den Profis:

• Alle Anforderungen sind erfüllt und noch mehr!
• Die Version wird nur im Projekt-Tag gespeichert
• Die Montage der neuen und die Neuerstellung der alten Version werden mit denselben Befehlen wie in der Originalversion ausgeführt
• Es sind keine Rechte erforderlich, um sich für das Projekt zu engagieren
• Die Toolbox bleibt gleich
• Bonus: Projektkonfiguration vereinfacht

Zwei Zeilen retteten also wieder die Welt.
Das ist alles, danke für Ihre Aufmerksamkeit!