Build

Diese Seite beschreibt den Build und das Ausbringen der Artefakte.

Um eine Konfiguration des Builds auf Projekt-Basis zu erlauben, hat jedes JaProSt Projekt unter src die Datei japrost-project.txt liegen. Damit lassen sich z.B. projektspezifische maven Profile aktivieren.

Build-Stages

Für den Build gibt es drei Stages: "local", "internal" und "public". Sie sind in der parent-pom weitgehend vorkonfiguriert.

"local" dient der Entwicklung und ist ohne spezielle Konfiguration in den settings nutzbar. "local" hat als scm das geclonte Repository.

"internal" dient dem Erstellen von Releases. Hier müssen ggfs. Server in den settings konfiguriert werden. "internal" hat als scm einen internen clone des Repositories.

"public" dient dem Veröffentlichen von Artefakten und der Site. Dazu müssen entsprechende settings konfiguriert werden. "public" hat als scm das in der pom konfigurierte Repository.

Entwicklung "local"

Der Entwickler-Build ist für den einfachen Build durch Entwickler gedacht. Alle Artefakte können in temporäre Verzeichnisse gebaut und deployed werden. Dort können sie geprüft werden. Es finden nur SNAPSHOT- und keine Release-Builds statt.

Der Entwickler-Build hat das lokale git als scm und ist das Ziel von commits.

Erstellen der SNAPSHOT-Artefakte

Typischerweise werden bei der Entwicklung mit einem clean install die Artefakte lokal installiert. Ein deploy obliegt der "public"-Stage.

Erstellen der SNAPSHOT-Site

Zum Testen der zusammenhängenden Site aller Projekte empfiehlt es sich, diese an eine gemeinsame Stelle zu "stagen" mit post-site site:stage.

Hierfür muss über z.B. -DstagingDirectory=/tmp/japrost/site/ die gemeinsame Ausgabe gewählt werden und über -DtopSiteURL=http://www.japrost.de/ das relativieren der Links einheitlich erstellt werden. Die Properties können natürlich auch über ein Profil in den Settings gesteuert werden.

Nicht zu vergessen, dass für die Site des Parent-Projekts über -f site-pom.xml die pom für die Site ausgewählt werden muss und ein Erstellen der "zu vererbenden" Site nicht notwendig ist.

Releases "internal"

Der interne Build ist für das Vorbereiten der Veröffenlichung bestimmt. In dieser Stage werden die Releases erstellt. Die Site wird hier aktuell nicht gebaut / veröffentlicht.

Erstellen der Release-Artefakte

Releases werden zunächst nur intern ohne site und deploy durchgeführt: mvn -DpushChanges=false -DlocalCheckout=true -Dgoals=install clean release:prepare release:perform

Durch das release:perform wird das Profil signArtifacts automatisch aktiviert.

Das veröffentlichen der Artefakte wird auf dem durch das release-plugin erstellten TAG durchgeführt (s.u.). Erst nach der Veröffentlichung werden die lokalen Änderungen durch das Release intern integriert.

Veröffentlichen "public"

Der öffentliche SNAPSHOT-Build ist zum Veröffenlichen der SNAPSHOT-Artefakte und der aktuellen SNAPSHOT-Site bestimmt.

Der öffentliche Release-Build ist zum Veröffentlichen der Release-Artefakte bestimmt. Die Release-Site wird aktuell nicht veröffentlicht.

Veröffentlichen der SNAPSHOT-Artefakte

Über ein clean deploy können die SNAPSHOT-Artefakte veröffentlicht werden, sofern der der Server japrostSnapshotsId in den settings konfiguriert ist.

Veröffentlichen der SNAPSHOT-Site

Zum Veröffentlichen der SNAPSHOT-Site über ein site-deploy muss in den settings sowohl der Server japrostSiteId als auch das Property japrost.distribution.site.url korrekt konfiguriert sein. Für letzteres bietet es sich an ein Profil in den settings anzulegen.

Veröffentlichen der Release-Artefakte

Zum veröffenlichen der Release-Artefakte muss das Release-Tag aus dem Release-Build ausgechecked werden und darauf ein clean deploy ausgeführt werden. Dabei muss das Profil signArtifacts aktiv sein, um die Artefakte mit gpg zu signieren. Die Server japrostOpenPGP und japrostReleasesId müssen in den settings konfiguriert sein.

??? automatisch aus parent pom? Für Java-Projekte muss das Profil javadocNsources aus der java-parent-pom aktiviert sein, um das JavaDoc und die Sourcen mit zu veröffentlichen.

Profile

Folgende Profile kommen bei den builds in Einsatz

Name Definition Anmerkung
local parent-pom für lokale Entwicklung
javadocNsources java-parent-pom für release builds
signArtifacts parent-pom für release builds

local

Dieses Profil setzt alle Einstellungen damit lokal builds nicht fehlschlagen.

javadocNsources

Dieses Profils konfiguriert die Plugins maven-javadoc-plugin und maven-source-plugin. Es wird manuell aktiviert und ist für public releases von jar-Projekten notwendig.

signArtifacts

Dieses Profil konfiguriert das maven-gpg-plugin zum releasen der Artefakte. Für release builds ist es automatisch aktiv (da das release:perform das Property performRelease setzt).

Checklist Release

Bauen und veröffentlichen der Release-Artefakte. Für "synchrone" Releases können die Schritte auch für die Projekthierarchie parallel ausgeführt werden (also erst bei allen die changes anpassen, dann alle Release-Artefakte erstellen, ...). Dies erlaubt es, sicherzustellen, dass keine Versionen "verbrannt" werden, da bis zu den Aktionen auf OSS alles zurückgedreht werden kann.

  • changes (und ggfs. pom) anpassen und integrieren
  • Ausführen "local build": Lokal alles bauen und installiern
  • Ausführen "local site": Lokal die Site bauen, installiern und prüfen
  • Ausführen "internal release": Erstellen der Release-Artefakte
  • Veröffentlichen auf dem Release-Tag
    • Checkout "release tag": Auf die Release-Sourcen wechseln
    • Ausführen "public release": Bauen und deployen der Release-Artefakte nach OSS staging
  • Veröffentlichen der Artefakte über OSS (staging repositories)
    • "Close" des Release repositories
    • "Release" des Release repositories
  • auf maven-central: warten auf öffenliche Verfügbarkeit (ca 15 min.)
  • Veröffentlichen der Site (Release-Version)
    • Site vom Projekt
    • JaProSt-Site mit update der Versionen-Seite

Veröffentlichen der Code-Basis

  • "master" (next SNAPSHOT) auschecken
  • Versionen korrigieren (TODO: find a way to get the right next version automatically) und (amend) committen
  • push nach allen scm (auch die tags!)