Delta-Deployments in Salesforce: nur ausliefern, was sich geändert hat

Ein Delta-Deployment schickt nur die Metadaten, die sich zwischen zwei Git-Referenzen geändert haben, statt des ganzen Projekts. Du berechnest es, indem du Commits vergleichst, aus dem Diff eine package.xml erzeugst und dieses Manifest deployst. In einem Punkt ist das schneller und risikoärmer als ein vollständiges Deployment, in einem anderen fragiler: Ein Teilpaket kann an Abhängigkeiten scheitern, die ein vollständiges Paket beiläufig miterfüllt hat.

Was ist ein Delta-Deployment in Salesforce?

Ein Delta-Deployment ist ein Metadaten-Deployment, dessen Manifest aus einem Git-Diff stammt und nicht aus deinem gesamten Quellbaum. Drei bewegliche Teile:

• Der Diff. Zwei Git-Referenzen, in der Regel dein Feature-Branch und der Zielbranch des Merges.
• Das Manifest. Eine package.xml mit nur hinzugefügten und geänderten Komponenten, dazu eine destructiveChanges.xml mit Löschungen und Umbenennungen.
• Das Deployment. Ein normales Metadaten-Deployment gegen dieses Manifest.

Nichts davon gehört einem DevOps-Anbieter. Jedes Werkzeug mit Delta-Deployments, Serpent eingeschlossen, führt eine Variante derselben drei Schritte aus.

Wie berechnest du ein Delta-Paket?

Der übliche Open-Source-Weg ist sfdx-git-delta, das Plugin, das der Salesforce Developers Blog für unpackaged Sources durchgespielt hat. Wichtig: Es ist ein inoffizielles, von der Community gepflegtes Plugin. Behandle es als Abhängigkeit, die dir gehört.

1. Sorge dafür, dass dein CI-Checkout genug Git-Historie hat. Ein Shallow Clone mit Tiefe eins kann nicht gegen einen Basis-Branch diffen, und das ist mit Abstand der häufigste Grund für ein leeres oder falsches Delta-Paket.
2. Erzeuge das Manifest: sf sgd source delta --from origin/main --to HEAD --output-dir .
3. Setze --generate-delta, wenn die geänderten Quelldateien mit herauskopiert werden sollen. Nur verwenden, wenn --to HEAD ist.
4. Sichere dich gegen ein leeres Manifest ab. Ein Deployment mit leerer package.xml schlägt fehl, also sollte deine Pipeline den Schritt überspringen statt zu brechen.
5. Deploye und wende Löschungen nach den Ergänzungen an: sf project deploy start -x package/package.xml --post-destructive-changes destructiveChanges/destructiveChanges.xml
6. Validiere zuerst. Fahre dasselbe Manifest als Check-only-Deployment gegen das Ziel, bevor du echt deployst.

Welche Abhängigkeitsfallen lassen Delta-Deployments scheitern?

Das ist der Teil, den Tutorials auslassen. Ein vollständiges Deployment trägt jede Komponente, also lösen sich implizite Abhängigkeiten stillschweigend auf. Ein Delta trägt eine Teilmenge, und jede zuvor unsichtbare Abhängigkeit wird zum Fehler.

Profile und Berechtigungssätze

Füge ein Feld im Delta hinzu: Der Zugriff darauf liegt im Profil, einer eigenen Datei. Hat sich diese Datei nicht geändert, ist sie nicht im Delta, und das Feld landet im Ziel, ohne dass es jemand sieht. Die Retrieve-Seite verschärft das: Salesforce liefert nur Sicherheitseinstellungen für die im Retrieve genannten Metadatentypen, wobei Benutzerberechtigungen, IP-Bereiche und Anmeldezeiten immer dabei sind. Deploye Profile bewusst, statt den Diff entscheiden zu lassen.

Auswahllisten, Datensatztypen und Übersetzungen

Einen Auswahllistenwert zu entfernen berührt Datensatztypen und Übersetzungen, die ihn referenzieren. sfdx-hardis hat Delta mit Abhängigkeiten genau dafür gebaut, denn der Fehler zeigt sich oft gar nicht im Delta-Deployment. Er zeigt sich im nächsten vollständigen Deployment, Wochen später, in einer anderen Pipeline.

Apex-Tests

Deployst du eine geänderte Klasse unter RunSpecifiedTests, muss ihre Testklasse im Ziel liegen und in der Testliste stehen. Ein Delta mit der Klasse, aber ohne den Test, ist ein Abdeckungsfehler, der auf die Produktion wartet.

Flows

Das Löschen eines Flows über destructiveChanges.xml ist eine dokumentierte Plattformlücke. Der Umweg ist, ihn zuerst zu deaktivieren, indem du eine FlowDefinition mit activeVersionNumber auf null deployst.

Metadaten in einer einzigen Datei

Benutzerdefinierte Labels, Workflows und Matching Rules packen viele Mitglieder in eine Datei. Eine Zeilenänderung markiert die ganze Datei als geändert, und ihr erzwungenes Einschließen braucht die vollständige Git-Historie, keinen Shallow Clone.

Umbenennungen

Git sieht eine Umbenennung als Löschen plus Hinzufügen. In falscher Reihenfolge deployt, löschst du eine noch referenzierte Komponente oder erzeugst ein Duplikat. Genau dafür gibt es die post-destruktive Reihenfolge.

Wann solltest du vollständig statt delta deployen?

Ein brauchbarer Standard, und der, den sfdx-hardis mitbringt: Delta für Feature-Branches, die in einen gemeinsamen Branch mergen, und vollständige Deployments zwischen gemeinsamen Umgebungen. Die Begründung: Je weiter oben in der Pipeline, desto wahrscheinlicher ist das Ziel von der Versionskontrolle abgedriftet, und ein Delta setzt voraus, dass die Versionskontrolle die Wahrheit ist.

Geh vollständig, wenn eines davon zutrifft:

• Die Ziel-Org hat seit dem letzten Deployment manuelle Änderungen erhalten.
• Die Änderung berührt Profile, Berechtigungssätze oder Freigaberegeln breit.
• Du promotest zwischen zwei langlebigen Umgebungen, statt ein Feature zu mergen.
• Du erholst dich von einem fehlgeschlagenen oder teilweise angewendeten Deployment.

Behalte eine manuelle Übersteuerung. sfdx-hardis nutzt eine NO_DELTA-Markierung im Commit-Titel, ein gutes Muster für jedes Werkzeug: Wer weiß, dass eine Änderung riskant ist, muss ein vollständiges Deployment erzwingen können, ohne Pipeline-Konfiguration anzufassen.

Wie sieht eine sichere Delta-Pipeline aus?

1. Vollständiger Clone, oder mindestens genug Tiefe bis zur Merge-Basis.
2. Manifest erzeugen und ins Build-Log drucken, damit ein Mensch liest, was gleich ausgeliefert wird.
3. Sauber überspringen, wenn das Manifest leer ist.
4. Check-only-Deployment, dann das echte, destruktive Änderungen zuletzt.
5. Vollständiges Deployment nach Plan, wöchentlich oder pro Release, um die Drift zu fangen, die kein Delta berührt hat.

Genau diesen letzten Schritt lassen Teams fallen, und genau er fängt die Auswahllisten-und-Übersetzungen-Klasse von Fehlern, bevor ein Release auf dem Spiel steht. Weitere Playbooks zur Salesforce-Auslieferung stehen in unserer SF Guides-Bibliothek.

FAQ

Sind Delta-Deployments sicherer als vollständige?

Sie sind schneller und berühren weniger, was den Wirkungsradius senkt. Sicherer sind sie nicht von sich aus, denn ein Teilpaket kann eine Abhängigkeit verfehlen, die ein vollständiges Paket mitgetragen hätte.

Brauche ich sfdx-git-delta für Delta-Deployments?

Nein. Es ist der verbreitetste Open-Source-Weg, inoffiziell und von der Community gepflegt. Die meisten kommerziellen Salesforce-DevOps-Plattformen berechnen das Delta für dich.

Warum ist mein Delta-Paket in CI leer, lokal aber nicht?

Fast immer ein Shallow Clone. Dein CI-Checkout braucht genug Git-Historie, um den Referenz-Commit zu erreichen.

Wie lösche ich Metadaten in einem Delta-Deployment?

Über destructiveChanges.xml, angewendet nach dem additiven Paket. Flows sind die Ausnahme: Deaktiviere sie zuerst per FlowDefinition-Änderung.

Sollten Profile Teil des Deltas sein?

Deploye sie bewusst, statt den Diff entscheiden zu lassen. Profildateien tragen nur Einstellungen für die im Retrieve enthaltenen Metadatentypen, ein diffgetriebenes Profil ist also selten das gemeinte.