Subversion: Zweig pro Umwelt?

Question

Zur Zeit arbeite ich an einem Projekt in .NET, die aus mehreren logischen Schichten und mehrere Frontends bestehen. Hier ist eine grobe Darstellung unserer SVN Struktur:

trunk
---doc
---lib
---src
------console
---------console.vbproj
------domain
---------domain.vbproj
------...
------web
---------web.vbproj
---.sln

Alle unsere Tag-zu-Tag-Entwicklung erfolgt in trunk - das ist, wo alle Entwickler Kasse von / verpflichten.

Ich bin auf der Suche nach einer Möglichkeit, sauber und einfach zwischen den Umgebungen (Test und Produktion) bereitstellen.

Mein Gedanke ist, zwei Zweige zum Erstellen, Testen und Produktion, von Stamm - Lösung und alle. Ich bin mir das an den folgenden Gründen zu rechtfertigen:

1. Ich habe die vollständige Kontrolle über die Änderungen nur vom Stamm zum Test Zweig Verschmelzung zu welchen Umgebungen fließen und aus dem Testzweig zu dem Produktionszweig
2. Ich kann leicht sehen, was Code, indem Sie einfach Blick auf das Protokoll der entsprechenden Zweig in Subversion

in jeder Umgebung ausgeführt wird

Hat jemand Erfahrung mit einer Lösung ähnlich wie diese hat? Gibt es irgendwelche möglichen Gefahren oder Versäumnisse, dass ich fehle?

Answer 1

Hat jemand Erfahrung mit einer Lösung ähnlich wie diese hatte?

Ja: -)

Gibt es irgendwelche möglichen Gefahren oder Versäumnisse, dass ich fehle?

Sie werden mit dem Problem konfrontiert, dass die Test- und Release Filialen im Laufe der Zeit aus der Entwicklungsumgebung driften weg, wie Sie sehr wahrscheinlich nicht jede Veränderung vom Stamm verschmelzen. Die Entwickler werden dann arbeiten in einer etwas anderen Umgebung und Sie werden, indem die Zweige synchron viel Zeit verschwenden. Dies ist bekannt als der merge-Manie anti-Muster .

Ich würde eher raten für jede geplante Veröffentlichung Release-Zweig vom Stamm zu erstellen, sobald Sie alle Funktionen bekommen dafür implementiert. Zu der Zeit, verzweigen Sie beide gleich sind. Dann hat ein Team zu stabilisieren und Test auf dem Release-Zweig. Die Entwicklung geht parallel auf Stamm. Sobald Ihr Release merge poliert wurde der Updates zu Stamm zurück.

Wiederholen Sie den Vorgang für jede Veröffentlichung. Auf diese Weise kann die Anzahl der Verschmelzungen begrenzt und haben die Leute auf etwas arbeiten, dass immer die Schneide.

Ich hoffe, diese Aspekte helfen Ihnen bei Ihrer Entscheidung. Der Link zeigt auch viele andere anti-Muster. Haben Sie einen Lese auf alle von ihnen vielleicht werden Sie einige Lektionen gelernt erkennen und einige Hinweise zu bekommen, es zu lösen besser.

Answer 2

Wir verwenden das gleiche Layout ohne Probleme. Stellen Sie sicher, die neueste SVN-Version zu verwenden. Version vor 1.5 sollte nicht wegen des fehlenden merge-Tracking verwendet werden.

In Verbindung mit einem Bug-Tracking-Tool wie JIRA von Atlassian (Ich bin nicht gesponsert) Ihr Setup wird noch transparenter zu machen.