Als wir vor zwei Jahren anfingen, hatten wir eine einfache Regel: Alle committen in den Trunk. Das funktionierte, solange wir fünf Leute waren. Jetzt haben wir sechs Entwickler, drei parallele Projekte und einen Kunden, der einen Hotfix für die Version in Produktion braucht.
Unsere Branching-Strategie¶
Nach mehreren Monaten Experimentieren haben wir uns auf ein Modell eingependelt: trunk/ für die Hauptentwicklung, branches/release-X.Y/ beim Feature Freeze, branches/hotfix-X.Y.Z/ für dringende Korrekturen und tags/release-X.Y.Z/ als unveränderliche Snapshots. Feature Branches verwenden wir nicht — Mergen in SVN ist schmerzhaft.
Release-Prozess¶
Zwei Monate Entwicklung im Trunk, dann Feature Freeze und Erstellung eines Release Branch. Im Release Branch werden nur Bugs behoben. Der Trunk wird für den nächsten Entwicklungszyklus geöffnet.
Hotfix-Workflow¶
Der Kunde ruft am Freitag um 16 Uhr an. Die Produktionsversion ist 2.0.3, der Trunk ist bei 2.1-SNAPSHOT. Hotfix-Branch vom letzten Release-Tag erstellen, Fix, Test, Deployment, Merge zurück. Niemals direkt in einem Tag fixen.
SVN Hooks und Zugriffsrechte¶
Ein Pre-Commit-Hook erfordert eine JIRA-Ticketnummer in der Commit-Nachricht und verhindert Commits nach tags/. Post-Commit benachrichtigt Hudson. Die authz-Datei beschränkt den Schreibzugriff auf Release Branches auf Senior-Entwickler.
Fazit¶
SVN-Branching ist kein Albtraum mit klaren Regeln. Wenn wir auf Git wechseln, wird es wegen des besseren Mergens sein, nicht weil SVN nicht funktioniert.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns