Fragen über Task-getriebene Verzweigung

Question

Ich überlege, von HG auf Kunststoff SCM (http://www.plasticscm.com, vor allem, weil es viel bessere VS-Integration zu bieten scheint), und sie fördern "Task Driven Branching", das heißt Verzweigung von Mainline für jeden Feature. Dies macht Sinn, aber ich ein paar Fragen hatte:

1. Sie empfehlen nicht verschmelzenden Ihre Aufgaben zurück zu Standard, nachdem sie abgeschlossen sind. Dies scheint sehr unintuitiv zu sein, ich hätte gedacht, dass man nach dem Testen sofort wieder mit dem Tipp verschmelzen möchte, damit man später nicht mehr rebasen muss. Ganz zu schweigen davon, wenn Tasks nicht zusammengeführt werden und eine neue Version erscheint, muss man in möglicherweise Hunderte von verschiedenen Zweigen zusammenführen und sicherstellen, dass alle in kurzer Zeit gut miteinander spielen (Testen) in der Unabhängigkeit bedeutet nicht, dass sie nett mit anderen spielen, imho). Also, das scheint so zu sein, dass es scheitern muss, liege ich falsch? Trainierst du diese Methode?
2. Nehmen wir an, ich liege falsch in Bezug auf die oben genannten, in dem folgenden Szenario: Aufgabe A, B, C. Wo B, C sind abhängig von A abgeschlossen, wäre es besser, A abzuschließen, füge es zurück zur Hauptlinie und verzweigen Sie von dort aus, um an B/C zu arbeiten, oder verzweigen Sie Ihren ersten Zweig (den Zweig, den Sie für A erstellt haben). Ist das überhaupt möglich? Empfohlen? Es scheint etwas sauberer in meinem Kopf zu sein, wenn die gleiche Person A, B, C implementiert. Wenn nicht, ist es offensichtlich, dass es am sinnvollsten ist, zur Hauptlinie zurückzukehren.

Lass mich wissen, was ihr denkt!

Danke.

Answer 1

In einer rather good discussion über Zweig Strategien vor kurzem hatten wir enthielten jgifford25's answer einen Link zu dem, was man von Subversion-Entwickler ruft die ‚agile release strategy‘, und das sieht ziemlich ähnlich, was die Plastic Jungs schlagen - einen Zweig pro Feature, mit Merges in Freisetzungszweige statt in den Kofferraum. Ich dachte nicht, dass das eine gute Idee ist, und ich denke nicht, dass dies eine gute Idee ist. Ich denke auch nicht, dass es ein Zufall ist, dass in beiden Fällen die Idee von einem SCM-Entwickler gedrängt wird - ich denke, dass diese Leute einen Fall von "alles sieht wie ein Nagel" haben und denken, dass irgendein Prozessproblem mit mehr behoben werden kann und größere SCM.

Warum ist diese Idee schlecht? Lasst uns dem Argument der Plastikjungs folgen. Sie bauen diesen Prozess um eine zentrale Idee auf: "Behalte die Hauptstrecke unberührt". So weit, ist es gut.Sie dann einen Syllogismus voranzubringen, die wie folgt aussieht:

1. Wenn Sie in den Kofferraum überprüfen gebrochen Code bricht der Build
2. Haften sind schlecht baut
3. Daher nicht überprüfen Code in den Kofferraum

Das Problem dabei ist, dass es völlig falsch versteht warum kaputte Builds sind schlecht. Zerbrochene Builds sind nicht schlecht an sich (obwohl sie nicht hilfreich sind, weil sie die Entwicklung blockieren), sie sind schlecht, weil sie bedeuten, dass jemandin den Code eingecheckt hat. Es ist gebrochener Code, der das wahre Problem ist, nicht kaputte Builds - es ist der kaputte Code, der tatsächlich das Potenzial hat, Schaden zu verursachen (verlorene Benutzerdaten, verlorene Raumsonden, globaler thermonuklearer Krieg, so etwas).

Ihre Lösung besteht also darin, dass Leute ihren Code an anderer Stelle überprüfen, damit der Build nicht beschädigt wird. Das macht offensichtlich gar nichts, um mit dem eigentlichen Problem des gebrochenen Codes fertig zu werden - ganz im Gegenteil, es ist eine Art, kaputten Code zu verbergen. In der Tat ist es mir nicht klar, an welcher Stelle die Brüche erkannt werden - wenn die Aufgabenzweige abgeschlossen und mit dem Veröffentlichungszweig verbunden werden? Das klingt nach einer großartigen Möglichkeit, schwierige Arbeit bis spät in den Veröffentlichungszyklus zu verschieben, was eine sehr schlechte Idee ist.

Die echte Lösung ist eher ganz einfach nicht überprüfen Sie den gesamten Code in. In der Verfolgung dieses Ziels ist ein gebrochener Build tatsächlich gut, weil es Ihnen sagt, dass es einen kaputten Code gibt, mit dem Sie es beheben können. Das ist in der Tat der ganze Wendepunkt der Idee der kontinuierlichen Integration - Sie verschmelzen früh und oft zu einem einzigen Stamm, der der Prototyp dessen ist, was tatsächlich veröffentlicht wird, so dass Sie Probleme mit dem entdecken, was Sie bereits veröffentlichen wollen möglich. Das erfordert unbedingt das "instabile Stamm" -Modell, oder etwas isomorphes dazu.

Die blog post, dass orangepips's answer Links zu Ubuntu Idee über Prozess als Treiber für diese Idee erwähnt. Aber schauen, was Shuttleworth sagte tatsächlich:

• Stamm halten unberührten
• Halten Funktionen
• Veröffentlichung auf Nachfrage fließt

Das ist mein Schwerpunkt auf den letzten Punkt ist, aber es ist Shuttleworths Endziel : Er möchte in der Lage sein, Releases jederzeit zu schneiden. Ein Prozess, der das Zusammenführen und Testen auf den Freigabeprozess verschiebt, wie es das Plastikmodell tut, kann dies unmöglich tun.

Eher, wenn Sie sehen möchten, wie ein Prozess aussehen kann, schauen Sie sich what the lean guys do an: eine Codezeile, kontinuierliche Integration (auf einer Skala von Stunden oder sogar Minuten statt Tagen oder Wochen), kein kaputter Code .

Also, zum Schluss: Tu dies nicht. Haben Sie eine Codezeile und überprüfen Sie den Arbeitscode so oft wie möglich. Einfach.

PS Okay, Sie möchten vielleicht Release-Zweige erstellen, um aktuelle Versionen zu stabilisieren und zu korrigieren. Im Idealfall würden Sie nicht, aber Sie müssen möglicherweise.

PPS Und wenn Sie eine CI-Testsuite haben, die vor dem Einchecken zu langsam ist (zB Funktionstests, die eine Stunde dauern), dann können Sie mit jedem DVCS zwei Repositories haben: einen dreckigen, wo Entwickler verschmelzen mit einem sauberen Skript, das von einem Skript angestoßen wird, das das schmutzige Repository nach Änderungen beobachtet, neue Versionen erstellt und testet und nach dem Übergeben an das saubere Repository weiterleitet. Sie können dann On-Demand-Releases (für QA usw.) aus dem Clean-Repository ausführen und Entwickler können aus dem Clean-Repository aktualisieren, um während der Entwicklung auf dem neuesten Stand zu bleiben. Sie müssen natürlich unmittelbar vor dem Zusammenführen aus dem schmutzigen Repository updaten.

Answer 2

Nach reading the PR klingt es, als ob sie für ein Modell befürworten, wo code is tested before it's merged into the trunk/main/base-line (siehe Regel # 4). Dies setzt eine Reihe von Komponententests und voraus, dass diese Tests alle Änderungen abdecken, die vorgenommen wurden. Für die meisten Projekte, an denen ich beteiligt war, existiert die Suite nicht und wird wahrscheinlich nie vollständig sein.

In meiner eigenen Erfahrung mit Subversion ist der Stamm unberührt, aber nicht, was Releases gemacht werden. Stattdessen ist der Stamm, wo Back-und Forward-Ports zwischen Version fließen. Releases kommen aus Versionszweigen.

Aus der Version Zweige, Feature Zweige werden manchmal erstellt. Diese Verzweigungen ermöglichen häufige Commits, die Dinge brechen können. Sobald ein Feature-Zweig fertiggestellt ist, wird er in die Version integriert. Es gibt zwangsläufig Probleme, die gelöst werden müssen, wenn diese Integration stattfindet. Sobald eine Version erstellt und validiert wurde, wird sie schließlich in den Trunk integriert.

Also ich denke, # 1 ist nicht realistisch. Wie für # 2, es kommt darauf an. Ist es sicher, dass B und C A nicht ändern werden? Wenn das der Fall ist, füge A zusammen, dann verzweige für B und C. Aber höchst wahrscheinlich würde ich A verzweigen, um B und C zu machen, weil wahrscheinlich Letzteres den ersteren ändern wird. Dann rollen Sie alle drei zusammen.