Development / Pull Request Workflow

[jolt]

================================================== =======

Aktuelle Regeln / Guidelines:

1. Entwicklungen (egal ob Bugfix oder Feature) finden nur in einem Branch statt, nicht in develop direkt
2. Sobald die Entwicklung abgeschlossen ist (und nur dann) wird ein Pull Request (PR) geöffnet
3. Der PR muss über einen aussagekräftigen Titel verfügen
4. Der PR darf nur einen Bugfix oder ein Feature enthalten (aber natürlich aus einem oder mehreren Changes bestehen)
5. Der PR wird von einem anderen Projekt Teilnehmer gereviewt (4 Augen Prinzip)
6. Beim Review wird der Code inhaltlich unter die Lupe genommen
7. Jeder PR bekommt ein Label (z.B. Major Feature, Enhancement, Bug Fix) sowie eine Release Target Version (z.B. 1.0.0 [= nächstes Feature Release], 0.9.1 [= nächstes Bug Fix Release]) zugewiesen
8. Änderungen, die Einfluss auf die Optik haben, werden im Forum angekündigt und per Poll bewertet


History:

- 2015-11-07: Workflow bei Optik Änderungen ergänzt

================================================== =======




Ursprünglicher Post:


Hallo Zusammen,

um den Release Prozess zukünftig ein wenig zu vereinfachen, würde ich gerne folgenden Vorschlag zum Development / Pull Request Workflow machen:

1. Entwicklungen (egal ob Bugfix oder Feature) finden nur in einem Branch statt, nicht in develop direkt
2. Sobald die Entwicklung abgeschlossen ist (und nur dann) wird ein Pull Request (PR) geöffnet
3. Der PR muss über einen aussagekräftigen Titel verfügen
4. Der PR darf nur einen Bugfix oder ein Feature enthalten (aber natürlich aus einem oder mehreren Changes bestehen)
5. Der PR wird von einem anderen Projekt Teilnehmer gereviewt (4 Augen Prinzip)
6. Beim Review wird der Code inhaltlich unter die Lupe genommen
7. Jeder PR bekommt ein Label (z.B. Major Feature, Enhancement, Bug Fix) sowie eine Release Target Version (z.B. 1.0.0 [= nächstes Feature Release], 0.9.1 [= nächstes Bug Fix Release]) zugewiesen

In weiten Teilen wird der Prozess heute schon so gelebt. Ich betrachte diesen Vorschlag daher eher als Ergänzung / Dokumentation. Was will ich erreichen?

a) Alle haben das gleiche Verständnis des Entwicklungsprozesses
b) develop stabil halten
c) Kürzere Feature Release Zyklen (1-2 Monate)
d) Changelogs automatisch aus den PR Labels + Titeln erzeugen
e) CherryPicking für Bug Fix Release steuern

Meinungen?

Grüße,
Florian

[starwarsfan]

Hallo miteinander

1. Entwicklungen (egal ob Bugfix oder Feature) finden nur in einem Branch statt, nicht in develop direkt

Das würde ich gern noch etwas konkretisieren:

1. Entwicklungen (egal ob Bugfix oder Feature) finden jeweils in einem eigenen Branch statt, nicht in develop direkt

Das macht das ganze später bei der Integration in den develop einfacher.

2. Sobald die Entwicklung abgeschlossen ist (und nur dann) wird ein Pull Request (PR) geöffnet
3. Der PR muss über einen aussagekräftigen Titel verfügen
4. Der PR darf nur einen Bugfix oder ein Feature enthalten (aber natürlich aus einem oder mehreren Changes bestehen)
5. Der PR wird von einem anderen Projekt Teilnehmer gereviewt (4 Augen Prinzip)
6. Beim Review wird der Code inhaltlich unter die Lupe genommen

Ich bin ganz bei Dir, m.M.n. gibts daran nichts auszusetzen.

7. Jeder PR bekommt ein Label (z.B. Major Feature, Enhancement, Bug Fix) sowie eine Release Target Version (z.B. 1.0.0 [= nächstes Feature Release], 0.9.1 [= nächstes Bug Fix Release]) zugewiesen

Hier wird's sicher etwas konkreteren Handlungsbedarf geben denn das mit den Labels kann auch unübersichtlich werden. Allerdings glaube ich eher nicht, dass das hier in diesem Fall ein grösseres Problem wird. Solange wir keine drei- oder vierstelligen Entwickler- resp. Committerzahlen haben, sollten wir das recht gut handhaben können.

In weiten Teilen wird der Prozess heute schon so gelebt. Ich betrachte diesen Vorschlag daher eher als Ergänzung / Dokumentation. Was will ich erreichen?

a) Alle haben das gleiche Verständnis des Entwicklungsprozesses
b) develop stabil halten
c) Kürzere Feature Release Zyklen (1-2 Monate)
d) Changelogs automatisch aus den PR Labels + Titeln erzeugen
e) CherryPicking für Bug Fix Release steuern

Meinungen?

+1 von mir.

[tuxedo]

+1 auch von mir (auch wenn ich noch nichts aktiv zur CV beigetragen habe)

[peuter]

Gerade weil meine Git-Erfahrung noch nicht allzu umfangreich ist, möchte ich hier mal kurz einhaken.

Momentan ist das so (und wird sicherlich auch so bleiben), dass jeder auf seinem eigenen Fork entwickelt/branched/commited und wenn er dann meint das er fertig ist einen Pull Request auf den Development Branch stellt. Lokal in seinem Fork kann er doch branchen wie er möchte und ggf. auch auf seinem Development-Branch arbeiten, oder sehe ich das falsch?

Zweite Sache: Ich würde vorschlagen das v.a. Features aber auch Bugfixes vor dem Merge auf einen Commit reduziert werden um die Commit-History ein wenig cleaner zu halten, v.a. wenn man daraus automatisch für einen Release Changelogs generieren möchte. Mann kann ja während der Entwicklung beliebig viele commits machen und auch seinen Pull Request mit mehreren Commits stellen, da ja durch eine Code Review eventuell noch neue Commits nötig werden. Aber wenn der Pull Request dann soweit "ready-to-merge" ist sollte man die Commits squashen so dass nur noch einer übrig bleibt, und erst danach sollte der Pull Request gemerged werden. Was meint Ihr dazu?

[jolt]

peuter: Ja im Fork kann nach Lust und Laune gewerkelt werden. Schnittstelle ist nur der Pull Request.

Commit squashing ist aus meiner Sicht nicht nötig. Ich würde versuchen die Release Changelogs aus den Pull Requests zu erzeugen. Das ist ja im wesentlichen ein gesquashter Commit. Deswegen ist es auch wichtig dass alles über Pull Requests läuft (-> #2 meiner Liste), diese einen aussagekräftigen Titel (-> #3 meiner Liste)
haben und nur ein Feature / Bugfix pro PR enthalten ist (-> #4 meiner Liste)

[jolt]

Das würde ich gern noch etwas konkretisieren:

1. Entwicklungen (egal ob Bugfix oder Feature) finden jeweils in einem eigenen Branch statt, nicht in develop direkt

Das macht das ganze später bei der Integration in den develop einfacher.

Richtig. Wobei ich das vermutlich falsch formuliert habe. Aus meiner Sicht sollte rein gar nichts im CometVisu Repository entwickelt werden. Auch nicht in einem Branch. Alles passiert innerhalb von Forks und wird dann über einen Pull Request in das CometVisu Repository in den develop Branch zurück geführt.

Bisher habe ich mehrere Pull Request immer aus dem gleichen Branch meines Forks gestartet. Ohne das es für mich erkennbar zu Problemen gekommen wäre. Gilt deine Aussage auch in diesem Fall? Falls ja, dann würde ich meine Liste entsprechend anpassen.

[starwarsfan]

Hallo miteinander,

das mit dem Commit squashing ist immer so eine Sache, geht schon fast in Richtung "Glaubensfrage". Ich bin eher an der History interessiert und will sehen, wie sich etwas entwickelt hat. Von daher wäre ich eher gegen eine Zusammenfassung der Commits vor dem Merge.

[Chris M.]

Wir haben jetzt zwei Threads mit ziemlich gleichem Thema. Ich mach mal hier weiter, da die Überschrift besser azu passt

1. - 6. ist exakt so umgesetzt.

1. alleine schon dadurch, dass zur Zeit nur drei Leute Schreibzugriff auf's Repository haben (peuter und ich so wie Makki als neutrale Backup und Not-Instanz; weitere Leute wären grundsätzlich möglich und denkbar - einfach durch gute Pull Requests qualifizieren ).
Mit Tobias/peuter ist auch vereinbart, dass wir unsere Pull-Requests nicht selber mergen sondern Reviewen (5.)

7. können wir gerne auch machen, wobei die Commit-Frequenz gering genug ist, dass ich hier noch keinen großen Vorteil sehe.

Was wir als Workflow in der Vergangenheit definiert hatten steht ja unter https://github.com/CometVisu/CometVi...pment-workflow

=> Bei den ganzen Vorschlägen die hier und im anderen Thread gekommen sind: wo weichen die ab? Was müsste wo konkretisiert werden?

[Chris M.]

Jetzt in diesem Thread nochmal die konkrete Frage wie wir die Versionen bzw. Branches im Rahmen eines Release-Prozesses handhaben wollen/sollen.

Konkret haben wir immer:

• master - eine Version die immer funktioniert und quasi den gleichen Stand wie das letzte Release hat
• develop - wo alles aktuelle rein kommt
• feature branches - nur theoretisch, praktisch arbeitet jeder in seinem Fork und sendet einen Pull-Request.

Kommt nun ein Release, so hatte ich https://github.com/CometVisu/CometVi...pment-workflow bzw. http://nvie.com/posts/a-successful-git-branching-model/ so verstanden, dass von develop ein Branch mit dem Namen release-0.8.15 erzeugt wird.

Nun fangen meine Fragen zum prakischen Vorgehen an:

• Ein neuer Pull Request für ein neues Feature geht nun nach develop, richtig?
• Ein neuer Pull Request für ein Bug-Fix geht nach develop oder nach release-0.8.15? Wie wird sicher gestellt, dass der in beiden Branches ankommt?
• Wie kommt man vom Release-Branch (also release-0.8.15) zu einer konkreten Ausleitung wie release-0.8.15-RC2?
• Automatische Code-Änderungen im Rahmen des Release-Prozesses gehen nach release-0.8.15 oder nach einen neuen Branch release-0.8.15-RC2?
  (Ich meine hier so Dinge wie den Austauch des Textes in den Versionsdateien von "Git" zu "0.8.15" oder dem ganzen Minimizing/Uglifying)
• Dem Branch release-0.8.15-RC2 wird dann ein Tag gegeben und der Branch gelöscht, sobald der veröffentlich wurde, oder?
• Ganz am Schluss wird release-0.8.15 sowohl nach master als auch nach develop gemerged, nicht?

[starwarsfan]

Moinmoin miteinander

Konkret haben wir immer:

• master - eine Version die immer funktioniert und quasi den gleichen Stand wie das letzte Release hat
• develop - wo alles aktuelle rein kommt
• feature branches - nur theoretisch, praktisch arbeitet jeder in seinem Fork und sendet einen Pull-Request.

Jo, das ist soweit ok. Der Branch master entspricht damit weitestgehend dem Release-Branch

Kommt nun ein Release, so hatte ich https://github.com/CometVisu/CometVi...pment-workflow bzw. http://nvie.com/posts/a-successful-git-branching-model/ so verstanden, dass von develop ein Branch mit dem Namen release-0.8.15 erzeugt wird.

So ist es.

Nun fangen meine Fragen zum prakischen Vorgehen an:[*]Ein neuer Pull Request für ein neues Feature geht nun nach develop, richtig?

Richtig.

[*]Ein neuer Pull Request für ein Bug-Fix geht nach develop oder nach release-0.8.15? Wie wird sicher gestellt, dass der in beiden Branches ankommt?

Ein Bugfix muss schlussendlich sowohl auf dem Release-Branch als auch im develop (für den nächsten Release) ankommen. Dafür gibt es nun mehrere Vorgehensweisen, je nachdem, wie invasiv der Change innerhalb des Bugfix ist bzw. welchen Zustand der develop mitlerweile hat. Es kann ja sein, dass das Problem auf dem develop bereits durch andere Umbauten eliminiert wurde.

Eine Variante ist, den Bugfix Pull Request auf den Release-Branch zu mergen und dann einen weiteren Pull Request zu machen, welcher vom Release-Branch zurück auf den develop geht. Wurde das gesamte Branching und die Handhabung der Pull's sauber gemacht, ist das überhaupt kein Problem und es kommen nur die Changes des Bugfix zurück auf den develop.

Die andere Variante ist, einfach zwei Pull Requests zu machen, einmal auf den Release-Branch und einmal auf den develop. Beides kommt schlussendlich aufs gleiche Resultat raus.

[*]Wie kommt man vom Release-Branch (also release-0.8.15) zu einer konkreten Ausleitung wie release-0.8.15-RC2?

Der Release wird einfach gebaut (was auch immer dazu bei de CV notwendig ist). Im Anschluss daran wird dieser Stand mit einem Tag versehen, eben release-0.8.15-RC2 um bei Deinem Beispiel zu bleiben. Wird das Modell von http://nvie.com/posts/a-successful-git-branching-model/ angewendet, wird der Stand des Release-Branch zuvor in den master gemerget und das Tag dann dort angelegt. Somit sind auf dem master nur die veröffentlichten Releases, jeweils mit einem Tag.

Hier gibt es immer wieder mal Diskussionen, denn die Versionen auf dem master entsprechen immer einem Release und damit könnte man sich die Tags auch sparen. Aber sie tun auch keinem weh und zeigen direkt auf die echten Releases, womit sich die Übersichtlichkeit verbessert.

[*]Automatische Code-Änderungen im Rahmen des Release-Prozesses gehen nach release-0.8.15 oder nach einen neuen Branch release-0.8.15-RC2?
(Ich meine hier so Dinge wie den Austauch des Textes in den Versionsdateien von "Git" zu "0.8.15" oder dem ganzen Minimizing/Uglifying)

Änderungen während dem Release-Prozess geschehen auf dem Release-Branch release-0.8.15. Dafür ist er da: Dort werden nur die Changes gemacht, welche für den Release-Build notwendig sind. Schlussendlich führt das zu einem Stand, welcher exakt dem Release-Stand entspricht.

[*]Dem Branch release-0.8.15-RC2 wird dann ein Tag gegeben und der Branch gelöscht, sobald der veröffentlich wurde, oder?

Es gibt keinen Branch release-0.8.15-RC2! Es gibt den Branch release-0.8.15 und der Stand dort drin ist das Release 0.8.15-RC2. Dieser Stand wird dann nach master gemerged und getagt, wie oben schon geschrieben.

[*]Ganz am Schluss wird release-0.8.15 sowohl nach master als auch nach develop gemerged, nicht?

So ist es. Wobei der Merge nach Develop ein Sonderfall ist. Wenn alles korrekt gemerged wurde, sollten dabei keine Code-Changes kommen sondern lediglich die Anpassungen "drumrum", also Release-Notes bspw. oder Versionseinträge. Von daher könnte der Merge in den develop auch entfallen, je nachdem, was auf dem Release-Branch in [T|D]aten und Wahrheit gemacht gemacht wurde.

Mir hat es zu Anfangs immer geholfen, den Workflow mit Papier und Bleistift zu zeichnen. Also senkrechte Linien für develop, bugfix, feature und master und dann den Weg der Changes resp. Pull's einzeichnen. Dabei sollte sich dann mehr und mehr das Bild aus der referenzierten Workflow-Beschreibung abzeichnen.

[jolt]

+1 sowie zwei Ergänzungen:

Kommt nun ein Release, so hatte ich https://github.com/CometVisu/CometVi...pment-workflow bzw. http://nvie.com/posts/a-successful-git-branching-model/ so verstanden, dass von develop ein Branch mit dem Namen release-0.8.15 erzeugt wird.

Wobei der Branch nicht zwingend aus develop erzeugt werden muss. Wenn du z.B. ein Bug Fix Release machen möchtest, ist es in der Regel besser vom letzten stabilen Release zu branchen. In diesem Fall dann von release-0.8.14.

[*]Automatische Code-Änderungen im Rahmen des Release-Prozesses gehen nach release-0.8.15 oder nach einen neuen Branch release-0.8.15-RC2?
(Ich meine hier so Dinge wie den Austauch des Textes in den Versionsdateien von "Git" zu "0.8.15" oder dem ganzen Minimizing/Uglifying)

Das ganze Minimizing/Uglifying ist aus meiner Sicht ein Build Artefakt, dass überhaupt nicht im VCS auftauchen sollte. Versionsnummer würde ich analog nur im Zuge des Release Prozesses ändern und nicht einchecken. Wenn das Changelog dann noch im Wiki geführt wird, braucht es überhaupt keine Release spezifischen Änderungen mehr oder? Das würde ich versuchen anzustreben.

[Chris M.]

Das ganze Minimizing/Uglifying ist aus meiner Sicht ein Build Artefakt, dass überhaupt nicht im VCS auftauchen sollte. Versionsnummer würde ich analog nur im Zuge des Release Prozesses ändern und nicht einchecken. Wenn das Changelog dann noch im Wiki geführt wird, braucht es überhaupt keine Release spezifischen Änderungen mehr oder? Das würde ich versuchen anzustreben.

Jetzt grüble ich schon eine ganze Weile über diesen Punkt.

Das die Artefakte nicht in's VCS sollen ist eigentlich klar.

Nur sind die Versionsnummern + Minimized-Dateien kein klassisches Artefakt (im sinne temporärer Dateien) sondern das finale Ziel der ganzen Aktivitäten. Und wenn man nun sagt, dass master dem letzten Release entsprechen soll - so dass man per simplem "git fetch" aktuell bleiben kann - dann würde ja das entscheidende fehlen, nicht?

Oder sollte nur develop per fetch aktuallisierbar bleiben?
Aber wie könnten wir dann das Minimizing in der Breite testen lassen?

[jolt]

Ich denke nicht, dass etwas fehlt wenn man per git fetch aktuell bleibt oder? Die Versionsnummer steht auf "git" oder "git-r4711" und der Source ist nicht Minimized, das Verhalten ist jedoch 100% identisch zu einem Release auf gleichem Stand. Zumindest sollte es dass.

Das finale Ziel würde ich nicht in einem VCS sehen. Du checkst ja auch keine Binärdateien ein. Weder die Object Files noch das finale Executable. Zumindest nicht in das VCS, in dem auch der Source liegt.

Testen in der Breite würde ich schlicht über Release Candidates oder gerne auch Nightly Builds. Es wäre daher viel wichtiger alles im VCS zu haben, was nötig ist, einen Release Stand zu erzeugen. Auch Build Scripte etc. Wer also wirklich up2date sein will, ruft einfach "git fetch" und "build_release.sh" auf. Wobei letzteres aus meiner Sicht optional ist.

[jolt]

=> Bei den ganzen Vorschlägen die hier und im anderen Thread gekommen sind: wo weichen die ab? Was müsste wo konkretisiert werden?

1. Passt
2. Niedergeschrieben ist es nicht, ich meine auch das ich beim Erstellen der Changelogs diverse unfertige Baustellen in develop gesehen habe. Z.B. der textify Umbau, ist aber nur ein Bauchgefühl, will hier niemanden etwas unterstellen! Wichtig ist hier im Ergebnis das nur fertige Dinge gemerged werden. Wenn man auf Arbeit / Fixes von anderen angewiesen ist, kann man problemlos auch von einem Feature Branch in einen anderen Feature Branch mergen (auch mehrfach wechselseitig) und das Ergebnis dann trotzdem automatisch nach develop per PR überführen.
3. Niedergeschrieben ist es nicht, Beispiel: PR #201 Titel: "Text allow class". Jetzt kommt jemand und liest diese Info im Changelog unter "Enhancements". Kann der sich dann vorstellen was damit gemeint ist? Der Commit im gleichen PR hat übrigens als Text "allow custom class definition for text item". Ich behaupte einfach mal das sich deutlich mehr Leute etwas darunter vorstellen können als unter dem PR Titel.
4. Niedergeschrieben ist es nicht, in der Praxis wird das aber (jetzt) so gelebt. In den anfänglichen Git Zeit nicht, aber das ist Transition Schmerz
5. Niedergeschrieben ist es nicht, Praxis passt.
6. Niedergeschrieben ist es nicht, Praxis passt.

7. Zwingt einen auf jeden Fall sich Gedanken zu machen wie kritisch der PR ist. Ob das noch in ein Stable Release kann oder auf das nächste Feature Update warten muss. Ggf muss der Fix auch in develop und einen Release Branch. Und es hilft die Changelogs automatisch zu erstellen.

[Chris M.]

So, mein Release-Script funktioniert erst mal so wie es soll. D.h. ich würde nun gerne die RC1 bauen - und vorher die offensichtlich passenden Bugfixes mergen. Da scheitere ich aber aktuell.

Beispiel: https://github.com/CometVisu/CometVisu/pull/206 ist eigentlich nur eine Zeile in einer Datei. Aber irgendwie bin ich zu doof das in den anderen Branch zu mergen. Da kommen immer eine ganze Latte mehr Dateien. Der Compare von GitHub (https://github.com/CometVisu/CometVi...derpositionfix ) zeigt genau das Problem.

Bzw. das "Problem" wird sein, dass der Pull-Request auf eine neuere Version von develop aufsetzt. Da ja develop für neue Entwicklungen frei ist (der Feature Freeze ist ja in release-0.9.0) wäre zu wünschen, dass das kein Problem darstellt.

=> Wie kann ich das lösen?

Und wie komme ich an bereit gemergte Bugfixes in develop um die noch nach release-0.9.0 zu bekommen?