Release Management in der einfachsten Form

[OnDemand]

Hallo zusammen,

ich möchte mein neues Programm gern mit Releases arbeiten. Jeden 2. Freitag soll ein neues Release kommen mit neu eingebauten Features, Bugfixes usw.

Aktuell habe ich folgendes Setup:

Bitbucket Branch TEST und MASTER
Jira
Jenkins

Ablauf eines Issue:

In Jira erstelle ich einen neuen Branch aus dem Master für den Issue, in dem Branch wird entwickelt. Dann wird der Branch in den TEST gemerged. Das Testsystem updated die App und ich teste in der Test-App ob es auch online funktioniert und nicht nur lokal.
Wenn iO wird der ISsue-Branch in den Master gemerged.

Jetzt soll hier eine Versionierung kommen, neue Version wird gebaut.

Wie wo an welcher Stelle muss ich jetzt mit der Versionierung arbeiten? Freue mich über Tipps!

 

[LimDul]

Du hast z.B. aktuell die Version 1.0.0 released. Dann würde ich es so machen:
* In den POMs steht die 1.1.0-SNAPSHOT als Development Version drin
* Wenn eine neue Version gebaut wird, wird das die 1.1.0 und die POMs auf 1.2.0-SNAPSHOT aktualisiert.
* Solltest du einen Hotfix benötigen, baust du zwischendurch eine 1.0.1.
* Wenn du die Versionen im test taggen willst, nimmst du da 1.1.0-rc0 oder was auch immer da als Modifier bzgl . Versionen möglich sind. Es gibt da afaik: -a für Alpha (nutzen wir für Tagesreleases, z.B. -a20210224), -ms für Milestone, -rc für Release Kandidates etc.

 

[OnDemand]

was heißt dieses snapchot? Das sieht im Namen doof aus, wenn das menie.jar baut.

Muss ich die Version in der pom.xml dann manuell erhöhen? Sorry für die blöden Fragen, aber hab mit Versionierung noch nicht wirklich was zu tun gehabt

 

[LimDul]

7 Understanding Maven Version Numbers

In a Maven environment, it is very important to understand the use of version numbers. A well thought out strategy can greatly simplify your dependency management workload.

docs.oracle.com

Beschäftige dich mal damit intensiver (ist jetzt nicht direkt Maven Doku, war aber das erste passende Suchergebnis)

 

[OnDemand]

Danke! Zum Snapshot hab ich folgendes gefunden. Das klingt schon mal logisch https://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-it

Nun ist mir nicht klar wie ich es aus dem Snapshot hin zur finalen Version bekomme. Ich schau mir mal deinen Link an, vielleicht beantwortet das meine Fragen

In meinem Link hier steht auch, dass man in der pom.ml manuell hochzählt ok dann wäre das auch geklärt.

Wenn nicht; bis gleich

 

[mihe7]

Evtl. kannst Du das Maven Release Plugin verwenden: https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html

 

[Thallius]

So ganz verstehen tue ich deine Problematik nicht. Ich habe einen Master branch und in den wird die nächste Release in dem Moment gemerged wenn ich deployen will. Somit habe ich z.B. gerade 1.0.14 released. Das nächste Minor Update kriegt dann die 1.0.15 und das nächste Major update bekommt die 1.1.0. Eine komplett neue Version 2.0.0 ist für mich immer ein kompletter rework bzw. halt ein Upgrade kein Update (BWL Technisch gesehen kosten Änderungen der vordersten Zahl den Kunden eben Geld, während Änderungen an den beiden hinteren Stellen kostenlos sind)
Wozu brauch ich da einen SNAPSHOT? Wenn ich 1.015 released habe setzt ich die neue Nummer erstmal auf 1.0.16. Solange das nicht im Master landet ist es also ein SNAPSHOT. Wozu muss ich das extra so nennen?

Auch kann ich diese Branch inflation nicht verstehen. Es gibt maximal 4 Branches:

Master (Alles was rausgeht)
Testing (Damit arbeitet die QC)
Develop (Hier kommen Änderungen und neue Features rein)
Bugfix (Hier werden hotfixes gemacht)

Bugfix kann man dann schnell auf Master, Testing und Develop mergen wenn ein Hotfix nötig ist.

Für jeden Issue ein eigener Branch ist doch Wahnsinn. Wer will das denn noch pflegen?

 

[LimDul]

Der normale Prozess ist irgendwann entscheidet man sich "Der Stand soll jetzt als Version X released werden".
Dann setzt man in allen Poms die Version entsprechend, baut das/die Artefakte und lädt sie in den Nexus hoch.

Danach setzt man in allen POMs die Version wieder auf Snapshot.

Um diesen Prozess zu automatisieren, gibt es in dem ganzen Konglomarat von GIT, Jenkins & Maven verschiedene Tools und Strategien:
* Maven hat das Release Plugin um die Version zu setzen
* In GIT taggt man in der Regel auch die Version
* Jenkins wird oft zur orchestrierung genutzt.

Hier im Projekt haben wir es z.B. so, wenn ich einen Stand Tagge mit einer Versionsnummer wird automatisch ein Jenkins Job angelegt und wenn der gebaut wird, passt der POM an und lädt das mit der Version hoch.

Es gibt auch den anderen Weg, dass man Jenkins sagt "Bau ein Release mit Version X" und dann macht der alles:
* Versionsnummer in POM anpassen
* In GIT taggen
* bauen
* Dann auf Snapshot setzen

Und mit Sicherheit gibt es noch zig andere Wege das zusammenzustecken.

 

[LimDul]

Für jeden Issue ein eigener Branch ist doch Wahnsinn. Wer will das denn noch pflegen?

Das ist das das Standard-GIT vorgehen. Eigener Branch => Und wenn fertig zurückmergen.
Siehe https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow

 

[mrBrown]

Das nächste Minor Update kriegt dann die 1.0.15 und das nächste Major update bekommt die 1.1.0. Eine komplett neue Version 2.0.0 ist für mich immer ein kompletter rework bzw. halt ein Upgrade kein Update (BWL Technisch gesehen kosten Änderungen der vordersten Zahl den Kunden eben Geld, während Änderungen an den beiden hinteren Stellen kostenlos sind)

https://semver.org/lang/de/ => erste Stelle sind Breaking Changes, zweite sind Features, letzte sind Patches

Wozu brauch ich da einen SNAPSHOT? Wenn ich 1.015 released habe setzt ich die neue Nummer erstmal auf 1.0.16. Solange das nicht im Master landet ist es also ein SNAPSHOT. Wozu muss ich das extra so nennen?

Damit zB Maven das auch als Snapshot erkennt. Für das gesamte Tooling ist der Branch nicht relevant, nur die Versionsnummer. Ohne SNAPSHOT behandelt Maven das immer als ganz normales Release.
Ist zB auch für install im lokalen Repo oder Release in Snapshot-Repos relevant.

Für jeden Issue ein eigener Branch ist doch Wahnsinn. Wer will das denn noch pflegen?

Das macht eigentlich jedes Projekt so, welches mit Merge Requests oä arbeitet, das ist heutzutage völliger Standard.
Grad bei Open Source Projekten mit mehreren Beitragenden gibt’s auch keine wirkliche Alternative dazu.

 

[LimDul]

Bezüglich der Branches - Im Endeffekt muss man ein Entwicklungsvorgehen finden, was für das Projekt trägt. Meist ist es sinnvoll sich da an bestehenden anzulehnen und die Best-Practices zu übernehmen. Das ist in der Regel was in Git mit Branches arbeitet.

Klar ist aber - man muss nicht alles übernehmen, nur weil irgendjemand sagt "Das ist gut". Aber man muss zumindest sich bewusst sein, warum das als gut bewertet wird und sich dann aktiv entscheiden, dass diese Dinge keine Rolle spielen oder man sie anders löst.

Branches mit Pull-Requests haben halt mehrere Vorteile:
* Man kann darüber Code-Reviews erzwingen, dokumentieren und durchführen. Das steigert die Qualität, als wenn jeder ohne 4-Augen-Prinzip direkt auf den Branch pushen kann, der dann irgendwann ausgeliefert wird.
* Im Sinne von Continues Integration will man auf dem aktuellen Entwicklungszweig immer einen deploy- und lauffähigen Stand haben. Das impliziert das da nur Features landen dürfen, die fertig sind und in irgendeiner Form schon mal getestet sind
* Je größer die Zahl der Entwickler ist, um so mehr muss man die Arbeit strukturieren das die Leute ungestört ihr Feature fertig entwickeln können.

Wenn z.B. nur eine Person entwickelt, kann man sich viel davon schenken.