Menü
Avatar von Oliver Gierke
  • Oliver Gierke

10 Beiträge seit 10.07.2012

Spezielle Annahmen die zu (IMO) falschen Schlussfolgerungen führen.

Änderungen aus den verschiedenen Feature Branches werden nicht mehr integriert.

Das ist ja erstmal eine Behauptung. Vor allem die negativste Annahme die man treffen kann. Daraus eine allgemein gültige Konsequenz abzuleiten halte ich für gewagt.

Stattdessen gibt es eine Integration zu den Zeitpunkten, wenn die Feature Branches wieder eingestellt werden.

Auch das ist eine sehr negativ verallgemeinernde Annahme und keineswegs eine unumstößliche Sache. Moderne Versionskontrollsysteme kennen ein Rebasing, die es ermöglichen die Integration auf der *Featureseite* und *zu explizit gewählten Zeitpunkten* vorzunehmen.

Ich würde auch behaupten, dass große Mergeprobleme mit Featurebranches hauptsächlich Indikatoren für schlechte Featureisolation bzw. suboptimales Softwaredesign (für verschiedene neue Features muss der gleiche Code angefasst werden) sind. Hier gilt im Zweifel: don't shoot the Messenger

Für mich scheint der Artikel anzunehmen, dass "continuous" zwangsläufig und hart anzunehmen dass jede Änderung sofort integriert werden muss. Wo aber ist da die endgültige Granularität? In einem CD Prozess führ ein Commit auf einer Masterbranch zu einem Deployment. D.h. man kommt zu einem Modell in dem ein Commit ein System von einem funktionierenden Zustand A in einen funktionierenden Zustand B überführt. D.h. es gibt einen gewissen Qualitäts- und Umfangsanspruch an einen Commit. Wenn ich diesen gleichzeitig mit der Anforderung verknüpfe immer in eine Branch zu committen führt das zu folgendem:

- es ist faktisch keine kontrollierte Integration mehr, da man um Code auszutauschen den im Master haben muss
- Commits bzw. pushes werden zurückgehalten, weil man "nichts unfertiges committen will". Dies sorgt für größere Commits die schwerer zu integrieren sind.

D.h. Featurebranches haben eigentlich nur die Aufgabe zwei orthogonale Aspekte (Qualität & Umfang, Integrationszeitpunkt) voneinander zu separieren. Klassisches SoC in meinen Augen.

Wenn man nun in diesem Modell zwangsläufig von negativer Auslegung (Langlebigkeit, einziger Integrationszeitpunkt Merge) ausgeht, gleichzeitig aber beim alternativen Ansatz alle negativen Folgen ausklammert, kommt man exakt zu diesem Bild. Man kann alternativ auch ein positives Bild von Featurebranches zeichnen:

- kurzlebige Branches, viele kleine Commits
- regelmäßiges Rebasen (aka. *kontrollierte* Integration auf der Featureseite - ich sorge dafür, dass mein Feature kontinuierlich in den master mergebar bleibt)
- regelmäßige automatisierte Builds der Featurebranches
- *kontrolliertes*, finales Integrieren/Mergen der Feturebranch in die Masterbranch

Continuous Delivery gut und schön, ich vermute allerdings schon, dass man gern ein wenig Kontrolle darüber hat, was man da kontinuierlich ausliefert ;).

Bewerten
- +
Anzeige