Subversion in Großprojekten – Workflow

Nach verschiedenen größeren Projekten hat sich langsam ein Workflow herauskristallisiert, mit dem wir das normale Szenario eines TYPO3-Projektes abbilden können. Zur Versionierung kommt hierzu Subversion mit dem „branch always“-Ansatz zum Einsatz, und es gibt für die Freigabe- und für die Live-Version getrennte Serverinstanzen.

Die Erklärung hierzu basiert weitgehend auf dem Beitrag SVN trunk, branches and tags von Jean-Michel, wurde aber übersetzt und um den Freigabe-Workflow ergänzt.

Subversion verbildlicht

Die Begriffe sind nicht zufällig gewählt, jedoch sollen sie an dieser Stelle noch einmal kurz erklärt werden:Working with SVN is somewhat like growing a tree:

• Ein Baum (tree) hat einen Stamm (trunk) und einige Äste (branches).
• Äste (branches) wachsen aus dem Stamm (trunk) heraus, und dünnere Äste (branches) wachsen teils aus dickeren Ästen (branches) heraus.
• Ein Baum (tree) kann mit einem Stamm (trunk) und ohne Äste (branches) wachsen (wird dies aber nicht lange tun ;-)).
• Ein Baum (tree) mit Ästen (branches) aber ohne Stamm (trunk) sieht eher nach einem Haufen Gestrüpp aus.
• Wenn der Stamm (trunk) krank ist, werden/sind es die Äste (branches) auch, und eventuell stirb der ganze Baum (tree).
• Wenn ein Ast (branch) krank ist, kann dieser weggeschnitten werden, und die anderen können weiter wachsen.
• Wenn ein Ast (branch) zu stark wächst, wird es möglicherweise zu schwer für den Stamm (trunk), und der Baum fällt um.
• Wenn der Baum, der Stamm oder ein Ast schön aussieht, kann ein Foto (tag) davon gemacht werden, um eines Tages sich wieder an diesen Zustand zu erinnern.

Trunk

Mit dem „branch always“-Ansatz ist der trunk die Stelle, die stabilen Code enthält (stable).
Bildlich: Der trunk ist quasi wie die Fertigungsstraße im Auto-Werk, wo bereits fertige, ausgetestete Komponenten zusammengebaut werden.

Regel zum Umgang mit dem trunk

• Arbeite NIE direkt im trunk, außer es ist ein Bug schnell und einfach zu fixen (nur wenige Zeichen) oder wenn nur Dateien hinzugefügt werden sollten, die keine Logik enthalten (Bilder, Videos etc.)
• Mache nicht zuviel Ausnahmen der vorhergehenden Regel, und diese sind wirklich Ausnahmefälle; alle anderen Fälle führen immer zum Anlegen eines neuen Branchs
• Mache keinen Commit von Änderung (aus einem branch merge) in den trunk, der diesen zerstört/unbrauchbar macht.
• Falls Du irgendwas doch den Trunk kaputt machst, bring am nächsten Tag Kuchen/Leberkäs/Döner mit. Bei großen Schäden großen Kuchen, dicke Scheiben, mit extra Fleisch

Branches

Regel zum Umgang mit Branches

• Wenn die Anwendung erweitert werden soll oder ein neues Feature hinzukommen soll, lege einen neuen Branch aus dem Trunk an und entwickle in in diesem Branch.
• Neue Branches müssen aus dem Trunk erstellt werden, außer bei Sub-Branches (soweit nötig), die aus dem jeweiligen Branch erstellt werden müssen.
• Wenn Du einen neuen Branch anlegst, wechsel sofort in diesen; falls Du es nicht tust, wozu hast Du ihn dann zuvor angelegt?

Workflow

• Erstelle eine neue Arbeitskopie des Projektes (durch einen Checkout oder einen Switch) aus dem Trunk
• Erstelle einen neuen Branch und benenne ihn so, dass man den Sinn/Inhalt versteht (z.B. „feature-contactform“)
• Wechsle mit Deiner IDE in diesen Branch (SVN switch to „/branches/feature-contactform“)
• Tue alles, was nötig ist an Änderung für das neue Feature (und natürlich eine Menge Tests, commite Teile Deiner Entwicklung wenn sinnvoll/nötig
• Wenn ein Feature fertig und stabil ist (und committet), merge den Trunk in den Branch (nicht gleich Deinen Branch in Trunk! auch nicht gleich in Freigabe-Branch), löse möglicherweise entstandene Konflikte und comitte diese neuen Änderungen
• Freigabe-Workflow
  Nach Absprache/Genehmigung durch die Projektbeteiligten:
  • in Freigabe-Kopie wechseln (SVN switch to „/branches/freigabe“)
  • Rebase/Replace die Arbeitskopie des Freigabe-Branchs mit dem Trunk
  • Merge Deinen Branch in die Freigabe-Kopie
  • Überprüfe nochmals Deine Entwicklung im gemergten Code
  • Bitte einen der anderen Entwickler um ein gemeinsames Review Deiner Änderungen
  • Committe Deine Arbeitskopie in den Freigabe-Branch
  • Vergebe ein Tag für die neue Beta-Version (z.B. 2011-11-beta1)
  • Rolle die Änderungen durch ein SVN update aus auf das Freigabe-System (ggf. erfolgt dies per post-commit für branches/freigabe automatisch)
• Release-Workflow
  Nach schriftlicher Freigabe durch Auftraggeberund Genehmigung durch die Projektbeteiligten:
  • in Trunk wechseln (SVN switch to „/trunk“)
  • Merge den Freigabe-Branch in Deine Arbeitskopie des Trunk (löse ggf. entstandene Konflikte)
  • Überprüfe nochmals Deine Entwicklung im gemergten Code
  • Committe Deine Arbeitskopie in den Trunk
  • Vergebe ein Tag für das neue Release (z.B. „2011-11“)
  • Rolle auf den betroffenen System die Änderungen durch ein SVN update aus (ggf. erfolgt dies per post-commit für trunk automatisch)
  • Benenne Deinen Entwicklungs-Branch so um, dass es klar ersichtlich ist, dass er nicht mehr verwendet wird („/branches/obsolete-feature-contactform”, „/branches/completed-feature-contactform”)
  • Eventuell nach einer gewissen Zeit den Branch löschen

 Quellen

• http://blog.jmfeurprier.com/2010/02/08/svn-trunk-branches-and-tags/