Der Trend der Entwicklungsbranche verschwindet

82

Mir ist in letzter Zeit aufgefallen, dass es bei einigen beliebten Projekten auf GitHub keine developFiliale gibt. Tatsächlich erwähnt der GitHub Flow Guide dies auch nicht. Nach meinem Verständnis mastersollte immer absolut stabil sein und die Produktion widerspiegeln. Wenn Entwickler an Feature-Zweigen arbeiten und diese anschließend zusammenführen master, bedeutet dies, dass in einem bestimmten Zeitraum Features / Fixes zusammengeführt werden masterund der masterZweig tatsächlich neuer als die Produktion ist.

Wäre es nicht sinnvoller, wenn das Team Feature- / Fix-Verzweigungen erstellt develop, diese wieder zusammenführt und dann, wenn die nächste Version vollständig zur Veröffentlichung bereit developist, zusammengeführt masterund ein Tag erstellt wird? Stellen Sie sich vor, die Leute gehen direkt ineinander über masterund es wird ein Fehler in der Produktion gemeldet, der sich nur schwer beheben lässt, weil sich die masterCodebasis der Zweige erheblich geändert hat. Dann müssen die Entwickler den Benutzer lediglich auffordern, bis zur nächsten Version zu warten, damit das Problem behoben wird.

EDIT: Diese Frage ist anders als "zu verzweigen oder nicht zu verzweigen." Es richtet sich speziell an Personen, die nicht mehr auf den Entwicklungszweig zurückgreifen, und an die Gründe dafür, da dies lange Zeit als Best Practice angepriesen wurde.

git github ffxsam
quelle
11
Es gibt viele mögliche Workflows, die git ermöglicht. Es sollte nicht erwartet werden, dass Gitflow oder Github Flow für alle Projekte verwendet werden.
Sehr interessante Frage. Ich habe jahrelang mit dem nvie.com/posts/a-successful-git-branching-model gearbeitet und ich muss sagen, dass es mir gefällt. Am besten gefällt mir, dass a) Master das ist, was in Produktion ist und das gilt auch für Versionen und b) es einen klaren Unterschied zwischen einem Hotfix und einem Feature gibt, sie werden auf Master initiiert und zusammengeführt bzw. entwickelt. Nachdem ich dieser Diskussion gefolgt bin, habe ich jedoch Zweifel, ob es zu kompliziert ist. Irgendwelche Meinungen dazu?
Aspasia
1
Ich hasse das Konzept, dass Master eine Aufzeichnung dessen ist, was in der Produktion ist. Wenn wir wissen müssen, was sich in der Produktion befindet, sollten wir nur die Produktion abfragen und uns nicht darauf verlassen, dass der Master genau widerspiegelt, was sich in der Produktion befindet.
Jim V

Antworten:

52

Es kommt aus der CI- Denkweise, bei der mehrmals täglich eine Integration stattfindet.

Es gibt Vor- und Nachteile von beiden.

In unserem Team haben wir auch die Entwicklungsbranche aufgegeben, da wir der Ansicht waren, dass sie keinen zusätzlichen Nutzen mit ein paar Nachteilen bringt. Wir haben unsere CI-Software (Teamcity) so konfiguriert, dass die folgenden Nachteile behoben werden:

  1. Aktivieren Sie die Bereitstellung eines bestimmten Commits. Mit anderen Worten: Wir stellen keine Filiale bereit. Wir setzen ein Commit ein.
  2. Wir können entweder Master oder Zweige bereitstellen, die mit einem Hotfix / Präfix beginnen.

Der Grund dafür ist, dass alle Pull-Anforderungen möglicherweise freigebbaren Code enthalten. Dies bedeutet jedoch nicht, dass wir alle Commits in master bereitstellen.

Der Hauptgrund, warum wir den Entwicklungszweig aufgegeben haben, ist, dass er zu groß und zu zeitaufwendig wurde, um zu sehen, was er tatsächlich enthielt. Wenn wir etwas vorzeitig bereitgestellt haben, verzweigen wir einfach einen Hotfix-Zweig und stellen ihn direkt bereit.

Esben Skov Pedersen
quelle
10
Nachdem ich ein oder zwei Jahre mit einem Entwicklungszweig zusammengearbeitet habe, um ihn dann und
wann
Interessant. Ich gehe also davon aus, dass Sie bei der Veröffentlichung von Version 1.3 beispielsweise ein bestimmtes Commit für taggen master, sodass Sie, wenn später ein Fehler auftritt, der mastersich im Fluss befindet, problemlos einen Hotfix vom 1.3-Tag abzweigen können.
ffxsam
5
Ich würde sagen, der Nutzen von "Entwickeln" hängt stark davon ab, welche Art von Software Sie erstellen, wie sie bereitgestellt wird und ob Sie mehrere Live-Versionen unterstützen müssen oder nicht.
Axl
1
@ffxsam wir brauchen nicht einmal taggen, da wir verfolgen, welche git-id gerade implementiert ist. Dies wird sowohl in TeamCity als auch in bereitgestellten DLLs und im Azure-Verwaltungsportal protokolliert. Daher haben wir keine Notwendigkeit für ein weiteres Tagging verspürt, es sei denn, das automatische Tagging wird von TeamCity durchgeführt. Wenn Sie das Gefühl haben, dass das Taggen besser zu Ihrem Arbeitsablauf passt, kann es auch gut gelöst werden. Aber ja, im Prinzip verzweigen Sie direkt von der aktuell bereitgestellten Änderung, um eine Hotfix-Verzweigung zu erstellen.
Esben Skov Pedersen
25

Ein Entwicklungszweig ist wichtiger, wenn Ihr Release-Prozess komplex ist und Sie ernsthafte Release-Kandidaten benötigen.

Stellen Sie sich zum Beispiel vor, Sie schreiben Software, die Firmware für Autos ist. Dies ist nicht trivial zu beheben und es ist wahrscheinlich, dass in jedem Release eine umfassende Reihe von Nicht-CI- / Integrationstests auf echter Hardware ausgeführt wird.

In diesem Fall ist es möglicherweise sinnvoller, einen "Release Candidate" in einem Nicht-Master-Zweig (z. B. "Develop") zu isolieren. Dies ermöglicht Ihrem Team, das diese Tests durchführt, eine Verzweigung, in der Features zusammengeführt werden können.

Webapps oder andere leicht zu aktualisierende Software unterliegen dieser Einschränkung nicht.

Beachten Sie jedoch Folgendes:

  • Viele (die meisten?) Projekte auf Github haben diese Einschränkung nicht
  • Ein Haupt- "Master" dient demselben Zweck
  • Ein Workflow von "Make a PR vs Master" ist weitaus universeller als "Make a PR gegen einen Zweig, den Sie in diesem Repo nicht sofort kennen".
Enderland
quelle
18

Es gibt zwei Philosophien, die ich in Projekten gesehen habe, und ich denke, die Wahl ist nur eine Frage des Geschmacks:

  1. Bestimmen Sie "master" als Produktions-Release und entwickeln Sie in einem "Develop" -Zweig.

  2. Entwickeln Sie sich in 'master' und haben Sie einen Zweig mit einem anderen Namen für stabile Produktionsfreigaben. Dies ist umso sinnvoller, wenn Ihr Projekt gleichzeitig über mehrere Release-Zweige verfügt (z. B. das derzeit bevorzugte Release ist Release 1.8, Sie behalten jedoch weiterhin Release 1.7 bei).

Beides sind gemeinsame Ansätze und haben Vor- und Nachteile.

Larry Gritz
quelle
Ich stimme mit Ihnen ein. Wir bevorzugen Release-Zweige und pflegen diese bis zur nächsten Produktionsfreigabe. Wenn wir
Johnny,
Genau. Was "Meister" tun sollte, ist hauptsächlich Semantik. Das Grundlegende, was Sie tun müssen, ist zu vermeiden, dass mehrere Zweige, die für immer existieren, bidirektional synchronisiert werden müssen, es sei denn, Sie haben einen guten Grund dafür. Der 'master'-Zweig in Git Flow ist nur eine verzögerte Kopie von' develop ', es zählt also nicht wirklich. Die Anti-Pattern-Funktion ermöglicht es dem Hauptentwicklungszweig, Änderungen vorzunehmen, die nie in eine Veröffentlichung einfließen. Dies ist eine schockierend häufige Praxis, die ich gesehen habe. Beide oben genannten Modelle verhindern dies, weshalb sie funktionieren.
John Michelau
7

Produktionsfreigaben können mit Tags versehen werden, sodass die freigegebene Situation jederzeit reproduziert werden kann, ohne dass eine ganze Filiale für diesen Zweck reserviert wird.

Wenn ein kritischer Fehler in der Produktion zu einem Zeitpunkt festgestellt wird, an dem der Master nicht freigegeben werden kann, ist es einfach genug, das Tag zu überprüfen und von dort aus einen neuen "Hotfixes-für-Release-1.2.0" -Zweig zu starten. Das dürfte aber eher selten sein.

Die meiste Zeit in unseren Webanwendungen hat sich der Master seit der letzten Version geändert, jedoch nicht wesentlich. Daher können wir einfach eine neue Version von Master erstellen, die den Fix enthält. Es hilft sowieso, sehr häufig Releases zu machen.

RemcoGerlich
quelle
5

Wenn Entwickler an Feature-Zweigen arbeiten und diese nach Abschluss des Vorgangs zum Master zusammenführen, bedeutet dies, dass in einem bestimmten Zeitraum Features / Fixes zusammengeführt werden masterund der masterZweig tatsächlich neuer als die Produktion ist.

...

Stellen Sie sich vor, die Benutzer fusionieren direkt zum Master und es wird ein Fehler in der Produktion gemeldet, der sich nur schwer beheben lässt, da sich die Codebasis des Master-Zweigs erheblich geändert hat.

Das ist kein Github Flow.

Dies ist der Bereitstellungs- / Zusammenführungsprozess von Github Flow gemäß Ihrem Link:

Bereitstellen

Sobald Ihre Pull-Anforderung überprüft wurde und die Zweigstelle Ihre Tests bestanden hat, können Sie Ihre Änderungen bereitstellen, um sie in der Produktion zu überprüfen. Wenn Ihr Zweig Probleme verursacht, können Sie ihn zurücksetzen, indem Sie den vorhandenen Master in der Produktion bereitstellen.

Verschmelzen

Nachdem Ihre Änderungen in der Produktion überprüft wurden, ist es an der Zeit, Ihren Code in der Hauptniederlassung zusammenzuführen.

(Betonung meiner)

Mit anderen Worten, masterwird nie vor der Produktion sein. In ähnlicher Weise ist er master(abgesehen von unentdeckten Fehlern) immer in einem stabilen, freigebbaren Zustand, da alles überprüft, getestet und für die Produktion bereitgestellt wird, bevor es mit dem Server zusammengeführt wird master.

8bittree
quelle
Nett! Dies ist sehr intuitiv zu verstehen - es masterist immer Ihre Rollback-Position, wenn der Feature-Zweig, den Sie in die Produktion verschieben, ausfällt. Wenn dies nicht der Fall ist, wird es masterzum neuen Fallback. Ich mag das.
Bill Horvath
1

Das Problem, das ich sehe, ist, dass Git / Hub-Flow-Bereitstellung / Zusammenführung davon ausgeht, dass eine Funktion gleichzeitig entwickelt / getestet / zusammengeführt / bereitgestellt wird - und meiner Erfahrung nach ist dies häufig nicht der Fall. Wenn wir jeweils ein Feature zusammenführen, besteht eine größere Wahrscheinlichkeit für Regressionsprobleme. Diese treten erst auf, nachdem die Features zum Master zusammengeführt wurden und möglicherweise in der Produktion sind.

Es muss eine Möglichkeit geben, mehrere Funktionen zu testen, mehrere Funktionen zusammenzuführen und dieselbe bereitzustellen. Ich habe einen 'Bundle Branch' (einen Branch, der aus einem Master mit darin zusammengeführten Test Ready Feature Branches erstellt wurde) verwendet, der in qa / uat implementiert wird. Korrekturen während des UAT werden nur für den Feature-Zweig durchgeführt, und diese werden wieder in den Bundle-Zweig eingefügt. Nachdem ein Unterabschnitt des Bundle-Zweigs genehmigt wurde, werden nur die genehmigten Features im Bundle vom Master angefordert - und der Zyklus wird fortgesetzt.

Ich verwende dies mit Gitflow, denke aber darüber nach, es für GitHub Flow zu verwenden. Die QA / UAT-Funktion für viele Funktionen zu einem bestimmten Zeitpunkt scheint von Bedeutung zu sein. Ein weiteres Problem mit GitHub Flow ist, dass alle sr-Entwickler davon ausgehen, und das ist nicht immer der Fall.

Ich würde den GitHub-Flow aufgrund seiner Vereinfachung eher verwenden. Ich denke, mit einem Bundle-ähnlichen Feature wäre es besser, bereit zu sein. Möglicherweise ähnelt das Bundle dem Release. Ich denke aber auch noch darüber nach.

Ein weiteres Problem ist, dass der Pull-Request-Prozess am Ende vor dem Zusammenführen zum Master stattfindet. Manchmal möchten Sie jedoch eine Codeüberprüfung vor dem Testen der Geschäftsqualität durchführen - also lange vor dem Zusammenführen

David Latty
quelle