Wir verwenden Git-Flow, um Hotfixes & Funktionen zu behandeln, mit einem Zweig entwickeln & der Master-Zweig (für die Produktion).Wie verwende ich git flow mit einer Staging-Umgebung?
Was ist der einfachste Weg, einen Staging-Zweig zu der Mischung hinzuzufügen, damit wir die Arbeit, die sich auf dem Weg zur Produktion befindet, validieren können, ohne die Hilfsbereitschaft des Git-Flows zu verlieren?
Ich würde sagen, dass Staging auf einem Git-Flow-Release-Zweig basieren sollte. Nach einem git flow release start und git flow release publish können Sie die QA-Arbeit für diesen Zweig starten, einschließlich der Veröffentlichung in einem Bereitstellungsbereich. Wenn die QA-Arbeit im Staging-Bereich den Code für die Produktionsfreigabe zur Installation in der Produktion geprüft hat, tun Sie dies unter git flow release finish.
Wenn Sie TeamCity verwenden, können Sie den Server einfach so einrichten, dass er neue Zweigstellen für die Fernübertragung erkennt und automatisch Builds für sie erstellt, see here.
Ich habe beginnen gerade git Flow verwenden, aber IMHO ist der einfachste Weg nächste Release als dev Zweig und Produktions-Releases als stage Zweig eingestellt ist und dann z.B .: manuell mit master Zweig (Ihrer realen Produktion) fusionieren.
Wenn Sie also Version 1.2.0 bis stage freigeben und dann Fehler in Ihrer Version finden (4 Hotfixes, z. B .: in core CMS, feature1, feature3 und feature4), können Sie immer Patches anwenden, damit Sie zum Beispiel landen können mit der Version 1.2.4 und schließe sie schließlich an die Produktion an.
UPDATE: Dieses Szenario vorausgesetzt, Sie haben Roll-Back-Mechanismus, so dass Sie immer hinzufügen Commits zu beheben, Release-Funktion oder etwas anderes. Wenn Sie einen Roll-Back-Mechanismus haben, müssen Sie sich nicht um Ihre Fehler in Ihrer Produktion kümmern. Wenn Sie einen Fehler entdecken, verwenden Sie Roll-Back, um die vorherige Arbeitsversion einzurichten. Beispiel: Wenn Sie einen Fehler in der Version 1.2.3 finden, gehen Sie zurück zur Version 1.2.2. Fehler beheben, auf dev dann auf stage testen und als Version 1.2.4 in die Produktion schieben. Ihre Produktion springt also von 1.2.2 direkt zu 1.2.4.
Sie schlagen vor, für jedes potenzielle Release einen anderen Zweig zu verwenden als einen dedizierten Zweig für "das nächste Release im Test" (Staging) zu verwenden, genauso wie es immer einen Entwicklungs- & Masterzweig gibt? – Eric
Ja, das wäre der Standard-Git-Flow-Weg, afaik. Sie könnten die Verzweigung immer gleich nennen, z. "Inszenierung". Aber normale Verwendung von git-flow würde den Zweig entfernen, wenn Sie Flow Release Release beenden und neu erstellen, wenn Sie den Flow Release Start starten. –
Wie würden Pull-Requests mit dieser Methode arbeiten? –