Setzen Sie die Entwicklung in einem Zweig oder im Stamm fort?

Question

Angenommen, Sie entwickeln ein Softwareprodukt, das in regelmäßigen Abständen veröffentlicht wird. Was sind die besten Praktiken in Bezug auf Verzweigungen und Zusammenführungen? Regelmäßige Veröffentlichungszweige für die Öffentlichkeit (oder wen auch immer Ihr Kunde ist) abtrennen und dann die Entwicklung auf dem Stamm fortsetzen, oder den Stamm als stabile Version betrachten, ihn regelmäßig als Veröffentlichung kennzeichnen und Ihre experimentelle Arbeit in Zweigen durchführen. Was denken die Leute, gilt der Stamm als "Gold" oder als "Sandkasten"?

Answer 1

Das hängt von der Größe Ihres Entwicklungsaufwands ab. Mehrere Teams, die parallel arbeiten, werden nicht in der Lage sein, alle effektiv am selben Code (Stamm) zu arbeiten. Wenn Sie nur eine kleine Gruppe von Leuten haben, und Ihr Hauptanliegen ist es, einen Zweig zu schneiden, damit Sie weiterarbeiten können, während Sie zum Zweig zurückgehen, um Fehler am aktuellen Produktionscode zu beheben, würde das funktionieren. Dies ist eine triviale Anwendung von Branching und nicht zu aufwändig.

Wenn Sie viel parallel entwickeln, werden Sie Zweige für jede Arbeit haben wollen, aber das erfordert auch mehr Disziplin: Sie müssen sicherstellen, dass Ihre Zweige getestet werden und bereit sind, sie wieder zusammenzuführen. Planen Sie die Zusammenführungen so, dass nicht zwei Gruppen gleichzeitig versuchen, etwas zusammenzuführen usw.

Manche Zweige befinden sich so lange in der Entwicklung, dass man Zusammenführungen vom Stamm in den Zweig zulassen muss, um die Zahl der Überraschungen bei der endgültigen Rückführung in den Stamm zu verringern.

Wenn Sie eine große Gruppe von Entwicklern haben, müssen Sie experimentieren und ein Gefühl dafür entwickeln, was in Ihrer Situation funktioniert. Hier ist eine Seite von Microsoft, die hilfreich sein kann: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Answer 2

Wir verwenden den Stamm für die Hauptentwicklung und den Zweig für Wartungsarbeiten an neuen Versionen. Das funktioniert gut. Aber Zweige sollten nur für Fehlerkorrekturen verwendet werden, keine größeren Änderungen, vor allem auf der Datenbankseite, wir haben eine Regel, dass nur eine Schemaänderung auf dem Hauptstamm passieren kann und niemals im Zweig.

Answer 3

Wenn Sie während eines Release-Zyklus an einem großen Feature arbeiten, werden Sie in einem Zweig eingeschlossen. Ansonsten arbeiten wir im Stamm und im Zweig für jede Produktionsversion in dem Moment, in dem wir sie erstellen.

Frühere Produktions-Builds werden zu diesem Zeitpunkt nach old_production_ verschoben und die aktuelle prod-Version ist immer nur production. Alles, was unser Build-Server über die Produktion weiß, ist, wie man den Produktionszweig bereitstellt, und wir stoßen diesen Build mit einem Force-Trigger an.

Answer 4

Wir verfolgen den Ansatz Stamm=aktueller Entwicklungsstrom, Zweig=Release(s). Bei der Freigabe an den Kunden verzweigen wir den Stamm und lassen den Stamm einfach weiterlaufen. Sie müssen sich entscheiden, wie viele Versionen Sie unterstützen wollen. Je mehr Sie unterstützen, desto mehr Fehlerbehebungen werden Sie durchführen müssen. Wir versuchen, unsere Kunden auf nicht mehr als 2 Versionen hinter dem Stamm zu halten. (Z.B. Dev = 1.3, unterstützte Versionen 1.2 und 1.1).

Answer 5

Hier ist das SVN-Design, das ich bevorzuge:

• Wurzel
  • Entwicklung
    • Zweigstellen
      • Merkmal1
      • Merkmal2
      • ...
    • Kofferraum
  • beta
    • tags
    • Kofferraum
  • freigeben
    • tags
    • Kofferraum

Die gesamte Arbeit wird von der Entwicklung/dem Stamm erledigt, mit Ausnahme von wichtigen Funktionen, die einen eigenen Zweig erfordern. Nachdem die Arbeit mit dem Entwicklungs-/Stammzweig getestet wurde, werden die getesteten Ausgaben in den Beta-/Stammzweig eingefügt. Falls erforderlich, wird der Code auf dem Beta-Server getestet. Wenn wir bereit sind, einige Änderungen zu veröffentlichen, führen wir die entsprechenden Revisionen in Release/Trunk zusammen und stellen sie bereit.

Tags können im Beta-Zweig oder im Release-Zweig gesetzt werden, damit wir eine bestimmte Version sowohl für Beta als auch für Release im Auge behalten können.

Diese Konstruktion ermöglicht eine große Flexibilität. Es macht es uns auch leicht, Revisionen in beta/trunk zu belassen, während andere in release/trunk zusammengeführt werden, wenn einige Revisionen die Tests in beta nicht bestanden haben.