Refactoring und gleichzeitig Entwicklungszweige

Question

Angenommen, Sie haben mehrere Wartungs Zweige für bestehende Versionen Ihrer Software haben. Einige Entwickler machen direkte Änderungen in den Wartungs Filialen und in regelmäßigen Abständen in den Kofferraum zu verschmelzen. Jetzt kommt ein umfangreiches Refactoring im Kofferraum Kodierzeilen, für eine anstehende Major-Release geplant. Aber das macht die Wartung Zweige grundsätzlich unvereinbar mit dem Code im Kofferraum, da sie auf Code abhängen könnten, die nicht mehr existiert, zum Beispiel.

Wie gehen Sie mit dieser Situation in der Praxis aus?

Answer 1

Ich würde es in der Verantwortung der Branche Wartung Entwickler betrachtet die entsprechende Änderung in den aktuellen Zustand des Rumpfes zu verschmelzen. Es gibt mehrere Möglichkeiten:

1. Der Code im Kofferraum hat sich nicht geändert und der Patch gilt ohne Konflikte.
2. Der Code im Kofferraum hat sich geändert und der Patch gilt, aber mit einem manuellen Zusammenführung erforderlich.
3. Der Code im Kofferraum komplett geändert hat und der Patch nicht anwenden. Der Entwickler muss beurteilen, ob der gleiche Defekt im Kofferraum vorhanden ist, und eine äquivalente Update anwenden, wenn nötig.

Die Fälle 1 und 2 sind die üblichen Wartungsentwicklungspfade. Fall 3 ist der Fall, dass Sie erwägen, wo der Code Stamm nicht den Wartungs Patch in irgendeiner Form annehmen kann. Wenn der Entwickler kann sich nicht feststellen, ob das gleiche Problem in den Kofferraum existieren könnte, dann sollte er ein Problem in den Issue-Tracking-System eingeben. Dieses Problem würde die Stamm-Entwickler richten, den Grund für den Patch in dem Wartungszweig und ob der gleiche Defekt vorliegen könnte noch zu berücksichtigen. Die Eingabe eine neue Ausgabe für eine möglich Defekt im Kofferraum ein letzter Ausweg für die Wartung Entwickler sein solle.

Ein Vorteil einer Wartung Entwickler versuchen, Patches anzuwenden, um die aktualisierte Stamm ihre Vertrautheit mit dem neuen Code-Basis zu erhöhen. Irgendwann werden sie aus Wartungsarbeiten ausgeführt werden und wird mit dem neuen Stamm arbeiten müssen. zumindest mit einer grundlegenden Ebene der Vertrautheit von großem Nutzen sein wird.

Answer 2

Dies ist letztlich eine Frage über die Kommunikation im Team, sondern als eine einfache Verzweigung / Zusammenführung Frage.

Der erste Schritt, wie in allen solchen Fällen ist zu erkennen, dass Sie ein Problem haben. Dies ist etwas, was Sie getan haben.

Dann müssen Sie das gesamte Team auf die Frage aufmerksam zu machen.

Wenn Sie das getan haben, ich denke, es gibt zwei verschiedene Wege:

1. Wenn die Wartungs Zweige selten verwendet werden, sagt der freigegebene Code ziemlich ausgereift ist und fehlerfrei, können Sie auf einem Code-Freeze entscheiden. Jeder Entwickler muss beenden, was er / sie arbeitet an um 32 Octember, und mischen Sie die Änderungen zurück in den Kofferraum. Die Zweige sollten dann entweder geschlossen oder gefroren sein. Dann kann die Arbeit in dem Kofferraum fortsetzen, und die neue Software freigegeben werden kann.

2. Wenn es häufige oder dringende Änderungen und Korrekturen in den Zweigen, dieses Problem komplizierter. Es muss noch ein Code-Freeze sein, oder der Stamm wird mehrmals verprügelt werden. Aber hier müssen Entwickler immer noch Dinge beheben in der Zwischenzeit und sie an Kunden aus. Ich schlage vor, dass jede Änderung in den Zweigen nach dem AKZ Einfrieren sollte in der Bug-Tracking-Datenbank (ein Muss in jeder Situation) aufgezeichnet werden, mit einem besonderen Hinweis darauf, dass diese in Zweig befestigt wurden N, aber noch nicht mit dem Stamm zusammengeführt. Dies erfordert eine sorgfältige Protokollierung, so dass jedes relevantes Detail erinnert wird.

   Nachdem die Stamm Refactoring ist, aber bevor es gereinigt wird, buffed, markiert und freigegeben, die Bug-Datenbank überprüfen, insbesondere die Elemente in den Zweigen befestigt, aber nicht der Stamm. Sind sie noch relevant? Jetzt ist die Zeit wieder, den Code zu ändern, falls erforderlich. Es kann doppelte Arbeit für kurze Zeit bedeuten, aber hoffentlich der Code ist viel besser verwaltbar jetzt.

   Nachdem alle bekannten Probleme behoben sind, kann die neue Version veröffentlicht werden, und die alten Zweige geschlossen werden kann.

Answer 3

Die einzige Antwort, ich in der Lage gewesen war, mit zu kommen ist ein wartungs Stamm Zweig zu erstellen, bevor Sie Refactoring starten. Sie pflegen diese Niederlassung als ob es ein Stamm waren, Änderungen und Release Filialen als normal zu verschmelzen. In Zukunft Sie dann vorsichtig sein, ändert sich von den alten und neuen Quelle Basen zu mischen.

Die andere Alternative ist, etwas zu versuchen, wie MolhadoRef ( Blog-Artikel über MolhadoRef und Refactoring-aware SCM ), wenn Sie eine fertig-für-Produktion finden gleichwertiges System, das Ihre Bedürfnisse entspricht. Dies ist in der Theorie, Refactoring-aware Quellcodeverwaltung. Ich habe nicht in ihn eine Zeit lang sah aber zuletzt Ich erinnere mich, es von immer noch ziemlich weit war etwas mehr als ein Forschungspapier und Proof-of-Concept zu sein.

Answer 4

In der Praxis können Sie zusätzliche Arbeit zu tun haben, um Ihre neue Änderungen rückwärts kompatibel zu machen.

• Schritt 1: Starten Sie die Komponente Refactoring. Mit jedem Schritt, halten Sie die alte Schnittstelle um, aber haben es Anrufe an die neue Implementierung migrieren. Beachten Sie, dass dies in mehreren Schritten durchgeführt werden kann, wie die neue Schnittstelle / API aufgebaut ist. Unit-Tests sollte kann, dass die Migration überprüfen, von alten zu neuen Arbeiten richtig, aber dieser Schritt wird höchstwahrscheinlich noch Test / QA-Overhead möglich.

• Schritt 2: Die neue Version ist in der Produktion leben; stellen Sie sicher, jeder kennt es. Zu diesem Zeitpunkt werden keine neuen Funktionen der alten Version hinzugefügt, und alle neuen (oder geändert) Anrufer nutzen die neue Version.

• Schritt 3: Finden Sie alles (verwenden Werkzeuge, dies zu tun), die die alte Schnittstelle aufruft, und alles ändern, um die neue Schnittstelle zu nennen. Dies verursacht wahrscheinlich eine Menge Tests / QA-Overhead zu. Jeder Anrufer kann einen nach dem anderen begangen / freigegeben werden, wenn.

• Schritt 4: An diesem Punkt ist die neue Version ist live, und es gibt keine Anrufer hinterlassen, die die alte Version zugreifen. Löschen Sie es sicher.

Beachten Sie, dass, wo die API öffentlich ist, und Sie haben keine Kontrolle über die Menschen, die es nennen (Firmen wie Microsoft, zum Beispiel), könnten Sie nie in der Lage seiner Vergangenheit Schritt # 2 zu gehen.

Dieser Prozess kann langsam sein, und es erfordert eine Menge Disziplin, Kommunikation und Testen. Aber in Fällen, in denen die alternativen catch-up / Integration immer spielen, könnte es eine vernünftige Option sein.

Answer 5

Da ein großer Teil der Kosten um einen Fehler der Behebung des Problems ist die Reproduktion und das Update zu testen. Können Sie einen automatisierten Test schreiben, der in allen Zweigen, auch wenn der Code fix anders für jeden Zweig getan werden, arbeiten muss?

Answer 6

An dem Punkt, dass Ihre Wartungs Zweige sind nicht mehr kompatibel mit dem Hauptstamm, wäre es an der Zeit zu schaffen, neue Filialen zu diesem Zweck sein. Das heißt, zu Beginn des großen Projektes, Sie sicherstellen, dass alle Ihre Entwickler bewusst sind, dass neue Funktionen in dem Hauptstamm kommen, so dass sie eine bessere Wahl treffen können, wo Korrekturen zu implementieren. Vermutlich, wenn die Code-Änderungen im Hauptstamm auftretenden so bedeutend sind wie die Wartung nicht erträglich zu machen, dann sollte die Wartung in den Hauptstamm aufgenommen werden.

Answer 7

Erstellen Sie eine Wartung Zweig und haben es als Puffer zwischen Stamm handeln und die Versionszweige.

Änderungen der Version-Filialen gehen in den Wartungs Zweig, und dann propegate in dem Stamm nur dann, wenn sie können, und umgekehrt.

Ich glaube nicht, gibt es eine silberne Kugel, though. Da Zweige mehr und mehr auseinanderlaufen, werden sie unvereinbar wachsen und so müssen Sie überlegen, wie lange unterstützen Sie sie. Ansonsten könnten Sie Fehler mehr als einmal, aber etwas anders für die verschiedenen Zweige am Ende zu fixieren.

Answer 8

Dies kann eine sehr intensive Vorschlag arbeiten, aber das erste, was mir in den Sinn kommt, ist alles wieder in den Kofferraum zu verschmelzen. Jeder Änderungen gehen an den Stamm Kopie verschmolzen zurück und halten sie alle zusammen. Dann Refactoring auf den Stamm, wie Sie wollen. Jetzt haben Sie einen Arbeits Stamm, mit allen Updates zusammen.

Leider würde dies bedeuten, dass alle Korrekturen in den Wartungs Zweigen müßten zusammen zu bekommen geworfen und in den zentralen Stamm. Ich weiß, das eine ganze Menge Arbeit sein würde, aber ich denke, dass dies alles Refactoring erlauben würde, und alle Verbesserungen in der Pflege Filialen würden im Hauptzweig gehören. Ich kann über diese naiv sein, aber ich habe nicht wirklich auf einem Produktions Projekt gearbeitet, und auch nicht genau wissen, was auf der Wartung Filialen ist. Ich stelle dar, dies würde der Stamm vollständig aktualisiert machen und alle Ihre Wartung Verbesserungen würden in den Kofferraum integriert werden.

ich es auf diese Weise Figur tun würde die Qualität aller Ihrer Filialen maximieren und Ihre Refactoring alle Zweige verteilt auf Sie nach dem Refactoring verzweigen würde. Dies wäre eine gute Möglichkeit, Ihr Team für die Verschmelzung zusammen zu bringen, wie gut.

Answer 9

Ich sehe zwei getrennte Wege, dies zu bewältigen:

1.

Wesentliche Änderungen an den Stamm (wie eine große Refactoring) nicht im Kofferraum erfolgen. Sie sollten in einem Zweig und verschmolzen zurück in den Kofferraum durchgeführt werden, wenn sie stabil genug sind, um.

In regelmäßigen Abständen die Änderungen an den Stamm sollte mit den anderen Pflegezweige zusammengeführt werden. Der Grund für die nur das Refactoring in den Kofferraum verschmelzen, wenn es stabil ist, weil diese dann in die Wartung Zweige zusammen bekommen. Wenn jedoch keine Möglichkeit besteht, diese Änderungen zu machen stabil dann Option 2 wäre besser.

Nach Änderungen an den Wartungs Zweige vorgenommen wurden sie dann wieder in den Stamm zusammengeführt werden.

2.

Erstellen Sie einen Zweig der Wartungszweige (ein Zweig für jeden). Dies wird für die Zusammenführung des Stammes mit jedem Wartungs Zweig verwendet werden. (Man beachte, dass die Verwendung von SVN Externen oder gleichwertig soll verwendet werden, um die Anzahl der Wartungs Zweige zu begrenzen).

Haben alle Ihre Refactoring im Kofferraum und verschmelzen diese in den Zweigen der Wartung Zweige. Beim Loslassen oder denken, dass der Rumpf stabil ist dann diese Zweige der Wartungsversionen fusionieren zurück in ihre jeweiligen Niederlassungen. Diese können dann wiederum zusammengeführt werden zurück in den Kofferraum.

In der Tat jede Wartung Zweig wird zu einem "Unterstamm".

Beachten Sie, dass dieses Szenario den Kompromiss zwischen der künftigen Wartung und Instandhaltung im Voraus hervorhebt. Je mehr Zweige und Unterschiede, die Sie in Ihrem Code haben, sind das mehr im Vorfeld Wartung erforderlich. Das Gute ist, dass inkrementelle Wartung ist viel einfacher.

Answer 10

Ich kann nur wiederholen, was andere gesagt haben, während die echte Schmerzen in den einer Betonung $$, dass Patch-Warteschlangen werden können.

Wenn Sie eine vordefinierte (und Iron Clad) fusionieren Fenster, nur zwei Wochen nach der Hölle haben sollte zu behandeln.

Answer 11

Ich denke, die beste Wahl zu haben, ist iterativ Refactoring. Anstatt alle der Refactoring in einem großen Schuss auf einem privaten Zweig tun, tun es eine Phase zu einem Zeitpunkt. Machen Sie ein paar Sätze von Änderungen auf dem Zweig und dann, wenn Sie wissen, dass sie stabil sind, verschmelzen sie zu dem Stamm. Entwickler auf anderen Branchen arbeiten würden ständig halten ihre Niederlassung auf dem neuesten Stand mit dem Stamm verantwortlich.

einen kleinen Satz von Änderungen Merging sehr oft wird viel weniger zu arbeiten als große Zweige zusammenführen, die ziemlich viel unterscheiden. Die Sie öfter verschmelzen, desto weniger Arbeit, die Sie wird am Ende zu tun hat.

Answer 12

In unserem Projekt haben wir nicht fix in erster Linie Änderungen in der Versionspflege Filialen. Wenn es ein Fehler und

1. kommt es sowohl in den Kofferraum und dem Hauptzweig, reparieren wir es in den Kofferraum und dann die Änderung der Wartungszweig verschmelzen (die sauber passieren einther, oder mehr Arbeit erfordern, in diesem Fall werden wir entscheiden, ob in der neueren Version ist nicht nicht besser ist der Fehler behoben hat nur).
2. es ist nur in der Wartung Zweig, gibt es wahrscheinlich einige König fix in den Kofferraum, und wir gehen eine Nummer scenation.

Answer 13

Haben Sie auf Haben , dass viele Zweige in Arbeit?

War die Arbeit an dem Stamm erst gestartet, wenn es tut, weil der Projektplan, sagte die aktuelle Version fertig sein würde, versenden daher ist es geliefert wurde?

Haben Sie eine Menge Wartung Filialen bekommen, weil Kunden auf die neueste Version aus irgendeinem Grund für ein Upgrade verweigern? Wenn ja, den Grund adressiert.

Haben Sie zu viele alte Versionen becouse die Lücke vor der nächsten Haupt-Release zu groß ist?

Berechnen Sie die Kunden, die nicht mehr für die Wartung wird ein Upgrade, da es mehr kosten?

Antwort Kommentar:

  

Microsoft unterstützt nach wie vor Windows XP   obwohl Vista ist out

ist sehr wahr, aber Microsoft immer noch nicht unterstützt Windows XP SP1, obwohl XP SP3 ist aus.

Dies ist nicht schwarz und weiß, auch wenn Sie nicht alte Version unterstützt stoppen können, können Sie in der Lage sein, die Anzahl von alten Versionen reduzieren Sie unterstützen. Das Problem ist, dass Verkäufe / Support mag ja sagen, aber die Entwicklung wird die Schmerzen, so müssen Sie Ihren Vertrieb / Support-Mitarbeiter auf der Seite erhalten.

Answer 14

Wie Greg darauf gibt es mehrere mögliche Szenarien.

würde ich einen Fall (2.5) hinzufügen, wo manuelle Zusammenführung erforderlich ist, aber da Sie eine Methode, weg von seiner ursprünglichen Position verschoben haben und dann einige Änderungen vorgenommen, wird es schwierig, speziell zu verschmelzen, wenn der „Basis“ Code wurde auch in der „Wartung“ Zweig modifiziert. Das ist nicht so ungewöhnlich, wie es klingt, in der Tat, ein Verfahren zu einem anderen Ort zu bewegen und einen kleinen Fix angewandt ist sehr verbreitet.

Wir haben ein Tool namens Xmerge (Cross-merge) entwickelt, die ein erster Schritt in Richtung Refactoring-aware Verschmelzung ist. Es ist noch nicht automatisch, aber es hilft, mit harten verschmilzt Umgang verschobene Code beinhaltet. Es hier beschrieben ist und ist bereits integriert in Plastic SCM 2.7.

Wir arbeiten an: automatische Bewegung Erkennung und auch „Quer merge“ auf mehreren Zieldateien zu können (Sie Code in einer anderen Datei zu bewegen, die auch ziemlich üblich ist)

.