wake-up-neo.net

Beste Verzweigungsstrategie bei kontinuierlicher Integration?

Was ist die beste Verzweigungsstrategie, wenn Sie eine kontinuierliche Integration durchführen möchten?

  1. Release Branching: auf Trunk entwickeln, für jedes Release einen Branch behalten.
  2. Feature Branching: Jedes Feature in einem eigenen Zweig entwickeln, nur einmal stabil zusammenführen.

Ist es sinnvoll, beide Strategien zusammen anzuwenden? Wie in, Sie verzweigen für jede Version, aber Sie verzweigen auch für große Funktionen? Passt eine dieser Strategien besser zur kontinuierlichen Integration? Wäre die kontinuierliche Integration bei Verwendung eines instabilen Trunks überhaupt sinnvoll?

99
KingNestor

Ich finde das Thema sehr interessant, da ich bei meiner täglichen Arbeit stark auf Branchen angewiesen bin.

  • Ich erinnere mich, dass Mark Shuttleworth ein Modell vorschlug, um den Hauptzweig makellos zu halten und gleichzeitig über das herkömmliche CI hinauszugehen. Ich habe darüber geschrieben hier .
  • Da ich mit Cruise Control vertraut bin, bloggte ich auch über Task Branches und CI hier . Es ist ein Tutorial, das Schritt für Schritt erklärt, wie es mit Plastic SCM gemacht wird.
  • Schließlich fand ich in Duvalls Buch über CI einige der Themen über CI (und möglicherweise über Verzweigung) auch sehr interessant .

Ich hoffe, Sie finden die Links interessant.

20
pablo

Die Antwort hängt von der Größe Ihres Teams und der Qualität Ihrer Quellcodeverwaltung ab sowie von der Fähigkeit, komplexe Änderungssätze korrekt zusammenzuführen. Zum Beispiel kann das Zusammenführen von Quellcodeverwaltungen wie CVS oder SVN in einem vollständigen Zweig schwierig sein, und mit dem ersten Modell sind Sie möglicherweise besser dran. Wenn Sie ein komplexeres System wie IBM ClearCase und ein größeres Team verwenden, können Sie mit dem zweiten Modell besser zurechtkommen Modell oder eine Kombination aus beiden.

Ich persönlich würde das Feature-Branch-Modell, bei dem jedes Hauptfeature in einem separaten Branch entwickelt wird, mit Task-Sub-Branches für jede Änderung, die von einem einzelnen Entwickler vorgenommen wird, trennen. Wenn sich die Merkmale stabilisieren, werden sie zum Rumpf zusammengeführt, den Sie einigermaßen stabil halten und alle Regressionstests zu jeder Zeit bestehen. Wenn Sie sich dem Ende Ihres Release-Zyklus nähern und alle Feature-Zweige zusammenführen, stabilisieren und verzweigen Sie einen Release-System-Zweig, auf dem Sie nur noch Stabilitäts-Bugfixes und erforderliche Backports ausführen, während der Trunk für die Entwicklung des nächsten Releases und Sie erneut verwendet wird Verzweigen für neue Feature-Verzweigungen. Und so weiter.

Auf diese Weise enthält trunk immer den neuesten Code, aber Sie schaffen es, ihn einigermaßen stabil zu halten und stabile Beschriftungen (Tags) für wichtige Änderungen und Zusammenführungen von Features zu erstellen. Die Feature-Zweige entwickeln sich mit kontinuierlicher Integration rasant und es können häufig einzelne Task-Unterzweige sein Wird aus dem Feature-Zweig aktualisiert, damit alle Benutzer, die an demselben Feature arbeiten, synchron bleiben und gleichzeitig andere Teams, die an anderen Features arbeiten, nicht betroffen sind.

Gleichzeitig haben Sie im Verlauf eine Reihe von Release-Zweigen, in denen Sie Backports, Support und Bugfixes für Ihre Kunden bereitstellen können, die aus irgendeinem Grund auf früheren Versionen Ihres Produkts oder sogar auf der neuesten veröffentlichten Version bleiben. Wie beim Trunk richten Sie keine kontinuierliche Integration für die Release-Zweige ein. Sie werden nach Bestehen aller Regressionstests und anderer Release-Qualitätskontrollen sorgfältig integriert.

Wenn aus irgendeinem Grund zwei Features voneinander abhängig sind und Änderungen voneinander erforderlich sind, können Sie in Betracht ziehen, entweder beide auf dem gleichen Feature-Zweig zu entwickeln oder die Features so zu konfigurieren, dass sie regelmäßig stabile Teile des Codes zum Trunk zusammenführen und anschließend die Änderungen von aktualisieren trunk, um Code zwischen Amtsleitungen auszutauschen. Wenn Sie diese beiden Features von anderen isolieren müssen, können Sie einen gemeinsamen Zweig erstellen, von dem Sie diese Feature-Zweige abzweigen und mit dem Sie Code zwischen den Features austauschen können.

Das obige Modell ist bei Teams unter 50 Entwicklern und Versionsverwaltungssystemen ohne spärliche Verzweigungen und ordnungsgemäße Zusammenführungsfunktionen wie CVS oder SVN nicht sehr sinnvoll. Dies würde das gesamte Modell nur zu einem Albtraum beim Einrichten, Verwalten und Integrieren machen.

20
Jiri Klouda

Ich persönlich finde es viel sauberer, einen stabilen Kofferraum zu haben und Verzweigungen zu haben. Auf diese Weise können Tester und dergleichen auf einer einzigen "Version" bleiben und vom Trunk aus aktualisieren, um alle Funktionen zu testen, die vollständig im Code enthalten sind.

Wenn mehrere Entwickler an verschiedenen Features arbeiten, können sie alle ihre eigenen separaten Zweige haben und anschließend zum Trunk zusammengeführt werden, um ein zu testendes Feature zu senden, ohne dass der Tester zum Testen verschiedener Features auf mehrere Zweige wechseln muss.

Als zusätzlichen Bonus gibt es ein gewisses Maß an Integrationstests, die automatisch durchgeführt werden.

9
Adnan

Release-Zweige sind sehr nützlich und sogar unbedingt erforderlich, wenn Sie mehrere Versionen Ihrer App warten müssen.

Feature-Zweige sind auch sehr praktisch, insbesondere wenn ein Entwickler an einer großen Änderung arbeiten muss, während andere noch neue Versionen veröffentlichen.

Für mich ist die Verwendung beider Mechanismen eine sehr gute Strategie.

Interessanter Link aus dem Buch der SVN .

5
SirFabel

Ich denke, dass jede Strategie mit kontinuierlicher Entwicklung verwendet werden kann, vorausgesetzt, Sie erinnern sich an eines der wichtigsten Prinzipien, die jeder Entwickler jeden Tag für Trunk/Mainline einsetzt.

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

BEARBEITEN

Ich habe dieses Buch über CI gelesen und die Autoren schlagen vor, dass die Verzweigung nach Release ihre bevorzugte Verzweigungsstrategie ist. Ich muss zustimmen. Das Verzweigen nach Merkmalen macht für mich bei der Verwendung von CI keinen Sinn.

Ich werde versuchen zu erklären, warum ich so denke. Nehmen wir an, drei Entwickler arbeiten in einem Zweig an einem Feature. Es wird einige Tage oder Wochen dauern, bis jede Funktion fertig ist. Um eine kontinuierliche Integration des Teams zu gewährleisten, muss es sich mindestens einmal am Tag in der Hauptniederlassung engagieren. Sobald sie dies tun, verlieren sie den Vorteil, einen Feature-Zweig zu erstellen. Ihre Änderungen sind nicht länger von allen Änderungen der anderen Entwickler getrennt. Warum sollten Sie sich dann überhaupt die Mühe machen, Feature-Zweige zu erstellen?

Die Verwendung von Verzweigung nach Release erfordert weniger Zusammenführen zwischen Zweigen (immer eine gute Sache), stellt sicher, dass alle Änderungen so schnell wie möglich integriert werden, und stellt (bei korrekter Ausführung) sicher, dass Ihre Codebasis immer bereit zum Release ist. Der Nachteil beim Verzweigen nach Release ist, dass Sie bei Änderungen wesentlich vorsichtiger vorgehen müssen. Z.B. Große Umgestaltungen müssen inkrementell durchgeführt werden. Wenn Sie bereits eine neue Funktion integriert haben, die Sie in der nächsten Version nicht mehr benötigen, muss sie mithilfe eines Feature-Umschalt- -Mechanismus ausgeblendet werden.

EINE ANDERE BEARBEITUNG

Es gibt mehr als eine Meinung zu diesem Thema. Hier ist ein Blog-Beitrag, der mit CI pro-Feature-Verzweigung ist

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/

5
Phil Hale

Ich bin vor kurzem dazu gekommen, dieses Modell zu mögen, wenn ich Git benutze. Obwohl Ihre Frage mit "svn" markiert ist, können Sie sie möglicherweise dennoch verwenden.

Kontinuierliche Integration kann in diesem Modell zu einem gewissen Grad in der "Entwickeln" -Zweigstelle (oder wie auch immer Sie es nennen) stattfinden, obwohl eine lange Laufzeit von Funktionszweigen für zukünftige Versionen dies nicht so starr machen würde, dass jede Änderung, die irgendwo am Code vorgenommen wird, in Betracht gezogen wird. Die Frage bleibt, ob Sie das wirklich wollen. Martin Fowler tut.

4
hermannloose

Solange Sie Prinzipien verstehen, können Sie die Best Practices immer wieder neu erfinden. Wenn Sie Prinzipien nicht verstehen, werden Sie die Best Practices so weit bringen, bevor Sie aufgrund widersprüchlicher externer Anforderungen auseinanderfallen.

Lesen Sie für eine optimale Einführung in das Mainline-Modell Folgendes: https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Lesen Sie den Link. Wenn Sie die Grundlagen verstanden haben, lesen Sie den folgenden Artikel des ehrwürdigen Henrik Kniberg. Es wird Ihnen helfen, das Mainline-Modell mit der kontinuierlichen Integration in Beziehung zu setzen.

http://www.infoq.com/articles/agile-version-control

2
zvolkov

Kontinuierliche Integration sollte für die Festlegung Ihrer Verzweigungsstrategie keine Rolle spielen. Ihr Verzweigungsansatz sollte basierend auf Ihrem Team, dem zu entwickelnden System und den verfügbaren Tools ausgewählt werden.

Davon abgesehen ...

  • es gibt keinen Grund, warum CI nicht in beiden von Ihnen beschriebenen Ansätzen verwendet werden kann
  • diese Ansätze funktionieren sehr gut in Kombination
  • keiner der beiden funktioniert "besser" als der andere
  • CI macht bei einem instabilen Kofferraum Sinn

All dies wurde in der vierten Frage auf der Seite beantwortet, der Sie die Diagramme entnommen haben: http://blogs.collab.net/Subversion/2007/11/branching-strat/

2
Zac Thompson

Als wir unser Team gründeten, erbten wir eine releasebasierte Strategie von dem Anbieter, der ursprünglich das System entwickelte, für das wir verantwortlich sein sollten. Es funktionierte bis zu dem Zeitpunkt, als unsere Kunden verlangten, dass mehrere entwickelte Funktionen nicht in ein Release aufgenommen werden sollten (z. B. ~ 250.000 Codezeilen, ~ 2500 Dateien, Scrum mit XP SDLC)).

Dann haben wir uns Feature-basierte Zweige angesehen. Dies funktionierte auch eine Weile - etwa zwei Monate, bis wir feststellten, dass unser Regressionstestprozess mehr als zwei Wochen dauern würde, was zusammen mit der Unsicherheit darüber, was veröffentlicht werden würde, zu einer enormen Unannehmlichkeit führte.

Der letzte "Nagel im Sarg" der reinen SC) Strategien kam, als wir beschlossen, dass wir 1. stabilen Stamm und 2. Produktion haben sollten, die ST, UAT und Regression geprüfte BINARIEN enthalten sollten (nicht nur Quelle - denke CC.)

Dies brachte uns dazu, eine Strategie zu entwickeln, die eine Mischung aus Feature- und release-basierten SC Strategien ist.

Wir haben also einen Kofferraum. Jeder Sprint, den wir aus dem Sprint-Zweig heraus verzweigen (für die nicht agilen Leute - ein Sprint ist nur ein zeitaufwändiger Entwicklungsaufwand mit variabler Leistung, basierend auf der Komplexität). Aus dem Sprint-Zweig erstellen wir die Feature-Zweige und in ihnen beginnt die parallele Entwicklung. Sobald die Funktionen vollständig und systemgetestet sind und wir die Absicht haben, sie bereitzustellen, werden sie mit dem Sprint-Zweig zusammengeführt. Einige können über mehrere Sprints verteilt sein, in der Regel die komplexeren. Sobald der Sprint fast zu Ende ist und die Funktionen vollständig sind ... "benennen" wir den Sprint-Zweig in "Regression" um (dies ermöglicht CruiseControl, ihn ohne Neukonfiguration aufzunehmen) und dann beginnen die Regressions-/Integrationstests auf dem CC-Build OHR. Wenn das alles erledigt ist, geht es in die Produktion.

Kurz gesagt werden funktionsbasierte Zweige zur Entwicklung, zum Systemtest und zur UAT-Funktionalität verwendet. Der Sprint-Zweig (eigentlich der Release-Zweig) wird verwendet, um Features On-Demand und Integrationstest selektiv zusammenzuführen.

Hier ist eine Frage an die Community: Offensichtlich haben wir Probleme bei der Durchführung einer kontinuierlichen Integration, da die Entwicklung in vielen Zweigen stattfindet und sich der Aufwand für die Neukonfiguration von CruiseControl erhöht. Kann jemand Vorschläge und Ratschläge geben?

1
XAvatar

Dave Farley , Autor von Continuous Delivery , bezeichnet Trunk Based Development (TBD) als Eckpfeiler für Continuous Integration (CI) und Continuous Delivery (CD). Er sagt:

Jede Form der Verzweigung steht der kontinuierlichen Integration entgegen.

Er sagt auch:

Feature Branching ist aus Sicht eines einzelnen Entwicklers sehr gut, aus Sicht eines Teams jedoch nicht optimal. Wir möchten alle ignorieren können, was alle anderen tun, und mit unserer Arbeit weitermachen. Leider ist Code nicht so. Sogar in sehr gut faktorisierten Codebasen mit einer schönen Trennung der Anliegen und wunderbar locker gekoppelten Komponenten wirken sich einige Änderungen auf andere Teile des Systems aus.

Trunk Based Development (TBD) ist das Integrieren von Codeänderungen in den Trunk (a.k.a., master, mainline) mindestens einmal pro Tag - vorzugsweise mehrmals pro Tag. Continuous Integration (CI) ist eine ähnliche Vorgehensweise, mit der Ausnahme, dass auch die Codeänderungen mithilfe automatisierter Tests überprüft werden. Die beste Verzweigungsstrategie besteht darin, direkt vom Trunk aus zu arbeiten und Codeüberprüfungen durch Pair-Programming durchzuführen. Wenn Sie aus irgendeinem Grund keine Verbindung herstellen können oder nur wirklich verzweigen möchten, stellen Sie sicher, dass Ihre Zweige nur von kurzer Dauer sind (weniger als einen Tag).

Ich arbeite an Trunk, dem "Master" in meinen GIT-Repos. Ich verpflichte mich, lokal zu mastern und sofort, wenn ich vernetzt bin, zu meinem zentralen Master-Repository zu pushen, auf dem CI ausgeführt wird. Das ist es!

Versuchen Sie, große Funktionen (d. H. Funktionen, die länger als einen Tag dauern) in kleine logische Blöcke zu unterteilen, die in den Trunk integriert werden können, ohne die Software zu beschädigen. Sie können auch Techniken wie Feature-Flagging und Verzweigung durch Abstraktion verwenden, mit denen Sie unvollständige Arbeiten bereitstellen können, ohne die Endbenutzer zu beeinträchtigen.

Ich verwende Branch-by-Abstraction, Dark-Releasing und manchmal Feature-Flags. Was ich als Gegenleistung erhalte, ist schnelles, definitives Feedback (zumindest in Bezug auf die Qualität meiner Tests).

0
Yani

So wie ich es sehe, möchten Sie eine begrenzte Anzahl von Zweigen haben, auf die Sie sich konzentrieren können. Da Sie möchten, dass Tests, Codequalitätsmetriken und viele interessante Dinge mit den Builds ausgeführt werden, werden Sie wahrscheinlich Informationen verpassen, wenn Sie zu viele Berichte haben.

Wann und was zu verzweigen ist, hängt normalerweise von der Größe des Teams und der Größe der zu entwickelnden Features ab. Ich glaube nicht, dass es eine goldene Regel gibt. Stellen Sie sicher, dass Sie eine Strategie verwenden, bei der Sie frühzeitig/häufig Feedback erhalten. Dazu gehört, dass die Qualität von Anfang an in die Funktionen einbezogen wird. Das Qualitätsmerkmal bedeutet, dass Sie bei der Automatisierung während der Entwicklung des Teams auch die Qualität in das Team einbeziehen müssen, wenn Sie für einen großen Funktionsumfang verzweigen, den ein Team aufbaut.

ps Woher hast du diese Ansatzreferenzen? - fühlt sich nicht, dass diese Grafiken alle Optionen darstellen

pdate 1: Erweitere, warum ich gesagt habe, dass es keine goldene Regel ist. Grundsätzlich empfand ich es für relativ kleine Teams als das Beste, einen Mix zu verwenden. Feature-Zweige werden erstellt, wenn es etwas Langes ist, und ein Teil des Teams wird weiterhin kleinere Features hinzufügen.

0
eglasius