it-swarm.com.de

Der Trend der Branche "Entwickeln" verschwindet

Ich habe in letzter Zeit bei einigen beliebten Projekten auf GitHub etwas bemerkt, dass es keinen develop Zweig gibt. Und tatsächlich wird es im GitHub Flow Guide auch nicht erwähnt. Nach meinem Verständnis sollte master immer absolut stabil sein und die Produktion widerspiegeln. Wenn Entwickler an Feature-Zweigen arbeiten und diese dann zu master zusammenführen, bedeutet dies, dass Features/Fixes in einem bestimmten Zeitraum zu master und dem zusammengeführt werden Der Zweig master ist tatsächlich neuer als die Produktion.

Wäre es nicht sinnvoller, wenn das Team Feature-/Fix-Zweige aus develop erstellt, wieder zusammenführt und dann, wenn die nächste Version vollständig zur Veröffentlichung bereit ist, develop wird in master zusammengeführt und ein Tag erstellt? Stellen Sie sich vor, die Leute verschmelzen direkt zu master und es wird ein Fehler in der Produktion gemeldet, der schwer zu beheben ist, da sich die Codebasis des master-Zweigs erheblich geändert hat. Dann müssen die Entwickler den Benutzer nur anweisen, bis zur nächsten Version zu warten, um zu sehen, ob das Problem behoben ist.

EDIT: Diese Frage unterscheidet sich von "verzweigen oder nicht verzweigen". Es richtet sich speziell an Personen, die sich von der Nutzung des Entwicklungszweigs entfernen, und an die Gründe dafür, da dies lange Zeit als Best Practice angepriesen wurde.

97
ffxsam

Es kommt aus der Denkweise CI , in der mehrmals am Tag integriert wird.

Beides hat Vor- und Nachteile.

In unserem Team haben wir auch die Entwicklungsbranche aufgegeben, da wir der Meinung waren, dass dies keinen zusätzlichen Nutzen, sondern nur einige Nachteile bietet. Wir haben unsere CI-Software (Teamcity) so konfiguriert, dass die Nachteile ausgeglichen werden:

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

Der Grund dafür ist, dass alle Pull-Anforderungen potenziell freisetzbaren Code enthalten. Dies bedeutet jedoch nicht, dass wir alle Commits im Master bereitstellen.

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

57

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 jeder Version ein umfassender Satz von Nicht-CI/Integrationstests auf realer Hardware ausgeführt wird.

In diesem Fall kann es sinnvoller sein, einen "Release Candidate" in einem Nicht-Master-Zweig zu isolieren (z. B. "Entwickeln"). Auf diese Weise kann Ihr Team, das diese Tests ausführt, über einen Zweig verfügen, in dem Features zusammengeführt werden können.

Webapps oder andere leicht aktualisierbare 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 dem gleichen Zweck
  • Ein Workflow von "PR gegen Master machen" ist weitaus universeller als "PR gegen einen Zweig machen, den Sie in diesem Repo nicht sofort kennen".
27
enderland

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 Produktionsfreigabe und entwickeln Sie in einem "Entwicklungs" -Zweig.

  2. Entwickeln Sie sich in 'master' und haben Sie einen anders benannten Zweig für stabile Produktionsversionen. Dies ist noch sinnvoller, wenn Ihr Projekt mehrere Release-Zweige gleichzeitig hat (z. B. ist der derzeit bevorzugte Release-1.8, Sie behalten jedoch weiterhin Release-1.7 bei).

Beide sind gängige Ansätze und haben ihre Vor- und Nachteile.

21
Larry Gritz

Produktionsfreigaben können markiert werden, sodass die freigegebene Situation immer reproduziert werden kann, ohne dass ein ganzer Zweig für diesen Zweck vorgesehen ist.

Wenn in der Produktion ein kritischer Fehler zu einem Zeitpunkt gefunden wird, an dem der Master nicht freigegeben werden kann, ist es einfach genug, das Tag auszuchecken und von dort aus einen neuen Zweig "hotfixes-for-release-1.2.0" zu starten. Das sollte aber eher selten sein.

In unseren Webanwendungen hat sich der Master die meiste Zeit seit der letzten Version geändert, jedoch nicht wesentlich. Daher können wir einfach eine neue Version vom Master erstellen, die das Update enthält. Es hilft sowieso, sehr häufige Veröffentlichungen zu machen.

7
RemcoGerlich

Wenn Entwickler an Feature-Zweigen arbeiten und diese dann in Master zusammenführen, wenn sie fertig sind, bedeutet dies, dass Features/Fixes in einem bestimmten Zeitraum in master zusammengeführt werden und der master-Zweig tatsächlich neuer als die Produktion ist.

...

Stellen Sie sich vor, die Leute verschmelzen direkt mit dem Master, und in der Produktion wird ein Fehler gemeldet, der schwer zu beheben ist, da sich die Codebasis des Master-Zweigs erheblich geändert hat.

Das ist nicht Github Flow.

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

Bereitstellen

Sobald Ihre Pull-Anforderung überprüft wurde und der Zweig 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.

(Hervorhebung von mir)

Mit anderen Worten, master wird der Produktion niemals voraus sein. In ähnlicher Weise befindet sich master immer in einem stabilen, freisetzbaren Zustand (abgesehen von unentdeckten Fehlern), da alles überprüft, getestet und für die Produktion bereitgestellt wird vorher und mit master zusammengeführt wird.

5
8bittree

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

Es muss eine Möglichkeit geben, mehrere Funktionen zu testen, mehrere Funktionen zusammenzuführen und dieselben bereitzustellen. Ich habe einen 'Bundle-Zweig' verwendet (einen Zweig, der aus dem Master mit testfertigen Feature-Zweigen erstellt wurde), der für qa/uat bereitgestellt wird. Korrekturen während der UAT werden nur für den Feature-Zweig ausgeführt, und diese werden erneut mit dem Bundle-Zweig zusammengeführt. Nachdem ein Unterabschnitt des Bundle-Zweigs genehmigt wurde, werden nur die genehmigten Features innerhalb des Bundles zum Master angefordert - und der Zyklus ist kontinuierlich.

Ich benutze 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 wegen seiner Vereinfachung lieber verwenden. Mit einer Bundle-ähnlichen Funktion wäre es meiner Meinung nach besser bereit. Möglicherweise ähnelt das Bundle der Veröffentlichung. Ich denke aber auch immer noch darüber nach.

Ein weiteres Problem ist, dass der Pull-Anforderungsprozess am Ende stattfindet, bevor er zum Master zusammengeführt wird. Manchmal möchten Sie jedoch die Codeüberprüfung vor dem Testen der Geschäftsqualität durchführen - daher lange vor dem Zusammenführen

1
David Latty