Zweck dieses Dokuments ist es, die minimal erforderlichen gemeinsamen Richtlinien und Maßnahmen einer Organisation für die KOMPLEXE Branching-Strategie und den Bereitstellungsprozess zu definieren, die während des Lebenszyklus durchgeführt werden sollen.

Die Standardstruktur für die Anwendungsbereitstellung verwendet die folgenden Umgebungen:

• lokale Entwicklungsumgebung (lde)

• Entwicklung (dev)

• Staging (stg)

• Produktion (prd)

• Master

  Dies entspricht einem Standardsatz von drei Branches in allen Anwendungs-Repositories:

Die folgenden betrieblichen Richtlinien sind zu beachten:

• Alle Branches werden von oben nach unten aus der obigen Tabelle neu gebildet (Rebase) ^^^ – dies bedeutet zum Beispiel, dass Hotfixes in der Produktion MÜSSEN auf alle darunterliegenden Branches in der folgenden Reihenfolge angewendet werden – develop, stg, staging, production auf jeden Feature-Branch, der zum Zeitpunkt der Anwendung noch in Arbeit ist (WIP)

• Wenn ein neues Feature entwickelt wird, erstellt der Entwickler einen neuen Feature-Branch aus der neuesten Version des develop Branches. Der Feature-Branch muss dem develop Branch folgen, also rebase.

• Features, die Komplexität hinzufügen, aber keine Tests mit CI-Implementierung dieser Testkomplexitäten bieten, DÜRFEN nicht zu irgendeinem der gemeinsamen Branches hinzugefügt werden (Überprüfen Sie die konkreten Schritte, die zu befolgen sind)

• Wenn das neu entwickelte Feature zur Aufnahme bereit ist, erstellt der Entwickler eine Pull-Anfrage, um zu bitten, seinen/ihren Feature-Branch in den develop Branch zu mergen.

• Die Pull-Anfrage wird von mindestens einem anderen Teammitglied überprüft und in den develop Branch gemerged, WENN der Prüfer die Pull-Anfrage genehmigt und alle geänderten Microservice-Komponenten getestet sind.

• Das Deployment in die stg Umgebung erfolgt vom stg Branch, um es für das Staging durch nicht-technische Benutzer bereitzustellen.

• Wenn das Deployment des stg Branches Probleme hat oder wenn die nicht-technischen Benutzer das neueste Deployment in der Staging Umgebung nicht genehmigen, wird ein Rollback durchgeführt.

• Wenn der staging Branch von nicht-technischen Benutzern in der stg Umgebung getestet wurde und bereit für die Produktion ist, mergen die Verantwortlichen für das Deployment das Feature in den release Branch (mit den Flags -X theirs und --allow-unrelated-histories) und taggen es mit einer neuen Version, um den Zustand des Codes durch den Aufruf git push --tags identifizierbar zu machen.

• Das Deployment in die Produktionsumgebung erfolgt vom release Branch.

• WENN die Geschäftsvertreter einen Fehler in der Produktion finden, der in weniger als 4 Stunden behoben werden kann, wird ein Hotfix Branch vom release Branch erstellt und schnell zuerst in der stg-Umgebung und, wenn alle Tests dort auch schnell bestanden werden, in die Produktion mit einem neuen Tag deployed. Sollte der Hotfix länger als 4 Stunden dauern, muss ein Priorität-1-Fehler erstellt werden und das Nicht-Hotfix-Deployment-Prozedere wird befolgt.

• Nachdem die Geschäftsvertreter die neue Version in der Produktion Umgebung genehmigt haben, wird der bestehende prod Branch mit dem release Branch neu gebildet (rebase) – das veröffentlichte Git-Tag wird zur neuen „Quelle der Wahrheit“ – also was die aktuelle Version der Software ist, die in der Produktionsumgebung läuft.

• WENN die Geschäftsvertreter die neue Version nicht genehmigen, erfolgt ein Rollback zum vorherigen Produktions Commit.

• Nach der Veröffentlichung werden ALLE gemeinsamen (develop und release) Branches vom develop Branch durch die Person, die die Veröffentlichung durchführt, neu gebildet (rebase). Alle anderen Entwickler MÜSSEN auch ihre Feature– / Bugfix-Branches vom develop Branch neu bilden (rebase) – jeder Entwickler muss sicherstellen, dass der Unterschied (Diff) zwischen dem gemeinsamen develop Branch und dem aktuellen Feature– / Bugfix-Branch, an dem er/sie arbeitet, NUR Änderungen enthält, die den aktuellen Fehler/das aktuelle Feature betreffen, an dem er/sie arbeitet.

HINWEIS: Deployments in die Live-Umgebungen sollten immer durch automatisierte CI/CD-Prozesse durchgeführt werden, niemals manuell. Im oben beschriebenen Prozess werden alle Bewegungen zwischen den Umgebungen über das Quellcode-Kontrollsystem auf GitLab durchgeführt.

Jedes Deployment in verschiedene Umgebungen sollte über die GitLab Actions UI manuell ausgelöst werden können.

• Alle Branches werden von oben nach unten aus der obigen Tabelle neu gebildet (Rebase) ^^^ – dies bedeutet zum Beispiel, dass Hotfixes in der Produktion MÜSSEN auf alle darunterliegenden Branches in der folgenden Reihenfolge angewendet werden – develop, stg, staging, production auf jeden Feature-Branch, der zum Zeitpunkt der Anwendung noch in Arbeit ist (WIP)

• Wenn ein neues Feature entwickelt wird, erstellt der Entwickler einen neuen Feature-Branch aus der neuesten Version des develop Branches. Der Feature-Branch muss dem develop Branch folgen, also rebase.

• Features, die Komplexität hinzufügen, aber keine Tests mit CI-Implementierung dieser Testkomplexitäten bieten, DÜRFEN nicht zu irgendeinem der gemeinsamen Branches hinzugefügt werden (Überprüfen Sie die konkreten Schritte, die zu befolgen sind)

• Wenn das neu entwickelte Feature zur Aufnahme bereit ist, erstellt der Entwickler eine Pull-Anfrage, um zu bitten, seinen/ihren Feature-Branch in den develop Branch zu mergen.

• Die Pull-Anfrage wird von mindestens einem anderen Teammitglied überprüft und in den develop Branch gemerged, WENN der Prüfer die Pull-Anfrage genehmigt und alle geänderten Microservice-Komponenten getestet sind.

• Das Deployment in die stg Umgebung erfolgt vom stg Branch, um es für das Staging durch nicht-technische Benutzer bereitzustellen.

• Wenn das Deployment des stg Branches Probleme hat oder wenn die nicht-technischen Benutzer das neueste Deployment in der Staging Umgebung nicht genehmigen, wird ein Rollback durchgeführt.

• Wenn der staging Branch von nicht-technischen Benutzern in der stg Umgebung getestet wurde und bereit für die Produktion ist, mergen die Verantwortlichen für das Deployment das Feature in den release Branch (mit den Flags -X theirs und --allow-unrelated-histories) und taggen es mit einer neuen Version, um den Zustand des Codes durch den Aufruf git push --tags identifizierbar zu machen.

• Das Deployment in die Produktionsumgebung erfolgt vom release Branch.

• WENN die Geschäftsvertreter einen Fehler in der Produktion finden, der in weniger als 4 Stunden behoben werden kann, wird ein Hotfix Branch vom release Branch erstellt und schnell zuerst in der stg-Umgebung und, wenn alle Tests dort auch schnell bestanden werden, in die Produktion mit einem neuen Tag deployed. Sollte der Hotfix länger als 4 Stunden dauern, muss ein Priorität-1-Fehler erstellt werden und das Nicht-Hotfix-Deployment-Prozedere wird befolgt.

• Nachdem die Geschäftsvertreter die neue Version in der Produktion Umgebung genehmigt haben, wird der bestehende prod Branch mit dem release Branch neu gebildet (rebase) – das veröffentlichte Git-Tag wird zur neuen „Quelle der Wahrheit“ – also was die aktuelle Version der Software ist, die in der Produktionsumgebung läuft.

• WENN die Geschäftsvertreter die neue Version nicht genehmigen, erfolgt ein Rollback zum vorherigen Produktions Commit.

• Nach der Veröffentlichung werden ALLE gemeinsamen (develop und release) Branches vom develop Branch durch die Person, die die Veröffentlichung durchführt, neu gebildet (rebase). Alle anderen Entwickler MÜSSEN auch ihre Feature– / Bugfix-Branches vom develop Branch neu bilden (rebase) – jeder Entwickler muss sicherstellen, dass der Unterschied (Diff) zwischen dem gemeinsamen develop Branch und dem aktuellen Feature– / Bugfix-Branch, an dem er/sie arbeitet, NUR Änderungen enthält, die den aktuellen Fehler/das aktuelle Feature betreffen, an dem er/sie arbeitet.

HINWEIS: Deployments in die Live-Umgebungen sollten immer durch automatisierte CI/CD-Prozesse durchgeführt werden, niemals manuell. Im oben beschriebenen Prozess werden alle Bewegungen zwischen den Umgebungen über das Quellcode-Kontrollsystem auf GitLab durchgeführt.

Jedes Deployment in verschiedene Umgebungen sollte über die Git/GitLab DevOps UI manuell ausgelöst werden können.