Categories
Branching & Merging DevOps Git

Branching Modell für den Betrieb in großen Umgebungen

Ich habe in großen Rechenzentren mit verschiedenen Gir Branch Modellen Erfahrungen gesammelt. Kurz:
git Flow ist meist zu komplex.
gitlab flow berücksichtigt einige wichtige Aspekte des Betriebs nicht.
Trunk Based Development funktioniert meines Erachtens nicht bei Service Providern, die keine Anwendungen entwickeln sondern nur betreiben, dies aber in hohen Installationszahlen mit vielen unterschiedlichen Releases.

Der Betriebsaspekt wird meines Erachtens zu oft unterschätzt. DevOps ist eben genau Dev und Ops. Die meisten Branch Konzepte finden Lösungen für Entwickler. Die betrieblichen Aspekte eines langfristigen, stabilen Betriebes in großen Umgebungen werden oft nicht bedacht.

Ein Beispiel eines Service Providers

Der Service Provider administriert eine Anwendung, nennen wir Sie “Banking v1.0”, auf WebSphere Application Server oder Tomcat und betriebt diese für Kunden. Die Anwendung selbst wird von einem Softwarehersteller geliefert. Es erfolgt keine Entwicklung.

Das Betriebsteam hat einen Branch master, der die Banking App v1.0 auf der Middleware deployt. Wird eine neue Version v1.1 geliefert, und auf dem master Branch eingecheckt, kann diese auf die Test und Integraions Stages ausgerollt werden. Nach erfolgreichem Tests kann in Produktion deployt werden. Was aber macht man, wenn die Tests noch andauern, aber in der Produktion ein Patch 1.0.1 eingespielt werden muss.
Was macht man, wenn die App in verschiedenen Versionen v1.1 und v1.2 auf verschiedenen Systemen des Service Providers im Auftrag des Kunden läuft?

Ein Lösungsansatz

Mit tags sind solche Konstellationen schwierig zu lösen. Ein guter Ansatz ist hier dargestellt:
A Successful Git Branching Model With Enterprise Support

Er geht von zusätzlichen Branches für den Support und einem Branch “stable” (ich würde ihn eher “prod” nennen) aus. Ich persönlich würde die Nutzung solcher Branches so weit wie möglich einschränken und diese schnell wieder “abbauen”, aber in den oben beschriebenen Szenarien sind sie sicherlich sinnvoll.

Categories
Branching & Merging DevOps Git

Alternative zu git stash

Bei der Arbeit in einem Feature Branch kann es passieren, dass aus verschiedenen Gründen ein anderer Branch kurz ausgescheckt und bearbeitet werden muss.

Normalerweise verwendet man git stash dafür.
Ich möchte kurz eine Alternative erläutern.

Die Idee ist, einen zweiten worktree anzulegen und zu nutzen. Der bereits ausgescheckte Feature Branch ist in einem lokalen worktree auf der Festplatte abgelegt. Normalerweise hat man für jedes Projekt nur einen worktree. Daher muss man bei einem Wechsel der Branches die Änderungen committen oder zurückstellen/stashen.

Der git Client bietet allerdings die wenig bekannte Option, einen zweiten worktree basierend auf einem Branch anzulegen. Der folgende Befehl legt in einem neuen Verzeichnis einen worktree des master Branches an:

cd <HomeDirOfProject>
git worktree add ../worktree_master master

Mit einfachen Verzeichniswechseln (cd)

cd ../worktree_master
cd ../<HomeDirOfProject$gt;

kann man jetzt zwischen den Branches wechseln.

Hinweis: Einen zweiten worktree des bereits aktiven, ausgecheckten Branches quittiert git mit einem
fatal: 'master' is already checked out at ...

Mit

cd <HomeDirOfProject>
git worktree remove ../worktree_master

wird man den worktree wieder los.

Die offizielle Dokumentation findet man hier. Bitte für den produktiven Einsatz die Warnung am Ende der Dokumentation beachten:
Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject.

Categories
Branching & Merging Git

Ein sehr gutes Modell für GIT Branching & Merging

Für mich persönlich hat sich das von Vincent Driessen beschriebene Branching Modell im Bereich der Software Entwicklung als sehr nützlich erwiesen. Er beschreibt es hier: A successful Git branching model

Mit diesem Modell kann sehr flexibel auf die verschiedneen Anforderungen, wie – Neue Releases (Major und Minor Releases) – Arbeiten an neuen Features – Hotfixes parallel zu den Releases auch in größeren Teams reagiert werden.

Wenn es darum geht, mehr oder wenig fertig angelieferte Softwareartefakte mit Hilfe eines Git/Gitlab Projekts zu deployen und konfigurieren, weiche ich allerdings oft davon ab. In diesem Fall ist oft ein Branching Konzept Branch = Stage) sinnvoll. Alsi ein Branch Dev für die Entwicklungssysteme, ein Branch INT für Integration Systeme und so weiter. Ich weiss, das dies sehr kontrovers diskutiert wird. Bei Service Providern, die angelieferte Software auf vielen Systeteme deployen und betreiben, ist dieses Vorgehen sehr einfach zu handhaben. Ebenso können CI Stages den Branches und Stages zugeordnet werden.

Letztendlich hängt es vom Einzelfall ab, welchem Konzept man den Vorrang gibt.