Vor allem wenn ich mit Abteilungen/Firmen arbeite, die aus der Subversion Welt kommen, höre ich oft die Frage, warum brauchen wir denn staging? Develop und Master ist ja prinzipiell klar, aber staging? Können wir uns das nicht sparen, dann müssen wir ja noch häufiger mergen.
Meistens hole ich dann kurz aus und lege nochmal dar wie typischerweise die Branches mit den Systemen korrelieren:
Da sich in develop die aktuelle Entwicklungsversion befindet, ist dieser die Basis für die Standard-Entwicklungen – üblicherweise werden von develop Feature Branches erzeugt. Nach Implementierung des Features wird zurückgemerged.
Sind alle Features eines Releases implementiert, bzw. zum festgelegten Termin, wird develop nach staging gemerged. Jetzt liegt das aktuell zu testende Release auf dem Staging Server. Wärenddessen wird in develop natürlich bereits an den nächsten Tickets für ein zukünftiges Release gearbeitet.
Wird jetzt beim Test auf dem Staging Server ein Fehler gefunden, muss dieser korrigiert werden, ohne dass Änderungen aus dem develop Branch auf den Testserver kommen. Also muss ausgehend von staging gearbeitet werden. Diese Änderungen müssen natürlich zurück in develop gemerged werden.
Theoretisch kann zum selben Zeitpunkt ein schwerwiegender Fehler auf dem Produktivsystem auftreten. Dieser soll sofort korrigiert werden – es steht ein sogenannter Hotfix an. Dafür wird vom Master Branch ausgehend entwickelt.
Zu diesem Zeitpunkt haben wir in allen 3 Hauptbranches unterschiedliche Stände, die sauber getrennt sind. Durch zurückmergen bzw. cherrypicken nach Fertigstellung wird sichergestellt, dass zukünftig keine der Neuentwicklungen / Bugfixes verloren geht.
Hat man bisher nur Erfahrung mit Subversion o.ä. dann wird man begeistert sein, wie einfach das Handling von Merges und Cherrypicks in git von der Hand geht.
Oft sehe ich im Projektalltag auch, dass die Verwendung eines staging Branches durch eine entsprechende Vorgehensweise vermieden wird. Das geht häufig gut, solange nur 1 Person für ein Projekt verantwortlich ist – wird diese aber mal zum falschen Zeitpunkt krank, wird das „System“ für die Vertretung leicht zum Albtraum. Nämlich dann, wenn nicht klar ist, welcher Stand in welchem Branch gehalten wird und evtl. ein Fall wie oben geschildert eintritt. Im Idealfall ist das Vorgehen standardisiert, dann ist der Zustand in den Haupt-Branches immer eindeutig definiert und von jedem Team-Mitglied leicht nachvollziehbar.
Aus meiner Sicht ist die Nutzung von develop, master UND staging heutzutage Pflicht, damit vernünftige Tests der Releases möglich sind.