Sollten Sie sich mit SVN-Filialen beschäftigen, wenn Sie nur eine haben?

Wenn wir in Subversion nur mit einem Zweig arbeiten, sollten wir uns dann überhaupt darum kümmern? Können wir nicht einfach am Kofferraum arbeiten, um die Dinge zu beschleunigen?

So entwickeln wir uns mit Subversion:

Es gibt einen Kofferraum
Wir machen einen neuen Entwicklungszweig
Wir entwickeln eine neue Funktion für diesen Zweig
Wenn das Feature fertig ist, wird es im Trunk zusammengeführt, der Zweig wird entfernt und ein neuer Entwicklungszweig wird aus dem Trunk erstellt

Wenn wir für die Produktion freigeben möchten, erstellen wir ein Tag aus dem Kofferraum. Bugfixes werden für einen Zweig dieses Tags vorgenommen. Dieser Bugfix wird dann im Trunk zusammengeführt.

Aus diesem Grund erstellen wir nach Fertigstellung eines Features einen neuen Entwicklungszweig. Auf diese Weise wird der Bugfix früh genug in unseren neuen Code aufgenommen.

Unten ist ein Diagramm, das verdeutlichen sollte:

Unsere Subversion-Strategie

Nun gibt es das Gefühl, dass dies nicht die effizienteste Arbeitsweise ist. Wir bauen vor Ort, bevor wir uns verpflichten, was ungefähr 5-10 Minuten dauert. Sie können verstehen, dass dies eine ziemlich lange Wartezeit ist.

Die Idee eines Entwicklungszweigs ist, dass der Trunk immer Release-fähig ist. Dies gilt jedoch nicht mehr für unsere Situation. Manchmal ist eine Funktion fast fertig, und einige Entwickler beginnen bereits mit der Codierung der nächsten Funktion (andernfalls warten sie darauf, dass ein oder zwei Entwickler fertig sind und zusammengeführt werden).

Wenn Feature 1 beendet ist, wird es in den Trunk eingefügt, wobei jedoch einige Commits von Feature 2 enthalten sind.

Sollten wir uns also überhaupt mit dem Entwicklungszweig beschäftigen, da wir immer nur einen Zweig haben? Ich habe über stammbasierte Entwicklung und Verzweigung nach Abstraktion gelesen, aber die meisten Artikel, die ich gefunden habe, konzentrieren sich auf den Teil Verzweigung nach Abstraktion. Ich habe den Eindruck, dass es sich um große Änderungen handelt, die sich über mehrere Veröffentlichungen erstrecken werden. Dies ist kein Problem, das wir haben.

Was denken Sie? Können wir nur am Kofferraum arbeiten? Das schlimmste Szenario ist (glaube ich), dass wir ein Tag aus dem Kofferraum erstellen und die benötigten Commits auswählen müssen, da einige Commits / Funktionen noch nicht produktionsbereit sind.

svn branching tagging

— Peter
quelle

Ich denke, es wäre besser, wenn Sie mehr als einen Zweig hätten. Eine für jede Funktion. Auf diese Weise können Sie, wenn Sie jemals anfangen, an einer großen Funktion zu arbeiten, die einige Zeit in Anspruch nimmt, keine Fehlerkorrekturen und dergleichen für bereits veröffentlichte Versionen aufhalten.

— Amy Anuszewski

Ein Zweig für jedes Feature scheint es komplizierter zu machen, während wir versuchen, die Komplexität zu reduzieren. Wenn es einen Bugfix gibt (dh für 1.0), kann dies auch für einen aus dem Tag erstellten Zweig erfolgen. Dann können wir diesen Zweig markieren (1.1 erstellen), ihn freigeben und den Bugfix in den Trunk einbinden. Die Entwicklung des großen Features würde am Kofferraum fortgesetzt.

— Peter

Antworten:

IMHO ist es in Ordnung, direkt am Trunk zu arbeiten, wenn Sie in kleinen Schritten festschreiben können und eine kontinuierliche Integration eingerichtet ist, sodass Sie (in angemessenem Umfang) sicherstellen können, dass Ihre Festschreibungen die vorhandenen Funktionen nicht beeinträchtigen. Das machen wir auch in unserem aktuellen Projekt (tatsächlich habe ich in keinem Projekt standardmäßig mit aufgabenspezifischen Zweigen gearbeitet).

Wir erstellen einen Zweig nur vor der Veröffentlichung oder wenn die Implementierung eines Features lange dauert (dh mehrere Iterationen / Versionen umfasst). Die grobe Größe einer Aufgabe kann fast immer gut genug geschätzt werden, so dass wir im Voraus wissen, ob wir einen separaten Zweig dafür benötigen. Wir wissen auch, wie viel Zeit noch vor der nächsten Veröffentlichung verbleibt (wir veröffentlichen Veröffentlichungen ca. alle 2 Monate), sodass leicht erkennbar ist, ob eine Aufgabe in die vor der nächsten Veröffentlichung verfügbare Zeit passt oder nicht. Im Zweifelsfall verschieben wir es, bis der Release-Zweig erstellt ist. Dann ist es in Ordnung, mit der Arbeit am Trunk zu beginnen. Bisher mussten wir nur einmal (in ca. 3 Jahren) einen aufgabenspezifischen Zweig erstellen. Natürlich kann Ihr Projekt anders sein.

— Péter Török
quelle

Ich bin bei Peter. Wir haben einen Zweig für jede unterstützte Version, arbeiten aber ansonsten im Trunk. Wir verwenden auch die kontinuierliche Integration. Beachten Sie jedoch, dass dies nur bedeutet, dass es kompiliert wird und nicht, dass vorhandene Funktionen auch bei Komponententests nicht beschädigt wurden.

— Ian

@ Ian, natürlich kann kein Test im wirklichen Leben sicherstellen, dass der Code 100% fehlerfrei ist. Mit begrenzten Ressourcen streben wir ein angemessenes Sicherheitsniveau an (dessen Definition domänen- und projektspezifisch ist). Beachten Sie auch, dass CI auch Integrationstests usw. ausführen kann, nicht nur Komponententests.

— Péter Török

Dies funktioniert so lange, bis es fehlschlägt. Wenn Sie einen Fix implementieren müssen, bevor das neue Feature bereit ist ... Oder wenn ein neues Feature-Release nicht so bereit für die Primetime war, wie Sie dachten, wird es viel schwieriger, diese Änderung aus dem Code heraus zu sichern, wenn Sie keine Verzweigung verwenden.

— SoylentGray

@Chad, Patches für die neueste Version werden im entsprechenden Release-Zweig ohne Störung durch den Trunk durchgeführt. Und wir testen neue Funktionen ziemlich ausführlich, damit wir wissen, wann sie zur Hauptsendezeit bereit sind. Zugegeben, wir haben relativ wenige große Funktionen in unserem Projekt. Und da es sich um eine serverseitige Web-App handelt, ist es ziemlich einfach, ein DB-Flag hinzuzufügen, um Funktionen selektiv ein- und auszuschalten. YMMV.

— Péter Török

LOL ok Ich habe es falsch verstanden und dachte, Sie hätten gerade den Kofferraum (mit einer Ausnahme). Ich habe diese Methode auch verwendet. Sie ist in Ordnung für eine kleine Gruppe und häufige kleine Veröffentlichungen. Es hat nicht gut funktioniert, wenn wir regelmäßig große Veröffentlichungen (3-6 Monate) durchgeführt haben ) Intervalle.

— SoylentGray

Was Sie mit Ihrer Feature-Entwicklung beschreiben, ist die parallele Entwicklung (gleichzeitige Entwicklung für verschiedene Produktversionen), für deren ordnungsgemäße Handhabung Zweigstellen erforderlich sind. Sie können entweder für jede Version oder für jede Funktion einen Zweig haben, wenn Sie häufig die Funktionen neu zusammenstellen müssen, die eine bestimmte Version erstellen.

Die andere Möglichkeit, dies zu tun, besteht darin, standardmäßig außerhalb des Trunks zu arbeiten, aber einen Zweig zu erstellen, wenn Sie erwarten, dass sich Ihre Aufgabe über die nächste Version hinaus erstreckt. Sie markieren natürlich immer die Veröffentlichung.

Welchen Ansatz Sie wirklich wählen, hängt davon ab, wie viel Management Sie im Voraus leisten können. Wenn die typische Version nicht wirklich parallel entwickelt wird, würde ich den zweiten Ansatz wählen.

— Jeremy
quelle

Ich stimme zu und OP bestätigte dies mit: "Manchmal ist eine Funktion fast fertig und einige Entwickler beginnen bereits mit der Codierung der nächsten Funktion ..."

— Chris

Ja, aber wir müssen nie wieder zusammensetzen. Die Funktionen sind chronologisch implementiert, und beispielsweise müssen die Funktionen 1 bis 4 alle in der nächsten Version enthalten sein (z. B. 1.0). Dies könnte nur dann problematisch sein, wenn die Entwicklung von Feature 5 begonnen hat, das für die Veröffentlichung danach vorgesehen ist (2.0). Dann müssen wir sicherstellen, dass diese Änderungen nicht im Tag / Release (1.0) berücksichtigt werden. Das Erstellen eines Zweigs vor der Veröffentlichung könnte dies tatsächlich beheben.

— Peter