...

Mit wachsender Komplexität in der Softwareentwicklung wird ein robuster Umgang mit Bereitstellungsumgebungen – Entwicklung, Staging und Produktion – unerlässlich. Jede Umgebung bringt eigene Anforderungen an Konfiguration, Zugriffskontrolle und Stabilität mit sich. Eine grundlegende Entscheidung, vor der jedes Team steht, ist: Wie sollen diese Umgebungen in der Versionskontrolle modelliert werden?

Mit zunehmender Reife Ihrer Deployment-Landschaft wird das Management mehrerer Umgebungen – wie Entwicklung, Staging und Produktion – entscheidend für einen reibungslosen Workflow, Stabilität und Geschwindigkeit. Eine zentrale architektonische Entscheidung ist, wie diese Umgebungen in der Versionskontrolle abgebildet werden.

Dieser Artikel beleuchtet drei gängige Strategien:

• Branching-Modell: Mehrere Umgebungs-Branches in einem einzigen Repository.
• Fork-Modell: Jede Umgebung ist als geforktes Repository isoliert.
• Trunk-Based Development (TBD): Alle arbeiten auf einem Haupt-Branch; Umgebungen werden über Deployment und Konfiguration gesteuert.

Option 1: Nutzung mehrerer Branches

Funktionsweise

• Umgebungen werden als Branches (develop, staging, main) innerhalb eines Repositories abgebildet.
• Features werden auf eigenen Feature-Branches entwickelt und via Pull-/Merge-Requests (PRs/MRs) in die jeweiligen Umgebungs-Branches integriert.
• Deployments für die jeweilige Umgebung werden durch Änderungen am entsprechenden Branch ausgelöst.

Vorteile

• Zentrale Historie: Alle Änderungen befinden sich in einem Repository – leicht nachverfolgbar und reviewbar.
• Reibungslose Promotion: Das Mergen von develop zu staging zu main passt gut in übliche PR-/MR-Workflows.
• Einfache Vergleiche: Unterschiede zwischen Staging und Produktion sind durch Branch-Vergleiche leicht ersichtlich.

Nachteile

• Merge-Konflikte: Auseinanderlaufende Hotfixes oder Konfigurationen können schwierige Merges verursachen.
• Konfigurations-Lecks: Gefahr, dass umgebungsspezifische Einstellungen versehentlich übertragen werden.
• Branch-Divergenz: Lang lebende oder schlecht synchronisierte Branches sind schwer zu vereinen.

Option 2: Nutzung geforkter Repositories pro Umgebung

Funktionsweise

• Jede Umgebung erhält ein eigenes Repository, implementiert als Fork des übergeordneten (meist Produktions-) Repositories:

  • myapp-dev (Fork von myapp-staging)
  • myapp-staging (Fork von myapp-prod)
  • myapp-prod (das Haupt- oder Autoritäts-Repo)

• Die Entwicklung findet hauptsächlich im Entwicklungs-Fork statt.

• Synchronisation erfolgt via PRs zwischen Forks: z. B. PR von myapp-dev zu myapp-staging, danach von myapp-staging zu myapp-prod.

Beispielhafter Workflow

1. Code wird in myapp-dev entwickelt.
2. Bei Fertigstellung wird ein PR von myapp-dev zu myapp-staging erstellt.
3. Nach erfolgreicher Staging-Validierung folgt ein PR von myapp-staging zu myapp-prod.

Vorteile

• Vollständige Isolation: Jede Umgebung kann eigene Einstellungen, Berechtigungen und sogar Code-Anpassungen besitzen.
• Explizite Promotion: Jede Beförderung zwischen Umgebungen ist ein sichtbarer, formalisierter PR – gut für Reviews und Qualitätssicherung.
• Strikte Zugriffskontrolle: Repo-basierte Berechtigungen begrenzen, wer was wo ändern darf.

Nachteile

• Höherer Overhead: Entwickler:innen und Automatisierung müssen Forks aktiv synchron halten; schnelles Teilen von Code wird erschwert.
• Komplexe Synchronisation: Manuelle oder geskriptete PRs können mühsam sein und zu Verzögerungen oder Auslassungen führen.
• Tooling-/CI-Duplikation: Jedes Repo benötigt eigene Pipelines, Secrets und Integrationen – kann aber zentral verwaltet werden.

Option 3: Trunk-Based Development (TBD)

Beim Trunk-Based Development arbeiten alle direkt auf einem Haupt-Branch – oft main oder trunk genannt. Bereitstellungsumgebungen werden dynamisch über Konfiguration, Feature Flags und Deployment-Automatisierung verwaltet – nicht über separate Branches oder Forks.

Funktionsweise

• Feature-Branches sind, falls vorhanden, sehr kurzlebig.
• Kontinuierliche Integration: Commit/Merge in main, Tests und Deployment folgen automatisch.
• Feature Flags steuern unfertige oder neue Features.
• Umgebungen basieren auf dem gleichen Code, unterscheiden sich nur durch Konfiguration zur Deploy-Zeit.

Vorteile

• Einfachste Historie: Keine Merge-Konflikte.
• Schnelles Feedback: Continuous Integration & Deployment möglich.
• Minimaler Overhead: Keine Branch- oder Fork-Synchronisation; alle Änderungen sind jederzeit deploybar.
• Fördert DevOps: Enges Zusammenspiel von Entwicklung und Betrieb.

Nachteile

• Disziplin & Automatisierung nötig: Erfordert Feature Flags, gutes Testen und ein solides CI/CD-Setup.
• Begrenzte Isolation: Unterschiede zwischen Umgebungen nur per Konfiguration – kein vollständiger Code-Schutz wie bei Forks.
• Schnelle Sichtbarkeit: Risiko, dass fehlerhafter Code in main landet – verlangt starke Review-, Test- und CI-Kultur.

Das passende Modell wählen – welches passt zu eurem Team?

Vergleichstabelle

Zusammenfassung

• Das Branching-Modell ist vertraut und funktioniert gut für kleine bis mittlere Teams.
• Forks bieten maximale Isolation auf Kosten der Synchronisations-Komplexität – ideal bei strikten Anforderungen an Trennung.
• Trunk-Based Development ist der schlanke, moderne Ansatz: ein Branch, Feature Flags, solide CI/CD und kontinuierliche Auslieferung – ideal für Teams mit DevOps-Fokus, Automatisierung und schnellem Feedback-Zyklus.

Die Wahl hängt von euren Prioritäten ab: Sicherheit, Geschwindigkeit oder Trennung. In den kommenden Artikeln zeigen wir, wie man Automatisierung für jedes Modell umsetzt.

Im nächsten Teil

In den Folgeartikeln dieser Serie zeigen wir:

• Wie man CI/CD-Automatisierung je Modell aufsetzt
• Wie man PR-/Merge-Prozesse für Code-Promotion gestaltet
• Wie man Secrets und Konfigurationen pro Umgebung organisiert