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"?
Antworten
Zu viele Anzeigen?
Travis B. Hartwell
Punkte
3141
Eine gute Referenz für einen Entwicklungsprozess, der den Stamm stabil hält und alle Arbeiten in Zweigen durchführt, ist Divmods Ultimatives Qualitätsentwicklungssystem . Eine kurze Zusammenfassung:
- Für jede Arbeit muss ein Ticket ausgestellt werden.
- Für jedes Ticket wird ein neuer Zweig erstellt, in dem die Arbeit für dieses Ticket erledigt wird
- Änderungen aus diesem Zweig werden nicht in den Hauptstamm zurückgeführt, ohne von einem anderen Projektmitglied überprüft zu werden.
Sie verwenden dafür SVN, aber das könnte man auch mit jedem anderen verteilten Versionskontrollsystem machen.
Jon Limjap
Punkte
92084
Ich denke, dass Ihr zweiter Ansatz (z.B. die Kennzeichnung von Veröffentlichungen und die Durchführung von Experimenten in Zweigen, wobei der Stamm als stabil betrachtet wird) der beste Ansatz ist.
Es sollte klar sein, dass Zweige alle Fehler eines Systems zu dem Zeitpunkt erben, an dem es verzweigt wird: Wenn Korrekturen auf einen Stamm angewendet werden, müssen Sie einen nach dem anderen auf alle Zweige anwenden, wenn Sie Zweige als eine Art Terminator für den Versionszyklus pflegen. Wenn Sie bereits 20 Versionen hatten und einen Fehler entdeckt haben, der bis zur ersten Version zurückreicht, müssen Sie Ihre Korrektur 20 Mal wiederholen.
Zweige sollen die eigentlichen Sandkästen sein, obwohl auch der Stamm diese Rolle spielen muss: Tags zeigen an, ob der Code zu diesem Zeitpunkt "Gold" ist, geeignet für die Veröffentlichung.
Brian Stewart
Punkte
8870
Wir entwickeln auf dem Stamm, es sei denn, die Änderungen sind zu groß, destabilisierend oder wir stehen kurz vor einer größeren Veröffentlichung eines unserer Produkte. In diesem Fall legen wir einen temporären Zweig an. Außerdem erstellen wir für jede einzelne Produktversion einen permanenten Zweig. Ich fand Microsofts Dokument über Anleitung zur Verzweigung sehr hilfreich. Eric Sink's Tutorium zur Verzweigung ist ebenfalls interessant und weist darauf hin, dass das, was für Microsoft funktioniert, für einige von uns zu schwer sein kann. In unserem Fall war es so, dass wir tatsächlich den Ansatz verwenden, von dem Eric sagt, dass sein Team ihn verfolgt.
Josh Segall
Punkte
3933
Das hängt von Ihrer Situation ab. Wir verwenden Perforce und haben normalerweise mehrere Entwicklungslinien. Der Stamm gilt als "Gold" und die gesamte Entwicklung findet in Zweigen statt, die in die Hauptlinie zurückgeführt werden, wenn sie stabil genug sind, um integriert zu werden. Dies ermöglicht die Ablehnung von Funktionen, die nicht in Frage kommen, und kann im Laufe der Zeit solide inkrementelle Fähigkeiten bieten, die von unabhängigen Projekten/Funktionen übernommen werden können.
Es gibt Integrationskosten für das Zusammenführen und Aufholen neuer Funktionen, die in den Stamm eingefügt werden, aber Sie werden diesen Schmerz sowieso ertragen müssen. Wenn alle gemeinsam auf dem Stamm entwickeln, kann das zu einer Wildwest-Situation führen, während die Verzweigung es Ihnen ermöglicht, zu skalieren und die Punkte zu wählen, an denen Sie die bitteren Integrationspillen schlucken wollen. Wir arbeiten derzeit mit über hundert Entwicklern an einem Dutzend Projekten, jedes mit mehreren Versionen, die dieselben Kernkomponenten verwenden, und es funktioniert ziemlich gut.
Das Schöne daran ist, dass man dies rekursiv machen kann: ein großer Funktionszweig kann ein eigener Stamm sein, von dem andere Zweige abgehen. Außerdem erhalten endgültige Versionen einen neuen Zweig, damit Sie einen Platz für die stabile Wartung haben.
Nicht registrierter Benutzer
Punkte
0
Der Versuch, die Wartung des aktuellen Produktionscodes mit der Neuentwicklung in Einklang zu bringen, ist bestenfalls problematisch. Um diese Probleme zu entschärfen, sollte der Code in eine Wartungslinie verzweigt werden, sobald die Tests abgeschlossen sind und der Code für die Auslieferung bereit ist. Darüber hinaus sollte die Hauptlinie verzweigt werden, um die Stabilisierung der Version zu unterstützen, experimentelle Entwicklungsarbeiten aufzunehmen oder um Entwicklungsarbeiten zu beherbergen, deren Lebenszyklus sich über mehrere Versionen erstreckt.
Ein wartungsfreier Zweig sollte nur dann erstellt werden, wenn die Wahrscheinlichkeit (oder Gewissheit) von Kollisionen zwischen dem Code besteht, die auf andere Weise nur schwer zu bewältigen wären. Wenn der Zweig kein logistisches Problem löst, wird er eines schaffen.
Die normale Entwicklung der Freisetzung erfolgt in der Hauptlinie. Die Entwickler checken für normale Release-Arbeiten in die Mainline ein und aus. Die Entwicklung von Patches für den aktuellen Produktionscode sollte im Zweig für die betreffende Version erfolgen und dann mit der Hauptlinie zusammengeführt werden, sobald der Patch die Tests bestanden hat und eingesetzt wird. Die Arbeit in Nicht-Wartungszweigen sollte von Fall zu Fall koordiniert werden.
