Home

"Neuer" Git-Branch Workflow ab 2022-04

Es gibt 4 Kategorien von Branches, zwischen denen code (bis auf hotfixes) immer nur aufsteigend fließen sollte. Die Kategorien sind in aufsteigender Reihenfolge, mit Beispielen (xyz als Beispiel-Portalname):

• Feature-Branches (feature/xyz-fix-conferences). Nur hier sollte echtes coding passieren. Alle Feature branches gelangen über ein PR in den dev-Branch. Bitte achtet immer auf die Naming-Convention "feature/".
• Development-Branch (dev). Der bleeding-edge Entwicklungs-Branch, und von hier kann man jederzeit beim Losarbeiten ab-branchen um ganz up-to-date zu sein. Alle PRs werden immer gegen dev gestellt.
• Staging-Branches (staging für die meisten Portale, staging-xyz z.B. für Portale mit custom features). Korrespondieren 1:1 zu den staging-Server-Instanzen und zeigen so immer den aktuellen Stand, auf dem der Testserver gerade läuft. Features werden aus dem dev branch eingemerged oder ge-cherry-picked.
• Production-Branches (main als Hauptbranch für fast alle Portale, main-xyz z.B. für einzelne Portale, die aktuell andere Featuresets haben, weil sie schneller oder langsamer geupdated werden). Bis auf Hotfixes wird ein Production-Branch ausschließlich auf den getesteten committ-Stand eines Staging-Branches geupdated.

Zusätzlich wird bei jedem Deploy ein Release-Tag angelegt. Bisher hatten die Tags die Form "r--" (z.B. "r22-02-24"), aber ich werde ab jetzt dazu übergehen, die Form "r-WE-005" zu benutzen, die exakt den Namen der großen gitlab-Release Tickets entspricht.

Eigentlich ändert sich am aktuellen Stand dadurch nicht viel, die einzigen Unterschiede sind:

• immer darauf zu achten, neue branches nur als Featurebranch ("feature/...") anzulegen
• PRs immer gegen dev stellen (dev ist im Grunde jetzt das, was staging-xyz die letzten Monate war)
• staging-xyz und die anderen Staging branches zeigen jetzt genau an, was auf dem Staging Server läuft, statt zwischendurch auch mal undeployte Zwischenstände.