Kontinuierliche Integration mit der Entwicklung mehrerer Zweige in Subversion

Wie Sie anmerken, besteht ein Zweck der Verwendung einer Verzweigung darin, bestimmte Code-Schwankungen von der Ticket-Fixierung und der Feature-Entwicklung getrennt vom Stamm zu trennen. Aber sobald das Feature oder Ticket abgeschlossen ist, sollten Sie es zusammenführen. In Subversion werden Zweige besser dazu verwendet, Gruppen verwandter Features (wie die für ein Release) zu verfolgen, nicht einzelne Features. Sonst werden Sie schnell mit einer unüberschaubaren Anzahl von Verzweigungen enden.

Warum sollte die Integration überhaupt verzögert werden? Je länger Sie zwischen den Releases warten, desto höher ist die Wahrscheinlichkeit, dass Ihre isolierte Änderung mit einer anderen seither vorgenommenen Änderung in Konflikt gerät und / oder nach der Zusammenführung zu weiterer Instabilität in Ihrem System führt.

Meine bevorzugte Strategie ist, so etwas zu tun:

Nun, sobald Sie bereit für die Veröffentlichung sind:

Ich weiß, dass Sie nach dem besten Weg gefragt haben, wie Sie Ihr kontinuierliches Integrationssystem dazu zwingen können. Aber ich würde respektvoll vorschlagen, dass Hudson als ein relativ fähiges CI-System anerkannt wird, dass die Tatsache, dass Sie eine Menge Probleme damit haben, Ihr Entwicklungsmodell in dieses System einzubetten, ein mögliches Zeichen dafür ist, dass es sich nicht um CI handelt an erster Stelle.

Unsere typische Praxis besteht darin, pro Projekt zwei Basis-Builds zu erstellen: einen gegen den Stamm und einen gegen den aktuellen Release-Zweig. Auf diese Weise wissen Sie Folgendes:

• Was gerade aktualisiert wird, wird korrekt integriert ( trunk )
• Was auch immer Ihr Veröffentlichungsziel ist, wenn Sie jetzt aufgehört hätten zu arbeiten, hätten Sie immer noch eine korrekte und funktionierende (nur nicht voll funktionsfähige) Version.

Hier ist was wir tun (inspiriert von Versionskontrolle für mehrere agile Teams von Henrik Kniberg):

• Entwicklung erfolgt in einem Entwicklungszweig und Funktionen werden nach "done done"
gedrückt
• trunk ist der Zweig "done"
• Zum Zeitpunkt der Veröffentlichung markieren wir den Stamm
• Wenn ein Fehler auftritt, erstellen wir einen Freigabezweig vom Tag
• Defekte werden im Zweig release
gepatcht
• patch wird unmittelbar nach der Veröffentlichung von release branch in trunk zusammengeführt (um es in zukünftige Releases aufzunehmen)

CI wird auf allen Zweigen ausgeführt (Entwicklungszweige, Stamm, Versionszweige).

Das klingt schmerzhaft und übermäßig kompliziert (vom Standpunkt der Verzweigung / Zusammenführung).

Ich würde bei der Veröffentlichung abzweigen und Entwickler in den Kofferraum einchecken lassen. Alles, was als Hotfix herausgehen muss, könnte mit dem Release-Zweig zusammengeführt werden.

Machen Sie eine nächtliche Fusion zu einem "instabil-bösen-Zwilling-Stamm", der alle Bug-Zweige mit dem bösen Zwillingsstamm vereint.

Oder richte nächtliche Builds für jeden Bug-Zweig ein (was sich nach einer Menge nächtlicher Builds anhört).

Meiner Meinung nach hört sich das für eine zentralisierte Stil-Versionskontrolllösung wie eine Menge Verzweigungen an. Vielleicht brauchen Sie ein verteiltes Versionskontrollsystem und einen Build-Server auf jeder Workstation, was das gleiche zu erreichen scheint (isolierte Check-Ins für jeden Entwickler und tägliche Builds auf dem, was die Entwickler einchecken)

Anstatt Verzweigungen für Ihre Fehlerbehebungen zu erstellen, versuchen Sie nicht, Zweige für die Version vor dem Beheben des Fehlers zu erstellen, und wenden Sie dann das Update auf den Stamm an.

Wenn Sie Ihren Kunden den Bugfix geben wollen, geben Sie ihnen die Stammversion. Wenn Sie ihnen den Bugfix nicht geben wollen, können Sie ihnen die Zweigversion geben, bevor Ihr Fix angewendet wurde.

Auf diese Weise können Sie Hudson die Stammleitung erstellen lassen und Ihre nächtlichen Builds werden alle Ihre Bugfixes enthalten.

Ich antworte das sehr, und hier ist, wie IBM es mit ClearCase (UCM) empfiehlt, und ich mache es in der realen Welt:

Alles, was nicht TAG ist, ist eine Verzweigung.