Wie gehen Sie mit der Spannung zwischen refactoring und die Notwendigkeit für die Zusammenführung?

Question

Unsere Politik bei Lieferung einer neuen version ist das erstellen einer Filiale in unseren VCS und Griff es für unser QA-team.Wenn letzteres gibt grünes Licht tag, und lassen Sie unsere Produkt.Der Zweig ist gehalten, zu empfangen (nur) bug fixes, so, dass wir können bei der Erstellung von technischen Veröffentlichungen.Diejenigen, die bug-fixes werden anschließend zusammengeführt, die auf den Stamm.

Während dieser Zeit wird der Rumpf sieht die wichtigste Entwicklung, und ist möglicherweise unterliegen refactoring-änderungen.

Das Problem ist, dass es eine Spannung zwischen der Notwendigkeit zu haben eine stabile Stamm (so, dass die Zusammenführung von bug-fixes, die gelingen-es kann in der Regel nicht, wenn der code wurde z.B.extrahiert eine andere Methode, oder in einer anderen Klasse) und die Notwendigkeit, umgestalten, es bei der Einführung von neuen Funktionen.

Die Politik in unserem Ort ist nicht die Umgestaltung, bevor genügend Zeit verstrichen ist, und der Zweig ist stabil genug.Wenn dies der Fall ist, kann man anfangen, das zu tun refactoring-änderungen auf dem Stamm, und bug-fixes sind manuell begangen sowohl der Stamm und Zweig.

Aber dies bedeutet, dass Entwickler müssen warten einige Zeit, bevor Sie auf den Stamm, jede Umgestaltung zu ändern, da diese brechen könnte das anschließende Zusammenführen von Zweig zu Stamm.Und dass Sie manuell Hafen bugs aus der Branche der Stamm ist schmerzhaft.Es scheint mir, dass dies behindert die Entwicklung...

Wie geht man mit dieser Spannung?

Vielen Dank.

Answer 1

Dies ist ein echtes praktisches problem.Es wird noch schlimmer, wenn Sie mehrere Versionen, die Sie unterstützen müssen, und haben verzweigte für jeden.Schlimmer noch, wenn Sie eine echte R&D-Niederlassung zu.

Meine Vorliebe war es der Hauptstamm zum fortfahren mit der normalen rate und nicht zu halten, weil Sie in einem Umfeld release timings wichtig waren kommerziell nie konnte ich argumentieren, wir sollten es erlauben, den code zu stabilisieren ("was, du meinst, Sie veröffentlichten es in einem instabilen Zustand?").

Der Schlüssel war, um machen Sie sicher, dass die unit-tests erstellt wurden, für die bug-fixes wurden gewechselt über, wenn der bug wurde migriert, die in den main-branch.Wenn Sie Ihre neue code-änderungen sind wirklich nur re-factoring dann die alten tests sollten gleichermaßen gut funktionieren.Wenn Sie änderungen sind solche, dass Sie sind nicht mehr gültig, dann können Sie nicht nur den port den du Update in jedem Fall und du wirst brauchen jemanden zu haben, zu überlegen, welche fix in die neue code-stream.

Nach ein paar Jahren die Verwaltung dieser Art von problem, Schloss ich, dass Sie wahrscheinlich benötigen 4 code Ströme auf ein minimum, um angemessene Unterstützung und Abdeckung, und eine Sammlung von ziemlich strenge Prozesse zum verwalten von code, der über Sie hinweg.Es ist ein bisschen wie das problem des seins in der Lage zu zeichnen einer Karte in 4 Farben.

Nie fand ich keine wirklich gute Literatur zu diesem Thema.Es wird unweigerlich verbunden werden, um Ihre release-Strategie und die SLAs, dass Sie sich mit Ihren Kunden.

Nachtrag:Ich sollte auch erwähnen, dass es notwendig war, zu schreiben Zweig Zusammenführen, wie bestimmte Meilensteine in den release-Zeitplan der Haupt-Niederlassung.Nicht unter Schätzung der Menge an Arbeit, die möglicherweise verbundene bringen Sie Ihren Branchen zusammen, wenn Sie eine Sammlung von hart arbeitenden Entwicklern Ihre Arbeit tun die Durchführung von features.

Answer 2

Wo ich arbeite, wir schaffen temporäre, kurzlebig (weniger als Tag - ein paar Wochen) Arbeitszweige für jede nicht-triviale Änderung (Feature hinzufügen oder Bugfix). Trunk ist stabil und (idealerweise) potentiell lösbare die ganze Zeit; nur fertig Einzelteile erhalten hinein verschmolzen. Alles vom Stamm begangen wird in die Arbeitszweige verschmolzen täglich; Dies kann weitgehend automatisiert werden (wir verwenden Hudson, Ant und Subversion). (Dieser letzte Punkt, weil es in der Regel besser Konflikte zu lösen eher früher als später, natürlich.)

Das aktuelle Modell, das wir verwenden wurde weitgehend durch einen ausgezeichneten Artikel beeinflusst ( die ich habe, bevor angeschlossen) von Henrik Kniberg: Versionskontrolle für mehrere Agile Teams .

(In unserem Fall haben wir zwei Scrum-Teams auf einer Code-Basis zu arbeiten, aber ich bin gekommen, dieses Modell zu denken, von Vorteil sein kann auch mit einem Team).

Es gibt einige Overhead über das zusätzliche Branching und Merging, aber nicht zu viel, wirklich, wenn Sie sich daran gewöhnen und besser mit den Werkzeugen (z svn merge --reintegrate ist praktisch). Und nein, ich nicht schaff' einen temporären Zweig immer, z.B. für kleinere, risikoarme Refactorings (ohne Bezug zu den wichtigsten Elemente zur Zeit in Arbeit), die leicht mit einem abgeschlossen werden kann, verpflichten sich Stamm.

Wir haben auch einen älteren Versionszweig, in der kritischen Fehler halten von Zeit zu Zeit festgelegt ist. Zwar kann es manuell sein (manchmal langweilig) Zusammenführung der Arbeit, wenn einige bestimmten Teil des Codes in Stamm mit dem Zweig signifikant im Vergleich entwickelt hat. (Diese hoffentlich wird weniger ein Problem, da wir in Richtung kontinuierlich Freigabe Schritten von Stamm (intern) zu bewegen, und lassen Marketing & Produktmanagement entscheiden, wenn sie eine externe Freigabe machen wollen.)

Ich bin mir nicht sicher, ob dies Ihre Frage direkt beantwortet, oder wenn Sie dies in Ihrer Umgebung (mit dem separaten QA-Team und all) anwenden können - aber zumindest kann ich sagen, dass die Spannung, die Sie beschreiben, nicht für uns existiert und wir sind frei, Refactoring, wann immer. Viel Glück!

Answer 3

Ich denke, die Spannung kann durch Zugabe von folgenden Zutaten zu Ihrem Entwicklungsprozess behandelt werden:

1. Kontinuierliche Integration
2. Automatische Funktionstests (nehme ich an Sie bereits mit Unit-Tests zählen)
3. Automatische Lieferung

Mit einer kontinuierlichen Integration, jeder begehen impliziert einen Build, wo alle Unit-Tests ausgeführt werden sollen und Sie alarmiert, wenn etwas schief geht. Sie starten mehr mit dem Kopf arbeiten, und Sie sind weniger anfällig die Code-Basis zu einer Verzweigung.

Mit automatisierten Funktionstests können Sie Ihre Anwendung testen beim Klick auf den Button. Im Allgemeinen, da diese Tests mehr Zeit in Anspruch nehmen, diese werden jede Nacht laufen. Damit beginnt die klassische Rolle der Versionierung, die Bedeutung zu verlieren. Sie machen Ihre Entscheidung nicht auf, wenn auf der Grundlage der Version und seinen Reif zu lösen, ist es die Geschäftsentscheidung ist. Wenn Sie Gerät implementiert haben und Funktionsprüfung und Ihr Team einreicht getesteten Code, den Kopf sollte immer im Zustand, die freigegeben werden kann. Bugs werden ständig entdeckt und behoben und Release geliefert, aber das ist nicht mehr zyklischer Prozess, es ist die kontinuierliche ein.

Sie werden wahrscheinlich zwei Arten von Verleumdern haben, da dies bedeutet, einige lange verwurzelte Praktiken zu ändern. Erstens scheint der Paradigmenwechsel der kontinuierlichen Lieferung kontraintuitiv zu Managern. „? Sind wir nicht einen großen Fehler versenden zu riskieren“ Wenn Sie einen Blick auf Linux oder Windows-Distributionen nehmen, das ist genau das, was sie tun: Veröffentlichungen gegenüber Kunden drängen. Und da Sie mit Suite von automatisierten Tests zählen, sind Gefahren weiter verringert.

Als nächstes QA-Team oder eine Abteilung. (Einige würden argumentieren, dass das Problem ist, ihre Existenz in sich selbst!) Sie werden auf die Automatisierung von Tests im Allgemeinen aversiven sein. Es bedeutet, neues und manchmal kompliziertes Werkzeug zu lernen. Hier ist der beste, indem sie es zu predigen. Unser Entwicklungsteam begann auf kontinuierliche Integration arbeiten und in der gleichen Zeit mit der Suite von Funktionstests schreiben Selen . Wenn QA-Team das Werkzeug in Aktion sah, war es schwierig, seine Umsetzung zu widersetzen.

Schließlich ist die thurth, dass der Prozess, den ich beschrieben, wie addig 3 ingredinents zu Ihrem Entwicklungsprozess nicht so einfach ist. Es bedeutet eine tiefe Veränderung der Art und Weise Sie Software entwickeln.

Answer 4

Vielleicht Git (oder anderen DVCS) sind besser auf die Behandlung übergeht, um aktualisierte Code dank der Tatsache, dass sie (wirklich) eher Änderungen verwalten als nur Dateien vergleichen ... As Joel sagt :

  

Mit verteilten Versionskontrolle ist verschmilzt einfach und gut funktionieren. So kann man tatsächlich einen stabilen Zweig und einen Entwicklungszweig, oder schaffen langlebige Zweige für Ihr QA-Team, wo sie testen Dinge vor der Bereitstellung, oder Sie können kurzlebig Filialen schaffen neue Ideen auszuprobieren und sehen, wie sie funktionieren.

noch nicht probiert, aber ...

Answer 5

Wo ich arbeite, halten wir mit dem Refactoring im Hauptzweig. Wenn der Merges knifflig, sie müssen nur mit auf Ad-hoc-Basis behandelt werden, sie sind alle tun kann, aber gelegentlich ein wenig Zeit in Anspruch nehmen.

Answer 6

Vielleicht ist unser Problem kommt von der Tatsache, dass wir Filialen haben, die eine recht lange Lebensdauer (bis zu 18 Monate) haben muss, und es gibt viele Fehlerbehebungen, die gegen sie getan werden müssen.

Sicherzustellen, dass wir nur aus extrem stabilem Code verzweigen würde wahrscheinlich helfen, werden aber nicht so einfach sein ...: (