171 Stimmen

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

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"?

152voto

Brian R. Bondy Punkte 325712

Ich habe beide Methoden mit einer großen kommerziellen Anwendung ausprobiert.

Die Antwort auf die Frage, welche Methode besser ist, hängt in hohem Maße von Ihrer genauen Situation ab, aber ich werde schreiben, was meine allgemeine Erfahrung bisher gezeigt hat.

Die insgesamt bessere Methode (meiner Erfahrung nach): Der Kofferraum sollte immer stabil sein.

Hier sind einige Leitlinien und Vorteile dieser Methode:

  • Kodieren Sie jede Aufgabe (oder verwandte Aufgaben) in einem eigenen Zweig, dann haben Sie die Flexibilität, wann Sie diese Aufgaben zusammenführen und eine Freigabe durchführen möchten.
  • Die Qualitätssicherung sollte für jeden Zweig durchgeführt werden, bevor er mit dem Stamm zusammengeführt wird.
  • Indem Sie die Qualitätssicherung für jeden einzelnen Zweig durchführen, können Sie leichter feststellen, was den Fehler verursacht hat.
  • Diese Lösung ist für eine beliebige Anzahl von Entwicklern geeignet.
  • Diese Methode funktioniert, da das Verzweigen in SVN eine fast sofortige Operation ist.
  • Kennzeichnen Sie jede Freigabe, die Sie durchführen.
  • Sie können Funktionen entwickeln, die Sie eine Zeit lang nicht veröffentlichen wollen, und genau entscheiden, wann Sie sie zusammenführen.
  • Für alle Arbeiten, die Sie durchführen, können Sie den Vorteil haben, dass Sie Ihren Code festschreiben. Wenn Sie nur aus dem Stamm heraus arbeiten, werden Sie Ihren Code wahrscheinlich oft nicht committen und damit ungeschützt und ohne automatische Historie lassen.

Wenn Sie versuchen, das Gegenteil zu tun und Ihre gesamte Entwicklung im Stamm zu machen, werden Sie die folgenden Probleme haben:

  • Ständige Build-Probleme bei täglichen Builds
  • Produktivitätsverluste, wenn ein Entwickler ein Problem für alle anderen Projektmitarbeiter festschreibt
  • Längere Release-Zyklen, weil man endlich eine stabile Version haben muss
  • Weniger stabile Veröffentlichungen

Sie haben einfach nicht die Flexibilität, die Sie brauchen, wenn Sie versuchen, einen Zweig stabil zu halten und den Stamm als Sandkasten für die Entwicklung zu verwenden. Der Grund dafür ist, dass Sie nicht aus dem Stamm auswählen können, was Sie in die stabile Version aufnehmen wollen. Es wäre bereits alles im Stamm vermischt.

Der einzige Fall, in dem ich empfehlen würde, die gesamte Entwicklung im Stamm durchzuführen, ist, wenn Sie ein neues Projekt beginnen. Es kann auch andere Fälle geben, je nach Ihrer Situation.


Übrigens bieten verteilte Versionskontrollsysteme viel mehr Flexibilität und ich empfehle dringend, entweder zu hg oder git zu wechseln.

35 Stimmen

Entschuldigung, aber diese Antwort ist falsch. Die gesamte Entwicklung sollte im Stamm erfolgen. Wenn Sie etwas zu "spiken" haben oder eine "riskante" Funktion, erstellen Sie einen Funktionszweig. Zweige sollten für jede Version des Produkts in der Produktion gepflegt werden, oder wenn es nur eine Version gibt, verwenden Sie einen Integrationszweig.

52 Stimmen

Ich habe nicht behauptet, dass dies der einzige Weg ist, sondern nur, dass es der bessere Weg ist. Wenn Sie genug Gründe haben, warum Sie glauben, dass ich falsch liege, dann sollten Sie sie natürlich nennen. Zumindest ist meine Antwort gerechtfertigt.

2 Stimmen

Es gibt nur ein Problem mit dieser Methode für DB-Anwendungen. SQL-Migrationsskripte, die zu Zweigen hinzugefügt, zum Stamm zusammengeführt und auf Produktionsdatenbanken ausgeführt werden, müssen in der Erstellungsreihenfolge ausgeführt werden. Das ist bei Feature-Zweigen schwierig.

66voto

Rob Wells Punkte 35303

Ich habe mit beiden Techniken gearbeitet und würde sagen, dass die Entwicklung auf dem Stamm und die Abzweigung von stabilen Punkten als Releases der beste Weg ist.

Diejenigen, die oben eingewendet haben, dass Sie das haben werden:

  • Ständige Build-Probleme bei täglichen Builds
  • Produktivitätsverlust, wenn ein Entwickler ein Problem für alle festlegt anderen Personen im Projekt

haben wahrscheinlich keine Techniken der kontinuierlichen Integration eingesetzt.

Es ist wahr, dass, wenn Sie nicht mehrere Test-Builds während des Tages, sagen wir einmal jede Stunde oder so, wird sich offen für diese Probleme, die schnell strangulieren das Tempo der Entwicklung zu verlassen.

Wenn Sie tagsüber mehrere Test-Builds erstellen, können Sie schnell Aktualisierungen in die Hauptcodebasis einfließen lassen, so dass andere sie nutzen können, und Sie werden während des Tages benachrichtigt, wenn jemand einen Fehler im Build hat, so dass er ihn beheben kann, bevor er nach Hause geht.

Wie bereits erwähnt, ist es töricht, von einem fehlerhaften Build erst dann zu erfahren, wenn der nächtliche Build für die Durchführung der Regressionstests fehlschlägt, denn dadurch wird die Entwicklung schnell verlangsamt.

Lesen Sie den Artikel von Martin Fowler über Kontinuierliche Integration . Wir haben unser eigenes solches System für ein großes Projekt (3.000kSLOC) in etwa 2.000 Zeilen Posix sh entwickelt.

1 Stimmen

Was hat "kontinuierliche Integration" mit der Wahrscheinlichkeit zu tun, dass ein Team mit seiner Funktion im Verzug ist und einen ganzen Veröffentlichungszyklus verzögert? Es ist der beste Weg "für Sie" zu gehen! Mehrere Builds pro Tag zu machen, löst keine potentiellen Probleme, außer dass man weiß, es wird gebaut! Ihre Argumente liefern keinen Beweis dafür, dass dies der bessere Weg ist (obwohl ich es normalerweise auch so mache).

0 Stimmen

CI ist für diese Antwort, aber auch für die von Brian notwendig.

2 Stimmen

@Jeach, wenn Sie mehrere Builds pro Tag durchführen, können Sie sich darauf verlassen, dass das Projekt so gebaut wird, dass Sie regelmäßig Tests durchführen können, entweder einfache Smkoke-Tests am Tag oder Regressionstests am Abend. Wenn Sie den Build bis zum abendlichen Build für die Regressionstests aufschieben, können Sie das gesamte Projekt um einen Tag zurückwerfen, nur weil Sie den Build nicht durchführen können. Das bedeutet, dass alle Entwickler nicht in der Lage sind, die Ergebnisse der Regressionstests für den neuen Code, den sie eingereicht haben, zu sehen. Das ist eine ziemlich teure Angelegenheit, nur weil zum Beispiel jemand einen Code mit einem Syntaxfehler eingecheckt hat.

36voto

Matt Dillard Punkte 14449

Ich neige dazu, den "Release Branch"-Ansatz zu verfolgen. Der Stamm ist flüchtig. Sobald der Zeitpunkt der Veröffentlichung näher rückt, würde ich einen Versionszweig erstellen, den ich vorsichtiger behandeln würde. Wenn dieser endlich fertig ist, würde ich den Zustand des Repositorys mit einem Label/Tag versehen, damit ich die "offizielle" veröffentlichte Version kenne.

Ich weiß, dass es auch andere Möglichkeiten gibt - ich habe es in der Vergangenheit einfach so gemacht.

19voto

Andrew Edgecombe Punkte 37795

Beides.

Der Stamm wird für den Großteil der Entwicklung verwendet. Es wird jedoch erwartet, dass die besten Anstrengungen unternommen werden, um sicherzustellen, dass jeder Check-in in den Stamm diesen nicht beschädigt. (teilweise verifiziert durch ein automatisiertes Build- und Testsystem)

Releases werden in einem eigenen Verzeichnis gepflegt, wobei nur Fehlerkorrekturen vorgenommen werden (und dann in den Stamm eingebunden werden).

Jede neue Funktion, die den Stamm in einem instabilen oder nicht funktionierenden Zustand belässt, wird in einem separaten Zweig erstellt und nach Fertigstellung in den Stamm integriert.

14voto

Pascal Thivent Punkte 548176

Ich mag und verwende den von Henrik Kniberg beschriebenen Ansatz in Versionskontrolle für mehrere agile Teams . Henrik hat großartige Arbeit geleistet, indem er erklärt hat wie man die Versionskontrolle in einer agilen Umgebung mit mehreren Teams handhabt (funktioniert auch für einzelne Teams in traditionellen Umgebungen) und es hat keinen Sinn, ihn zu paraphrasieren, also werde ich einfach den "Spickzettel" (der selbsterklärend ist) unten veröffentlichen:

alt text alt text

Ich mag es, weil:

  • Es ist ganz einfach: Sie können es dem Bild entnehmen.
  • Es funktioniert (und skaliert) gut, ohne dass es zu viele Probleme mit Zusammenschlüssen und Konflikten gibt.
  • Sie können jederzeit "funktionierende Software" freigeben (im Sinne des agilen Ansatzes).

Und nur für den Fall, dass es nicht deutlich genug war: Die Entwicklung findet in "Arbeitszweigen" statt, der Stamm wird für FERTIGEN (veröffentlichungsfähigen) Code verwendet. Prüfen Sie Versionskontrolle für mehrere agile Teams für alle Einzelheiten.

0 Stimmen

Meine persönliche Erfahrung ist, dass dies NUR für kleine Teams funktioniert, im Gegensatz zu Ihrer Bemerkung "es lässt sich skalieren". Wenn die Teams wachsen und die Geschichten neu geordnet werden, verbringen alle anderen Teams beträchtliche Mengen an Teamarbeit mit Merges. Und bei sehr großen Projekten (viele Dateien und KLOC) tauchen regelmäßig Merge-Probleme auf, vor allem, wenn der Code stark schwankt.

0 Stimmen

@Jeach Bei einem großen Projekt mit 5 Teams, die in Feature-Teams organisiert sind, hat es bei uns gut funktioniert, obwohl ich nicht leugne, dass das Zusammenführen mit Kosten verbunden ist.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X