Zweige für jede kleine Veränderung?

Question

Wir haben einen Client (der einen Client hat, der einen Client hat), der uns mit Change Requests zu einer Code Base (in PHP) verführt. Unsere erste Antwort war, einfach in einem Haupt-Trunk in SVN zu arbeiten, aber der Client kommt oft zurück und fordert, dass eine bestimmte Änderung so schnell wie möglich an die Live-Server weitergeleitet werden muss. Auf der anderen Seite werden andere Änderungen plötzlich in der Priorität reduziert, die ursprünglich (scheinbar) mit anderen Änderungen gruppiert wurden.

Wir denken über eine Verzweigung für jede Änderungsanforderung. Ist das verrückt? Welche anderen Lösungen könnten funktionieren?

Danke!

Bearbeiten: Das ist eine wirklich schwierige Frage, um die richtige Antwort zu wählen. Danke an alle für eure tollen Antworten.

Bearbeiten: Ich weiß, dass die beste Antwort, die ich wählte, nicht besonders beliebt war. Auch ich wollte eine technische Lösung für dieses Problem finden. Aber jetzt denke ich, dass, wenn der Kunde Software mit Funktionen wünscht, die in einer modularen Weise eingesetzt werden können ... sollte dieses Problem nicht in unserem Gebrauch des Versionskontrollsystems gelöst werden. Es müsste in die Software integriert werden.

Bearbeiten: Jetzt ist es fast einen Monat später und mein Kollege/Kunde hat mich davon überzeugt, dass mehrere Zweige der Weg zu gehen ist. Dies liegt nicht nur an der Unzurechnungsfähigkeit des Kunden, sondern auch daran, dass wir feststellen müssen, ob eine Funktion "bereit ist" oder "mehr Arbeit benötigt" oder was auch immer. Ich habe das SVN nicht bei mir, aber wir verschmelzen mit dem Ratschlag aus dem SVN-Kochbuch: Sie verschmelzen den Zweig von die Revision, die es in die Hauptversion verzweigt wurde.

Mit diesem System fusionieren wir auch alle Zweige an einem Punkt und das wird die neue QA und dann Live-Build. Dann verzweigen wir uns davon.

Letzte Änderung (Vielleicht): Monate später funktioniert dieses System noch für uns. Wir erstellen Filialen für jedes Ticket und haben selten Probleme. Auf der anderen Seite versuchen wir, die Dinge getrennt zu halten, was die Leute arbeiten ...

Zwei Jahre später: Wir verwenden jetzt GIT, und jetzt ist dieses System eigentlich ganz vernünftig.

Answer 1

Ein Zweig für jede Änderungsanforderung klingt wie Overkill und vielleicht später ein Problem.

versuchen Sie, die Änderungsanforderungen in logische Bereiche zu gruppieren, damit Sie sehen können, dass eine bestimmte Gruppe von Änderungen eine logisch verwandte Auswirkung auf die Anwendung hat. Erstellen Sie Zweige für diese.

Ich denke, dass die eigentliche Antwort auf die Frage ist beheben Sie den Client. Sie müssen über einen Vertrag klarstellen, dass diese willkürliche Änderungsanfrage ihnen Geld kostet und sie verlangsamen könnte. Wenn dies so bleibt, wird Ihr svn-Repository der am wenigsten störende Aspekt des Projekts sein.

Answer 2

Wie wäre es mit einem Zweig für die Live-Version Ihres Kunden, einem Zweig für Ihre neue Entwicklung und einem Zweig für Ihre laufenden Änderungen.

Arbeiten Sie in der neuen Entwicklungsabteilung, wenn Sie nicht mit Aufgaben überschwemmt werden.

Arbeiten Sie in den laufenden Änderungen Zweig, wenn Sie all die Spaß Sachen reparieren, die sie fahren Sie verrückt mit. Wenn Sie einen Fix haben, verbinden Sie ihn mit dem Zweig "live" und dem Zweig "new development".

Auf diese Weise ist die Distribution Ihres Kunden in einer eigenen Welt, Ihre neue Entwicklung wird fortgesetzt (und kann bei Bedarf zusammengeführt werden) und Ihre Wartung wird ebenfalls erfasst.

Wir arbeiten in einem neuen Entwicklungszweig, und jedes Mal, wenn wir uns entscheiden, einen Patch zu machen, verzweigen wir den Trunk und senden dann diesen Patch für Q/A ab. Wenn es eine Weile hin und her geht, arbeiten wir in diesem Zweig, um die Probleme zu beheben, die zurück in den Trunk münden, um sicherzustellen, dass alles synchron ist.Wenn etwas lange nach der Tatsache zurückkam, die in einer früheren Version behandelt werden musste, können wir es immer wieder in diesem Zweig reparieren und dann wieder einfach in den Stamm einfügen.

Answer 3

Branch per Change Request, mit der entsprechenden Erhöhung der Kosten für den Client für die zusätzliche Verwaltung, ist ein guter Ansatz für dieses Problem.

Es kostet Sie mehr, in Bezug auf die Zeit, verfügbare Ressourcen für die Arbeit an anderen Funktionen, etc., aber mit vielen nicht verwandten Änderungen oder Projektfunktionen, die zum Stillstand kommen oder abgebrochen werden, ist es wahrscheinlich einer der besseren Ansätze.

Dies ist wirklich SCM-System Agnostiker - aber Subversion kann sicherlich tun, was benötigt wird.

Answer 4

Vielleicht ist Subversion hier nicht das beste Werkzeug für den Job. Obwohl die Erstellung all dieser Zweige in SVN billig ist, kann das erneute Zusammenführen zeitaufwändig und schmerzhaft werden.

Wenn Sie sich GIT anstelle von SVN ansehen, finden Sie ein Versionskontrollsystem, das beim Zusammenführen im Allgemeinen leistungsfähiger ist. Hinzu kommt die Besonderheit des "Rosinenpickens". Das heißt, einzelne Commits können leicht aus einem Entwicklungsbaum "ausgewählt" und zu einem anderen (dem Live-Zweig) hinzugefügt werden. Außerdem ist es in GIT einfach und bequem, mehrere Commits in einen einzigen zusammenzufassen (Sie können sogar zu einem bestimmten Commit aus einer anderen Struktur hinzufügen).

Die Erstellung von Einzelmerkmals-Commits und die anschließende Auswahl der richtigen Option könnte die Lösung für Sie sein.

Answer 5

Zweig pro getestet, funktioniert ändern.
Tag pro Versionsversion.
Im Kofferraum entwickeln.
Wiederholen.

:)

Answer 6

Wenn dabei viel raschen Veränderungen in der „Live“ Zweig eines Projekts, benötigen Sie einen festen Code-Review-Prozess haben die Chance, es zu brechen zu reduzieren. Die Code-Überprüfung muss vor dem Check-in durchgeführt werden. und halten Sie die Kernentwicklung von diesem Zweig fern.

Sobald die Änderung genehmigt wurde, können Sie die Änderung einchecken (und/oder aus Ihrem Arbeitszweig zusammenführen) und ein neues "Tag" erstellen, sobald es fertig ist.

Answer 7

An meinem Arbeitsplatz haben wir das folgende System:

• Stable-Zweig: Hier wird getestet und überprüft stabilen Code geht.
• Wartungszweig: Dies ist, wo Fehler in Stable behoben wird. Wenn die Arbeit verifiziert ist, wird sie in einen stabilen Zweig zusammengeführt.
• Projektspezifische Zweige: Jedes Teilprojekt in unserem Produkt hat einen Zweig. Zu einer bestimmten Zeit im Jahr werden alle Projekte, die in diesem Jahr veröffentlicht werden sollen, in die "Release Branch" zusammengeführt. Dies ist so alles Verschmelzen und Zeug ist nicht eine Woche vor der Veröffentlichung getan.
• Release-Zweig: Dies ist, wo alle die schmutzige Entwicklung des aktuellen Release passiert, nachdem die Teilprojekte zusammengeführt wurden. Zusammengeführt mit stabil nach der Veröffentlichung ist fertig.

Answer 8

Haben Sie eine Verzweigung für jede Freigabe. Kombiniere so viele Änderungen in einer einzigen Veröffentlichung, wie sinnvoll - mehr Zweige zu haben ist im Allgemeinen gut, du kannst sie in den meisten Fällen leicht kombinieren, ein Auseinanderbrechen ist etwas komplizierter.

Wenn Sie für jede Version eine Verzweigung haben, haben Sie auch eine Verzweigung für die aktuelle Produktion (oder was gerade veröffentlicht wird, wenn die Releases nach der Zusammenführung, aber vor der eigentlichen Bereitstellung anstehen).

Das machen wir sowieso.

Answer 9

Das Szenario durch den Thread Opener erklärt ist ein Beispiel für das Mustermerkmal Zweige: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature

Sie sind sehr usefule, wenn Sie die Hauptentwicklungslinie halten müssen (der Stamm) stabil, und Sie haben zu entwickeln, viele Features, die möglicherweise die Hauptlinie brechen könnten. Der Nachteil besteht darin, dass Sie die verschiedenen Zweige synchron mit dem Trunk halten müssen: Während sich ein Zweig für Feature A in Entwicklung befindet, kann ein Zweig für Feature B einen stabilen Status erreicht haben und geschlossen und im Trunk zusammengeführt werden In diesem Fall müssen Sie die Änderungen, die durch die B-Verzweigung vom Stamm in die A-Verzweigung eingeführt wurden, zusammenführen. Also, es ist eine gute Angewohnheit, die Zweige oft mit dem Stamm zu verschmelzen, um die problematische Situation einer einzigartigen großen Zusammenführung am Ende des Lebens zu vermeiden, mit vielen Konflikten, die man aufspüren und lösen kann.

Answer 10

Wenn geschätzte Stunden mehr als 8 sind, verwenden Sie eine Verzweigung.

Answer 11

Mit Git, ich tun machen Sie einen Zweig für jede kleine Veränderung, und ich liebe es!