SVN im agilen Projekt - 3 Systemlandschaft

[beta20]

Hallo zusammen,

ich habe derzeit ein Problem mit SVN im agilen Projekt mit einer 3 Systemlandschaft (Entwicklung, Testsystem, Produktion)

• Wir haben ein agiles Projekt (z.B. alle 3 Wochen soll etwas auf das Testsystem bzw. nach Produktion).
  • Nicht alle Entwicklungen innerhalb des Sprints sollen auch sofort in das Testsystem bzw. nach Produktion!

Derzeit haben wir
- 1x Entwicklungsbranch
- 1x Trunk

Alle 3 Wochen zum Beispiel geht etwas nach Produktion. Danach mergen wir den Entwicklungsbranch in den Trunk und spielen dann die Objekte aus dem Trunk ein.
Für das Testsystem haben wir keinen SVN Branch.

Nun haben wir aber ein Problem, dass teilweise Objekte in den Trunk kommen, die eigentlich noch gar nicht produktiv gehen sollen.
Hat hier jemand Erfahrungswerte bzw. andere Herangehensweiße hierfür.

Danke für die Hilfe

 

[LimDul]

Meine durchaus ernst gemeinte Antwort: Stellt auf GIT um. Vermutlich bekommt man es auch mit Subversion und Branching hin, aber meine Erfahrungen mit Subversion (die allerdings mittlerweile schon ein paar Jahre alt sind) sagen, mit SVN bekommt man da Probleme bzw. viel Overhead.

Unter GIT wäre die Vorgehensweise:
* Für jedes Feature was umgesetzt wird, wird ein Branch gemacht
* Nur Features, die fertig für die Auslieferung sind, werden in den Entwicklungsbranch gemergt

Das kann man mit Sicherheit auch mit Subversion machen, allerdings ist Branching & Merging bei Subversion meines Erachtens deutlich aufwendiger als mit GIT.


Grundsätzlich solltet ihr aber euren Workflow überdenken - entweder etwas ist fertig entwickelt und darf ausgeliefert werden - dann darf es in den Entwicklungsbranch. Oder es ist nicht fertig - dann darf es da nicht rein.

 

[LimDul]

Google hat mir gerade das hier gefunden, wo auch mit Links ein paar Varianten beschrieben sind: http://svnbook.red-bean.com/de/1.7/svn.branchmerge.advanced.html

(Ggf. auf Englisch umstellen, die deusche Seite liest sich für mich was seltsam).. Empfehlung wäre dennoch GIT, weil da der Workflow deutlich mehr dafür ausgelegt ist.