So werden Sie den Entwicklungszweig für einen vereinfachten Git-Flow los

In einem kontinuierlich weiterentwickelten Webprojekt (kein Produkt) verfolgen wir derzeit die folgende Verzweigungsstrategie, die grob auf Git Flow basiert :

• branch entwickeln: neueste arbeitsversion
• master branch: freizugebende version / freigegebene version
• Feature-Zweige: Features in Entwicklung
• Hotfix-Zweige: dringende Bugfixes in der veröffentlichten Version

Der Master ist schreibgeschützt und wird über Pull-Anforderungen aus Entwicklungs- oder Hotfix-Zweigen aktualisiert . Jedes Update führt dazu, dass ein Release Candidate erstellt und auf dem Staging-System bereitgestellt wird. Release-Kandidaten werden nach manueller Genehmigung für die Produktion bereitgestellt.

Feature-Zweige werden basierend auf der Entwicklung oder aus dem letzten Commit erstellt, das mit dem Master zusammengeführt wurde. Eine Pull-Anforderung aus einem zu entwickelnden Feature-Zweig wird erstellt und in einem kostenlosen Testsystem bereitgestellt, in dem Integrationstests und Abnahmetests (automatisch und manuell) ausgeführt werden. Nach erfolgreichem Test und Überprüfung wird der PR zusammengeführt, sodass er Teil des nächsten Releases wird (dh von der Entwicklung zum Master zusammengeführt wird).

Mein Ziel

Ich möchte dies vereinfachen und den Entwicklungszweig loswerden. Der Entwicklungszweig hat hauptsächlich historische Gründe und da es sich immer um eine erfolgreich getestete Version handelt, ist es meines Erachtens unnötig, ihn vom Master zu trennen. Durch das Entfernen wird auch der Freigabeprozess vereinfacht, da keine weitere Zusammenführung mehr erfolgt.

Ich habe folgende Einschränkungen:

• Veröffentlichungen sind geplant und sollten nicht vollständig automatisiert werden
• Während Feature-Zweige in der Regel nur von kurzer Dauer sind, bleiben einige für einige Wochen nicht verbunden (z. B. ein Redesign), müssen jedoch ebenfalls getestet werden (derzeit als Open-Pull-Anforderungen für die Entwicklung).
• Manchmal sollte ein einzelnes Feature außerhalb des regulären Releases veröffentlicht werden, um es effektiv in einen Hotfix zu verwandeln. Mit der aktuellen Strategie kann ich einen Feature-Zweig rebasieren und direkt in den Master einbinden
• Es kommt auch vor, dass wir Funktionen zurückhalten müssen, nachdem Abnahmetests mit externen Systemen bei fehlgeschlagener Bereitstellung fehlgeschlagen sind

Wo ich nicht sicher bin über den Übergang:

• Derzeit erstelle ich Pull-Anforderungen zum Testen und füge Commits für Releases zusammen. Kann ich das vereinheitlichen?
• Wie gehe ich mit Hotfixes um, wenn der Master der neuesten Version voraus ist? Soll ich Releases direkt aus Hotfix-Zweigen erstellen und bereitstellen?
• Gibt es eine sinnvolle Möglichkeit, mit Funktionen umzugehen, die nach dem Zusammenführen von Funktionen von einer Freigabe ausgeschlossen werden sollten? Ist ein separater Entwicklungszweig in diesen Fällen wirklich von Vorteil? Die meiste Zeit ende ich damit, dass ich Commits sowieso manuell zurücksetze und wieder zurücksetze.

IMHO sind die Probleme, mit denen Sie konfrontiert sind, nur ein Nebeneffekt der schlechten Filialstrategie, mit der Sie begonnen haben: Sie pflügen effektiv Neuentwicklungen develop(dh was in Richtung des zukünftigen Produktionscodes konvergiert ) durch den aktuellen Produktionscode an master. Dies führt zu widersprüchlichen Anforderungen und Problemen, da der zukünftige Code normalerweise vom aktuellen Code abweicht:

• die Neuentwicklung destabilisiert Produktion - Regressionen gesehen nach dem Zusammenführen developinmaster
• Die Stabilisierung der Produktion verlangsamt die zukünftige Entwicklung - Sie müssen die Produktion stabilisieren develop, damit sie gut genug für die Fusion istmaster

Löschen develophilft nicht (viel) - Sie beseitigen das Problem nicht, Sie übertragen nur den developspezifischen Teil des Problems in master.

Ein besserer Ansatz wäre, die Produktion hinter die aktuelle / zukünftige Entwicklung zu verlagern , um Entwicklungsstörungen für zukünftige Releases zu vermeiden, wie in diesem Bild aus Was ist Ihr Verzweigungsmodell? Dargestellt. :

Bitte beachten Sie, dass ich mich nur auf die Release-Zweige im obigen Bild beziehe, nicht darauf, was im Kofferraum passiert.

Wie würde das für Sie funktionieren:

• Der developZweig verschwindet, wie Sie es wünschten, und zieht sich in sich zusammenmaster
• Die masterNiederlassung ist Ihr Stamm. Hier erfolgt die Entwicklung ohne Geschwindigkeitsbeschränkungen (sie wird niemals in die Produktion integriert).
• Produktion ist / sind eine oder mehrere releaseNiederlassungen, die von einem masterEtikett / Etikett gezogen wurden, das als der Produktionsqualität nahe genug angesehen wird (eine kurze Liste der verbleibenden Aufgaben kann in dieser Niederlassung bei Bedarf behandelt werden). Diese Zweige können nur direkte Hotfixes und / oder ausgewählte Fixes von erhalten master, sie werden nie mit masteroder anderen Zweigen zusammengeführt
• Hotfixes sind direkte Commits in releaseZweigen

Wenn ein Hotfix nur für eine Produktionsversion gilt, jedoch nicht für die master, wird er direkt an den releaseZweig übergeben. Wenn beides zutrifft, gilt dies in der Regel auch für masterFirst Commit und Cherry-Picked / Double-Commit für den releaseZweig.

Wenn Sie sich nun ansehen, was in masterden releaseZweig geht (der hinter dem Punkt liegt, an dem der aktuelle Zweig abgezogen wird), haben Sie zwei Möglichkeiten:

• weiterhin mit Feature - Filialen wie Sie heute tun, außer sie aus basieren werden master, nicht develop. Das Konvertieren in Hotfixes bleibt weiterhin möglich - Sie müssen sie releasestattdessen nur in den entsprechenden Zweig umwandelnmaster
• Stellen Sie auf kontinuierliche Integration um und nutzen Sie die Vorteile (dies ist jederzeit möglich), auch in progressiver Weise. Ziehen Sie nach und nach immer weniger Feature-Zweige heraus.

Wenn Ihnen dieser Ansatz gefällt, erfahren Sie hier, wie Sie von Ihrem heutigen Standort dorthin gelangen:

• Legen Sie eine Release-Namensstrategie fest:
  • Sie können keinen laufenden Release-Zweig mit demselben Namen haben
  • Sie können (sollten eigentlich nicht) einen Produktions-Release-Zweig rebasieren oder synchronisieren
• Ziehen Sie sofort einen releaseXZweig ab master, indem Sie dieser Namensstrategie folgen
• Hören Sie auf, Commits einzugehen develop, sie werden bald direkt zu gehen master.
• verschmelzen developzumaster
• Weisen Sie die Entwickler an, ihre Arbeitsbereiche auf "rebase on" masteranstatt auf " develop.
• offen masterfür Commits
• Löschen, developwenn Sie möchten (oder dauerhaft gesperrt / schreibgeschützt lassen)

Nehmen wir an, Sie nehmen den Hauptzweig heraus (Sie können "Develop" in "Master" umbenennen, um Ihr Team zu verwirren, wenn Sie dies später möchten) und verwenden einfach Tags für Veröffentlichungen in Entwicklungs- oder Hotfix-Zweigen. Sie haben einen Zweig entfernt, aber der Unterschied ist nur eine Änderung der Syntax. Wechsel um Wechsel willen.

Nehmen wir nun an, Sie nehmen die Entwicklung tatsächlich unter Beibehaltung des gesperrten Hauptzweigs vor. Was passieren wird, ist, dass die Integration von Code verlangsamt wird, es wird länger in Feature-Zweigen getrennt leben, insbesondere in der Nähe von Veröffentlichungsdaten. Dies erhöht die Schwierigkeit des Zusammenführens jedes Mal und verlangsamt den Prozess.

Unter den von Ihnen festgelegten Bedingungen sehe ich keine positiven Auswirkungen einer solchen Änderung. Es würde die Lockerung der Zwänge erfordern, insbesondere der ersten.

Sie erstellen und testen bereits Code für jeden Pull-Request- und Hot-Fix-Zweig. Dies bedeutet, dass insgesamt die Summe aller auf Abruf ausstehenden Zweige Ihr virtueller developZweig ist.

Sie können ein System erstellen, wenn in einer Testumgebung mehrere Pull-Requests in einen temporären Zweig gepickt werden, der nicht im Hauptrepository veröffentlicht wird. Dieser Zweig wird verwendet, um eine Testumgebung zu integrieren, die mastermehrere zusätzliche Pull-Requests enthält. Nach Abschluss des Tests ist dieser Zweig jedoch nirgendwo mehr verfügbar.

Wenn Sie ein Release von erstellen, erstellen masterSie normalerweise ein Tag für dieses Release. Spätere Hotfixes können dieses Tag verwenden, um einen neuen Hotfix-Zweig zu erstellen, von dem aus eine Bereitstellung durchgeführt wird, obwohl der Rand von masterbereits voraus ist. In diesem Hotfix-Zweig würden Sie wahrscheinlich auch eine kleinere Version markieren und sicherstellen, dass die Änderungen übernommen wurden master.

Das Entfernen von zusammengeführten Features aus einem Release ist mit git ziemlich schwierig. Der beste Mechanismus hierfür wäre die Verwendung git revertdes Merge-Commits. Aber das macht es fast unmöglich, diese Funktionen / Änderungen zurückzugewinnen, und die Geschichte wird durcheinander.

Eine viel bessere Möglichkeit, die Trennung für die Bereitstellung von Code und die Freigabe von Features zu handhaben, sind Feature-Flags . Wenn Ihre Entwickler ihre Funktionen hinter bestimmten Bedingungen im Code selbst verbergen können, können Sie ihren Code bereitstellen, die Funktion jedoch deaktivieren. Dies ist ein separates Thema, aber es gibt viele Informationen dazu (einschließlich einer Frage und Antwort zu devops.SE).

Gut, @ dan-cornilescu sagt es gut für Ihr spezielles Problem, aber der allgemeinere Fall für die stammbasierte Entwicklung (erwähnt in Continuous Delivery, Lean Enterprise und The DevOps Handbook) wird hier gestellt: https://trunkbaseddevelopment.com/