Jira Release Notes

[OnDemand]

Hallo zusammen,

wie erstellt ihr eure Release Notes? Würde das gern aus dem Jira Sprint machen, finde aber blöd wie die Releasenotes dann heißen.

Zb ein Issue heißt "Preisberechnung funktioniert nicht mehr wenn man auf Button X klickt" So hieße dann auch der Punkt für die Release Notes.

Ich hätte aber lieber "Preisberechnung funktioniert wieder wenn man auf den Button X klickt". Kennt jemand ein Plugin, welches die "Lösung" auf einem Jira Issue nimmt als Release Note?

Oder wie handhabt ihr das?

 

[LimDul]

Wir schreiben die von Hand (mit Referenz auf das Jira-Ticket) in Form von Ascii Doc.

Sprich, es ist immer Bestandteil eines Tickets, dazu den entsprechenden Abschnitt im New & Noteworthy (so heißen die bei uns) zu schreiben. Nicht jedes Jira Ticket führt da zu einem Eintrag. Aber wir haben auch nur ca. alle 6 Monate ein Release

 

[thecain]

Wir erstellen unsere Release Notes aus den git Commits. Ggf verlinken wir die Jira Stories daran.

 

[OnDemand]

Wir erstellen unsere Release Notes aus den git Commits. Ggf verlinken wir die Jira Stories daran.

Das klingt schon mal gut, wie genau macht ihr das? Copy Paste oder kann Jenkins oder irgendein IDE Plugin dabei helfen?

 

[sascha-sphw]

Wir erstellen unsere Release Notes aus den git Commits. Ggf verlinken wir die Jira Stories daran.

Ist bei euch 1 feature = 1 commit? Damit würdet ihr Euch die Unterstützung von Git extrem einschränken.
Ich mache immer recht viele kleine commits und Kommentare, die genau aussagen, was der commit am Repo verändert (z.B. "moves the class ... into the package ...". Wenn man sich erst einmal dran gewöhnt hat, ist es nicht mehr so schlimm, aber erhöht enorm den Komfort, wenn man doch mal Teile davon reverten muss. All diese commit messages möchte ich nicht in den Release Notes haben.

Ich mache das wie @LimDul nach jedem feature/bugfix... wird mit dem Abschluss immer auch der Eintrag in den Release Notes gemacht, dann auch so das der User, was damit anfangen kann.

 

[thecain]

Wir setzen auf Conventional Commits und squashen die Branches vor dem Merge

 

[OnDemand]

Ich mache es eigentlich immer so, dass ich für jedes Problem / Feature einen Jira Issue erstelle. Wenn ich den bearbeite mache ich einen Branch den ich dann in "Development" pushe. Dannach wird das automatisch aufs Testsystem ausgerollt, von den Testern kontrolliert. Wenn die ihr OK geben, dann gehts in den Master.

Wir machen immer ganz kleine Sprints von 1- 2 Wochen damit wir den Kunden möglichst oft neue Sachen liefern können und die bei Laune halten. (Andere in unserem Metier halten es da so, dass alle 8 Wochen mal ein Update kommt und da dann aber nicht die Probleme der Kunden behoben werden sonder lieber neue Features rein kommen die keinem helfen, daher machen wir das regelmäßiger)

Werde es dann auch so machen, dass wir das lieber manuell machen oder bei jedem PullRequest einen Eintrag in die Release Notes machen.

 

[sascha-sphw]

Ich mache es eigentlich immer so, dass ich für jedes Problem / Feature einen Jira Issue erstelle. Wenn ich den bearbeite mache ich einen Branch den ich dann in "Development" pushe. Dannach wird das automatisch aufs Testsystem ausgerollt, von den Testern kontrolliert. Wenn die ihr OK geben, dann gehts in den Master.

Vom Ablauf her machen wir das auch so, nur mit einem Unterschied, dass die QA auch noch im feature branch gemacht wird. Erst dann darf in develop gemerged werden. Und zusätzlich gibt es noch ein Release QA bevor in master gemerged werden darf.

Wir machen immer ganz kleine Sprints von 1- 2 Wochen damit wir den Kunden möglichst oft neue Sachen liefern können und die bei Laune halten. (Andere in unserem Metier halten es da so, dass alle 8 Wochen mal ein Update kommt und da dann aber nicht die Probleme der Kunden behoben werden sonder lieber neue Features rein kommen die keinem helfen, daher machen wir das regelmäßiger)

Ja, so macht SCRUM in meinen Augen auch nur Sinn. Es geht ja gerade darum, das Risiko auf beiden Seiten zu minimieren und das geht nur durch viele Feedback schleifen. 8 Wochen ist viel zu lange für einen Sprint, lass mal in einer User Story etwas Luft zur Interpretation und schon ist das Schlamassel vorprogrammiert.

Wir setzen auf Conventional Commits und squashen die Branches vor dem Merge

Werden die Daten (Zeitstempel, Commit message, commiter usw.) dann verworfen, oder kann man das dann dennoch noch einsehen? Also kann ich mir das als eine Gruppierung vorstellen, oder werden Roh Daten reduziert?

 

[thecain]

Werden die Daten (Zeitstempel, Commit message, commiter usw.) dann verworfen, oder kann man das dann dennoch noch einsehen? Also kann ich mir das als eine Gruppierung vorstellen, oder werden Roh Daten reduziert?

Das ist eigtl ein rebase, die History wird also verändert. Mit kleinen Features ist das meiner Erfahrung nach aber kein Problem und hält die git History auf dem master sauber. Der gesquashte Commit bekommt dann eben auch eine gute Beschreibung, die in den Release Notes landet.