Branching Best Practise

[OnDemand]

Hi!
Frag mich grad wie ich am besten vorgehe, was das anlegen von Branches angeht.

Ich (alleiniger Entwickler) will mir gleich einen vernünftigen Workflow aneignen und nicht will durch einander entwickln. Hab noch einen Kollegen der testet, was ich entwickle und wir wollen in Sprints arbeiten um immer alle 4 Wochen eine neue Version zu releasen. Ist für unsere Kunden einfach gut so, so können sie sich auf Update einrichten usw.

Jetzt hab ich es in dem Sprint mal so gemacht:
Branch angelegt "release-3.0.5"
Darin hab ich alle Issues (Jira) eingebaut und in commit message die Issue Nummer eingetragen

Eine andere Möglichkeit ist ja, pro Issue einen Branch zu machen. Geht auch direkt aus Jira heraus. Wenn ich dann aber sagen wir 10 Branches habe am Ende des Sprints muss ich die alle in den Master mergen (manuell?) Oder gibts da in Bitbucket eine einfache Möglichkeit?

Welche der beiden Varianten haltet ihr für sinnvoll und warum? Welche Erfahrungen habt ihr gemacht. Möchte mich gern vorher informieren und nicht erst in Probleme laufen

 

[thecain]

Ich verstehe nicht ganz. Die selbe Frage hast du doch schonmal gestellt? https://www.java-forum.org/thema/releaseablauf.191277/

Auf jeden Fall werden die Antworten hier woeder hnlich ausfallen...

 

[OnDemand]

Danke, dass du den Thread raus gegraben hast. Die Frage wäre im von dir genannten Thread aber gut aufgehoben, da hast du recht es wurde da schon etwas angeschnitten.

Die Frage ist ; wann Branch erstellen? Auf Issue Ebene oder auf Version-Ebene. Wer hat Erfahrung und kann diese teilen? Welceh Vorteile/Nachteile hat es wenn ich pro Issue einen Branch erstelle oder eben auch nicht?

 

[kneitzel]

Die Frage ist ; wann Branch erstellen? Auf Issue Ebene oder auf Version-Ebene. Wer hat Erfahrung und kann diese teilen? Welceh Vorteile/Nachteile hat es wenn ich pro Issue einen Branch erstelle oder eben auch nicht?

Ich (alleiniger Entwickler) will mir gleich einen vernünftigen Workflow aneignen

Als alleiniger Entwickler ist fast alles schlicht overkill!

Hast Du eine Pflege alter Versionen? Sprich: Machst Du Support für Leute, die noch eine alte Version nutzen und nicht auf eine aktuelle Version gehen wollen?

Wie viel Zeit arbeitest Du daran? Arbeitest Du parallel an mehreren Dingen?

Also ich entwickle an meinen Projekten Gradlinig. Wenn es ein Release gibt, dann wird da ein Tag gesetzt. Aber ansonsten arbeite ich in der Regel eine Sache nach der anderen ab. Da ich mich nicht verzetteln will, fange ich nichts an, ehe das angefangene nicht zu einem halbwegs vernünftigen Stand gekommen ist. Und damit reicht mir sogar ein einziger Branch und ich erstelle NIE einen weiteren Branch. Wenn ich das bräuchte, könnte ich aber natürlich jederzeit einen Branch erstellen. Wenn ich auf Version 1.0 etwas machen wollte, dann könnte ich zum Tag der Version gehen und einen neuen Branch starten. Aber so lange wie das nicht vorkommt, belaste ich mich nicht damit.

Also: Ich mache nichts, wofür ich keinen Grund sehe! Siehst Du einen Grund für einen Branch? -> Dann mach einen bzw. bewerte den Grund und wiege den mit Risiken/Aufwand und so ab.

 

[mrBrown]

Also ich entwickle an meinen Projekten Gradlinig. Wenn es ein Release gibt, dann wird da ein Tag gesetzt. Aber ansonsten arbeite ich in der Regel eine Sache nach der anderen ab. Da ich mich nicht verzetteln will, fange ich nichts an, ehe das angefangene nicht zu einem halbwegs vernünftigen Stand gekommen ist. Und damit reicht mir sogar ein einziger Branch und ich erstelle NIE einen weiteren Branch. Wenn ich das bräuchte, könnte ich aber natürlich jederzeit einen Branch erstellen. Wenn ich auf Version 1.0 etwas machen wollte, dann könnte ich zum Tag der Version gehen und einen neuen Branch starten. Aber so lange wie das nicht vorkommt, belaste ich mich nicht damit.

Also: Ich mache nichts, wofür ich keinen Grund sehe! Siehst Du einen Grund für einen Branch? -> Dann mach einen bzw. bewerte den Grund und wiege den mit Risiken/Aufwand und so ab.

Vorteil von Branch per Feature/Task:

1. Haupt-Branch ist immer lauffähig, auch wenn das Feature nicht fertig ist
2. Der Done-Zustand eines Features ist explizit über den Merge in den Hauptbranch
3. Das Feature kann man mit kleinen Commits entwickeln, und das am Ende als einen einzigen Commit mergen (ohne die History des Haupt-Branches zu verändern)
4. Jeder Commit im FB kann im CI-System getestet werden
5. 2 & 3 führen potentiell zu bessere Doku, durch den expliziten Commit am Ende und einen expliziten Zeitpunkt für diesen

 

[OnDemand]

Danke. Wer einen Bug in einer alten Version findet, muss updaten. Also alte Versionen werden nicht supported in dem Sinne. Ich mache es eigentlich auch so, dass ich Issue für Issue abarbeite. (Alles in einem Release Branch)

Wenn ich dann doch mal einen Hotfix bringen muss, dann zweige ich aus dem Master einen Branch ab, baue das und gut. Branch per Feature ist doch etwas aufwändig für mich als Einzelkämpfer oder?

 

[kneitzel]

Vorteil von Branch per Feature/Task:

Das sind (gute) Gründe, aber diese muss man dennoch bewerten, in wie weit die wirklich etwas "wert" sind.

Wenn das "nur ein Entwickler" als dauerhafter Zustand gedacht ist und Dritte, die dazu kommen, zur Not "mit Waffengewalt" vertrieben werden, dann ist das unnötig.

Branch per Feature ist doch etwas aufwändig für mich als Einzelkämpfer oder?

Den Aufwand sehe ich nicht als Hauptaugenmerk. Es ist eine Frage der Gewöhnung. Ein Grund dafür kann auch sein: Übung. Später musst Du im Job vielleicht auch mergen und dann hast Du da schlicht Übung drin.

Die Gründe von @mrBrown sind gute Gründe. Es gibt auch gute Gründe mit Jenkins und Co in einem lokalen Cluster zu arbeiten. Da ist der Aufwand aber enorm (Hardware beschaffen, dann aufsetzen, Gluster Filesystem, Kubernetes, ... alles deployen, ..... => Diese Aufwände willst Du zuhause vermutlich nicht. Das nur als extremes Beispiel, wenn ich meine: Das muss man individuell bewerten.

Nur hier sind die Aufwände minimal. Aber die guten gründe ziehen auch minimal. Ja, wäre toll, wenn meine GitHub Repositories sauberer aussehen würden. Aber: Sorry: Da verirrt sich nie ein Schwein hin und wenn doch, dann fällt es vermutlich direkt tot um( und wird direkt zu Wurst verarbeitet ).

Ich sehe hier nicht, dass Du groß etwas gewinnst. Aber ich sehe auch nicht, dass Du groß mehr Aufwände haben wirst (Außer einmalig das Erarbeiten!)

==> Wenn Du das ggf. brauchst und vertiefen willst: Das wäre ein guter Grund, es zu machen.

Wie Du aber etwas erkennen konntest: Ich mache es nicht, bin zu faul. (Und brauche die Nebeneinkünfte von den Schlachtbetrieben, die meine Repositories als gute Möglichkeit zur Schlachtung angenommen haben)

 

[mrBrown]

Ich beschreib mal eben mein Vorgehen, sowohl in Einzel-Projekten als auch denen mit mehren Leuten:

• Es gibt einen Haupt-Branch, der ist immer aktuell und immer lauffähig
• Jedes Feature wird auf einem eigenen Branch entwickelt
  • Feature-Branch sind kurzlebig, wenige(!) Tage
  • Zwischenzeitliche Änderungen auf dem Haupt-Branch kommen immer über Rebase in den FB
  • Wenn ein Feature fertig ist (bei uns aktuell immer nach Review durch mindestens einen anderen, einmal zur Qualitätsicherung aber vor allem auch damit es nicht Teile gibt, die nur eine Person kennt), wird das zu einem sinnvollen Commit gesquasht
  • der Commit wird dann in den HB gemerged
• Produktion-Release gibts als
  • explizite Releases alle N-Sprints nach dem Sprint-Review, je nachdem was Stakeholder sagen, in dem Fall wird getaggt
  • automatischer Release bei jedem Commit auf dem HB (vor allem bei meinen Einzelprojekten)
  • Irgendwann, wenn ich Lust hab (auch bei meinen Einzelprojekten), dann auch mit Tag
  • Potentiell ist immer jeder Commit auf dem HB release-bar
• Hotfix wäre abzweigen vom aktuellem öffentlichen Stand (=Tag, und davon wird dann ein passender Branch aufgemacht), entwickelt wird der Fix wie in Feature, also extra Branch + Merge-Reuqest + Review, und bei Merge in den Release-Branch wird das deployed (hatten wir bisher aber noch nie, es reichte immer das Release zum Sprint-Ende)