Kürzerer Release-Zyklus mit DVCS

Ermöglicht die Wahl der Verwendung eines DVCS gegenüber einem CVCS tatsächlich kürzere Freigabezyklen? Wenn ja, was verkürzt die Software-Release-Zyklen und was sind die Argumente dafür?

1. Bezogen auf Pull-Anfrage? Spielt hier die einfachere Einreichung von Patches eine Rolle?
2. Bezogen auf Personenfaktor? Handeln Projektteams, die CVCS verwenden, konservativer mit Release-Zeitplänen?
3. Irgendwelche anderen Faktoren?

Was verkürzt den Software-Release-Zyklus mit DVCS im Vergleich zu CVCS?

Ich denke nicht, dass es hier notwendigerweise einen Unterschied zwischen DVCS und CVCS gibt, sondern vielmehr einen Unterschied im Verzweigungsmodell, an dem die Leute festhalten.

Nach dem, was ich hier gesammelt habe und nach meiner Erfahrung verwenden Benutzer von DVCS tendenziell mehr Zweige als Personen, die CVCS verwenden. Wenn Sie jedes Feature in einem eigenen Zweig entwickeln, ist es einfacher, eine Version mit dem neuen Feature X vorzubereiten, jedoch nicht mit Feature Y, dessen Entwicklung begonnen hat, das jedoch noch nicht für eine Version bereit ist.

Jeder hier scheint zu bestätigen , dass Projekte DVCS kürzeren Release - Zyklen über alle verwenden, aber es ist noch nicht sicher , dass die Annahme eines DVCS verursacht die kürzeren Zyklen: Die Korrelation ist nicht Kausalität!

Verteiltes VCS und kurze Release-Zyklen sind relativ neue Technologien. Projekte, die das eine umfassen, werden wahrscheinlich das andere umfassen, während Gruppen, die das Bewährte bevorzugen oder über einen seit langem etablierten Workflow verfügen, konservativer sind und sich an CVCS und weniger häufige Veröffentlichungen halten.

Eine bessere Frage wäre: "Inwiefern erleichtert die Verwendung eines DVCS das Modell des kurzen Veröffentlichungszyklus?" Dies ist, was die meisten Antworten tatsächlich ansprechen. Die Verwendung eines DVCS verhindert nicht, dass jemand lange Release-Zyklen hat. Es ist eine Wahl, kurze zu übernehmen, und es umfasst Entwicklungsmethoden, Verzweigungsmodelle, Codeüberprüfungen usw. - nicht nur das VCS.

Gute Frage!

Das CVCS glaubt an das Hauptprinzip, dass alles immer wieder mit dem "Trunk" zusammengeführt / synchronisiert werden muss. Wir gehen auch davon aus, dass der Kofferraum während unserer Entwicklung die stabilsten Punkte sein sollte, bevor die Veröffentlichung erfolgt. Die Leute legen ihre Arbeit in eine Arbeitskopie, nehmen Aktualisierungen vor und testen sie vor dem Einchecken. Alternativ arbeiten Sie an privaten Zweigen / Feature-Zweigen und führen dann andere Trunk-Änderungen zusammen. Testen Sie diese, bevor Sie sie erneut integrieren.

Das DVCS-Muster kann erheblich abweichen. Sie verzweigen sich weiter und gabeln sich. Sie können experimentieren und schließlich sinnvolle Zweige zusammenführen. Gelegentlich haben Sie von Sicherheitsupdates gehört, die sofort gelöscht werden müssen. Sie möchten also, dass sich dieser Patch auch in Ihrer Filiale befindet, aber Sie möchten nicht viele andere Dinge von Trunk! Standardmäßig arbeiten Sie also weiter in Ihrem Raum, nehmen und integrieren weiterhin Dinge - und die Zeit für die Veröffentlichung kommt, Sie alle sitzen und entscheiden, was Sie nehmen und was Sie fallen lassen möchten.

Siehe dies: http://nvie.com/posts/a-successful-git-branching-model/

Der wesentliche Unterschied ist also folgender: CVCS fragt, was die Mutter zu ihren kleinen Kindern sagt - gehen Sie nicht weit über einen Punkt hinaus, an dem ich Sie finden kann, dh - synchronisieren Sie sich weiter mit dem Kofferraum. Das DVCS funktioniert unter der Annahme, dass alle Arbeiten unabhängig gestaltet sind, es sei denn, es besteht eine ausdrückliche Notwendigkeit zum Zusammenführen (z. B. Erstellen einer Version).

Kommen wir nun zu Ihrer Frage -

Die obige Erklärung widerspricht tatsächlich eher dem, was Sie beobachtet / gefragt haben. Die eigentliche Herausforderung besteht darin, zu definieren, was stabil ist! Wenn die Anzahl der Benutzer sehr groß ist und die Leute weiterhin ihre Deltas einschenken, kann es sein, dass jeder von ihnen einen Gegenbruch in Bezug auf andere parallele Änderungen hat, bis sich alle auf sein individuelles Bestes eingestellt haben und die gesamte Integration und Abhängigkeiten in Ordnung sind. Wenn Sie also versuchen, eine Veröffentlichung vorzunehmen, müssen Sie die Dinge wirklich durcheinander bringen, die Leute davon abhalten, neue Funktionen zu nutzen - Identifizierungsprobleme identifizieren, wenn die Dinge zusammengeführt werden und so weiter. All dies impliziert, dass CVCS Sie immer auffordert, zwischen den Entwicklungen "Release-Pausen" einzulegen!

Wenn die Anzahl der Mitwirkenden groß wird, wird es schwierig und weniger, an diesen Punkt der „Release-Pausen“ zu gelangen. und daher wird CVCS Sie tatsächlich zwingen, nach einem sehr bedeutenden "Release Creation Festivals" zu veranstalten.

In DVCS arbeiten Sie weiter, testen, testen in Ihrem eigenen Raum. Das Erstellen und Integrieren von Releases ist eine ziemlich parallele Aktivität und es kann sich auch leisten, Fehler zu versuchen, indem Sie sehen, welche Patch-Sets zusammenarbeiten und welche nicht (daher werden sie aus Releases übernommen oder gelöscht). In DVCS können Sie die individuelle Entwicklung entkoppeln und dann ab und zu eine Veröffentlichung einschleichen, wenn dies sinnvoll ist.

Was verkürzt den Software-Release-Zyklus mit DVCS im Vergleich zu CVCS?

Ich stimme Bart zu, dass der Hauptgrund das verwendete Verzweigungsmodell ist, aber die Art des Versionskontrollsystems beeinflusst direkt, welche Verzweigungsmodelle realisierbar sind. Wir haben also zwei Unterfragen. Welches Verzweigungsmodell unterstützen die verteilten Systeme besser und warum beschleunigt es den Release-Zyklus?

Der grundlegende Unterschied zwischen zentraler und verteilter Versionskontrolle besteht darin, dass Sie ohne zentrale Autorität keine lineare Zeitachse erzwingen können. Um eine verteilte Versionskontrolle zu ermöglichen, mussten diese Systeme den Verlauf notwendigerweise als gerichteten azyklischen Graphen definieren, wobei jede Revision lediglich eine eindeutige Kennung, eine oder mehrere übergeordnete Revisionen und möglicherweise beliebig viele untergeordnete Revisionen aufweist, die Sie möglicherweise gar nicht kennen, weil Sie haben noch nicht mit dem System synchronisiert, auf dem sie erstellt wurden.

Es stellt sich heraus, dass sich dieser Ansatz sehr gut zur Verzweigung eignet. Sie müssen nichts tun, um einen Zweig zu bekommen, Sie haben einfach immer einen. So können Sie direkt mit dem Kopf voran zur Arbeit tauchen und entscheiden, wann und wo es zusammengeführt werden soll oder wo und unter welchem ​​Namen es aufbewahrt werden soll, bis Sie wissen, ob es tatsächlich so läuft, wie Sie es benötigen.

Im Gegensatz dazu pflegen alle zentralisierten Systeme die Historie als Satz von Zweigen mit linearer Abfolge von Revisionen. Sie müssen also im Voraus entscheiden, ob Sie einen Zweig benötigen, ihm einen Namen geben und ihn explizit erstellen. Das ist ziemlich nervig, wenn Sie noch nicht wissen, was die Idee wert ist, und das oft einfach nicht wissen, bevor Sie mit dem Programmieren beginnen. Erschwerend kommt hinzu, dass in den meisten zentralisierten Systemen die Filialnamen global, signifikant, häufig persistent und nicht leicht zu ändern sind, während sie in allen wichtigen verteilten Systemen nur lokale Moniker sind, die nach Belieben geändert und frei recycelt werden können. Und durch die Tatsache, dass alle Verzweigungs- und Zusammenführungsvorgänge in CVCS normalerweise etwas langsamer sind.

Somit erleichtert DVCS Verzweigungen und daher werden Teams, die DVCS-Zweige verwenden, ständig verwendet, während Teams, die CVCS verwenden, diese die meiste Zeit meiden.

Warum ermöglicht die Verwendung von Zweigen häufigere Releases? Nun, jedes Team wird ab und zu eine Aufgabe unterschätzen, oft wenn ein schwer zu verfolgender Fehler auftritt. Teams, die zentralisierte Systeme verwenden, führen normalerweise das gesamte Debugging und die meisten Entwicklungen im Trunk durch, da Zweige unpraktisch sind. Sie können also erst freigeben, wenn sie die meisten Fehler beseitigt haben und die Entwicklungs- und Debugging-Phasen verschachteln müssen.

Im Gegensatz dazu können in verteilten Systemen, in denen alle Arbeiten an Zweigen ausgeführt werden, diese zum Testen zusammengeführt, getestet, Fehler behoben und nur die Arbeit, die Tests besteht, separat mit dem Trunk zusammengeführt werden. Dies führt zu einem Stamm, der nur sehr wenige Fehler aufweist und daher häufiger freigegeben werden kann, normalerweise immer dann, wenn ein wichtiges Feature landet.

Es hilft auch, dass bei einer Änderung der Prioritäten die laufenden Arbeiten mit dem bei verteilten Systemen verwendeten Verzweigungsansatz trivial zurückgestellt werden können. In den meisten realen Projekten ändern sich die Prioritäten ständig.