Fabric CI/CD: mergen oder Cherry-Pick?

Das Wichtigste in Kürze

In Fabric-Leitern mit mehreren Devs (test → staging → main) ist der Tip selten komplett fertig.
Wer den ganzen Tip mergt, befördert unfertige Arbeit zusammen mit der fertigen.
Sicherer: ausgewählte Squash-Merge-Commits per Cherry-Pick auf einen kurzlebigen Promotion-Branch übernehmen, dann einen PR in die nächste Umgebung öffnen.
Cherry-Pick ohne Temp-Branch + PR ist unvollständige Promotion-Hygiene.
Kombiniere die Auswahl in git mit Variable Library und dem Rebind der Items. git allein ist noch kein Deployment.
Bei großem Umfang ist die Cherry-Pick-Hölle real. Verkleinere das Release-Set und dokumentiere die Pick-Liste schriftlich.

Du hast drei Entwickler auf test. Feature A ist erprobt. Feature B ist halb fertig. Feature C zeigt noch auf einen Wegwerf-Spike. Jemand öffnet einen PR vom Tip von test nach staging, weil "die Leiter eben so funktioniert". Jetzt gehört staging unfertige Arbeit, die du nie dorthin bringen wolltest.

Befördere per Commit, nicht per Tip. Wähle die fertigen Squash-Merge-Commits aus, parke sie auf einem kurzlebigen Promotion-Branch, öffne einen PR in den Branch der nächsten Umgebung und deploye dann. So bleibt der Blast Radius ehrlich.

Benanntes Modell: per Commit befördern, nicht per Tip

Tip: der aktuelle Stand eines Umgebungs-Branches (test, staging, main). In einem Repo mit mehreren Devs mischt er oft fertige und unfertige Arbeit.
Ausgewählte Commits: Squash-Merge-SHAs, die du als Release-Set für diese Beförderung benennen kannst.
Promotion-Branch: ein kurzlebiger Branch, abgezweigt vom Tip der nächsten Umgebung. Die Cherry-Picks landen hier, nicht auf dem geschützten Branch der Leiter.
PR-Schranke: Temp-Branch → nächste Umgebung. Review, Checks und Rebind laufen mit dem PR. Der Cherry-Pick allein ist nicht die Schranke.
Vertrag: Der Blast Radius entspricht den Commits, die du benannt hast, nicht allem, was zufällig auf dem Tip lag.

Benanntes Modell: Beförderung per Tip gegenüber Beförderung ausgewählter Commits

Abbildung 1. Benanntes Modell: per Commit befördern, nicht per Tip. Ein Merge des Tips erbt unfertige Arbeit. Ausgewählte Squash Commits lassen Unfertiges auf der unteren Stufe.

Kontext und Rahmenbedingung

Diese Notiz behandelt die Form der Beförderung in git über eine Leiter von Fabric-Umgebungen. Sie steht neben Fabric CI/CD Blast Radius, wo es um eine andere Frage geht: was der Deployer im Workspace abgleicht, sobald du eine Beförderung auslöst. Hier geht es darum, welche Commits du auf den nächsten Branch lässt, bevor dieses Deployment läuft.

Die Rahmenbedingungen: mehrere Entwickler, unfertige Features auf test, und du musst gezielt nach staging oder main befördern, ohne auf jede laufende Änderung zu warten. Klassische Diagramme, in denen die Leiter einfach gemergt wird, sehen auf einer Folie sauber aus. Sie brechen, sobald der Tip ein gemeinsamer Parkplatz ist.

Community-Threads zu Microsoft Fabric CI/CD landen immer wieder bei derselben Klarstellung: Cherry-Pick ist kein einzelnes git cherry-pick direkt auf den geschützten nächsten Branch. Es ist ein Cherry-Pick auf einen Temp-Branch und danach ein PR von diesem Branch in die nächste Umgebung. Genau dieses Modell zeigt diese Notiz.

Design

1. Den Tip ehrlich aufzeichnen

Liste auf, was auf dem Tip von test liegt, bevor du einen PR die Leiter hinauf öffnest. Fertiges Feature A. Unfertiges Feature B. Reste des Spikes für C. Wenn du die unfertigen Teile nicht benennen kannst, bist du nicht bereit, den Tip zu mergen. Abbildung 2 zeigt die Gabelung: Merge des Tips gegenüber ausgewählten Squash Commits.

Merge des Tips mit A plus unfertiger Arbeit gegenüber der Auswahl nur fertiger Squash Commits

Abbildung 2. Weg A mergt den ganzen Tip und befördert unfertige Arbeit. Weg B wählt fertige Squash Commits aus. Unfertiges bleibt auf test, bis es ein eigenes Release-Set hat.

2. Squash-Merge-SHAs als Release-Einheit bevorzugen

Feature-PRs, die als Squash Merge landen, geben dir einen SHA pro Feature. Dieser SHA ist die kleinste Einheit der Beförderung. Ohne Squash (oder einen gleichwertigen Vertrag für saubere Commits) wird gezielte Beförderung zur Archäologie in unübersichtlichen Merge Commits. Schreibe das Release-Set als Liste von SHAs und Verantwortlichen auf, bevor jemand git anfasst.

3. Einen kurzlebigen Promotion-Branch nutzen, dann einen PR

Zweige promote/test-to-staging-<date> (oder etwas Ähnliches) vom Tip von staging ab, nicht vom Tip von test. Übernimm die benannten SHAs per Cherry-Pick auf diesen Temp-Branch. Löse Konflikte dort. Öffne einen PR nach staging. Pushe Cherry-Picks nicht direkt auf geschützte Umgebungs-Branches. Abbildung 3 zeigt diese vier Schritte.

Commits auswählen, Temp-Branch, PR, dann Deployment

Abbildung 3. Der Cherry-Pick isoliert das Change-Set. Der PR ist die Schranke der Beförderung. Das Deployment läuft nach dem Merge, mit Variable Library und Rebind im selben Ablauf.

4. Ein Deployment bleibt ein Eingriff in den Workspace

Nach dem Merge des PR entscheiden immer noch fabric-cicd oder Deployment Pipelines, was im Workspace abgeglichen wird. Eine ausgewählte git-Historie verkleinert einen blinden Publish in den Workspace nicht von selbst. Behalte Item-Filter, Dry-Runs und die Liste "niemals blind" aus der Notiz zum Blast Radius. Kombiniere diese Beförderung mit Variable Library Deploy-Ziele, damit Lakehouse- und Workspace-IDs pro Stufe neu zugeordnet werden, statt mit den Bindungen aus Dev nach oben zu wandern.

5. Wissen, wann ein Merge des Tips trotzdem richtig ist

Wenn der Tip ein Release-Zug ist, der komplett fertig ist (jedes offene Feature ist ausgeliefert oder vom Branch entfernt), ist der Merge des Tips ehrlich und günstiger. Gezielter Cherry-Pick ist für den häufigen Fall mit mehreren Devs gedacht, in dem test bewusst gemischt ist. Erfinde kein Cherry-Pick-Theater, wenn der Tip sauber ist.

6. Die Cherry-Pick-Hölle begrenzen

Bei großem Umfang machen lange Rückstände von Commits zwischen den Stufen das Picken einzeln mühsam. Verkleinere Release-Züge, halte Features klein, nimm lieber weniger SHAs pro Beförderung und entferne aufgegebene Arbeit vom unteren Branch, damit sie nicht jede Pick-Liste heimsucht. Dokumentiere die Pick-Liste schriftlich im PR-Text, damit die nächste Person nicht raten muss.

Häufige Fehler

Den Tip mergen, weil das Diagramm der Leiter es so zeigt. Unfertige Notebooks und Bindungen landen mit einem grünen Merge in staging.

Cherry-Pick auf den geschützten Umgebungs-Branch ohne PR. Kein Ort für ein Review, keine Checks, kein schriftliches Release-Set, schwer zu auditieren.

Den PR nach einem lokalen Cherry-Pick vergessen. Der Temp-Branch liegt auf einem Laptop. Die nächste Umgebung bekommt die Änderung nie. Die Person glaubt, sie hätte befördert.

Cherry-Pick als reines git behandeln, ohne Rebind. Die Items wandern, aber Lakehouse- und Verbindungs-IDs zeigen noch auf die untere Stufe. Das Deployment ist "erfolgreich". Die Datenebene lügt.

Cherry-Pick-Hölle ohne Hygiene bei den Release-Zügen. Lange Rückstände von Commits, unklare Verantwortliche, Stürme von Konflikten. Unter Druck fällt der Prozess zurück auf Merges des Tips.

Variable Library und Deployment-Regeln überspringen. Auch eine gezielte Beförderung in git braucht Bindungen, die für jede Stufe passen. Die Auswahl in git ersetzt nicht die Zuordnung der Umgebungen.

So übernehmen oder anpassen

So übernehmen

Per Commit befördern, nicht per Tip, wenn unfertige Arbeit auf der unteren Stufe liegt.
Ein schriftliches Release-Set aus Squash-Merge-SHAs, bevor der Cherry-Pick beginnt.
Ein kurzlebiger Promotion-Branch, abgezweigt vom Tip der nächsten Umgebung, dann ein PR in diese Umgebung.
Deployment nach dem Merge mit Dry-Run in fabric-cicd oder der Pipeline und Neuzuordnung über Variable Library.
Ein Merge des Tips nur dann, wenn der Tip ehrlich komplett fertig ist.
Ein PR-Text, der SHAs, Verantwortliche und Hinweise zum Rebind auflistet.

Vor dem Einsatz anpassen

Cherry-Pick kostet Betriebsaufwand. Ein Merge des Tips ist günstiger, wenn der Tip sauber ist. Einem Team mit Trunk-based Development, das main laufend deployt, gezielte Beförderung aufzuzwingen, ist vielleicht die falsche Form. Richte das Modell danach aus, wie viele unfertige Features tatsächlich einen langlebigen Umgebungs-Branch teilen. Kopiere außerdem nicht "Cherry-Pick für immer", ohne die Züge zu verkleinern. Die Hölle bei großem Umfang ist ein Zeichen für schlechtes Design, kein Abzeichen für Gründlichkeit.

Fabric CI/CD: Die ganze Leiter mergen oder nur Fertiges per Cherry-Pick?