Delta-Deployments in Salesforce: nur ausliefern, was sich geaendert hat

Ein Delta-Deployment schickt nur die Metadaten, die sich zwischen zwei Git-Referenzen geaendert 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 risikoaermer als ein vollstaendiges Deployment, in einem anderen fragiler: Ein Teilpaket kann an Abhaengigkeiten scheitern, die ein vollstaendiges Paket beilaeufig miterfuellt 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 hinzugefuegten und geaenderten Komponenten, dazu eine destructiveChanges.xml mit Loeschungen und Umbenennungen.
• Das Deployment. Ein normales Metadaten-Deployment gegen dieses Manifest.

Nichts davon gehoert einem DevOps-Anbieter. Jedes Werkzeug mit Delta-Deployments, Serpent eingeschlossen, fuehrt eine Variante derselben drei Schritte aus.

Wie berechnest du ein Delta-Paket?

Der uebliche Open-Source-Weg ist sfdx-git-delta, das Plugin, das der Salesforce Developers Blog fuer unpackaged Sources durchgespielt hat. Wichtig: Es ist ein inoffizielles, von der Community gepflegtes Plugin. Behandle es als Abhaengigkeit, die dir gehoert.

1. Sorge dafuer, 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 haeufigste Grund fuer 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 geaenderten 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 schlaegt fehl, also sollte deine Pipeline den Schritt ueberspringen statt zu brechen.
5. Deploye und wende Loeschungen nach den Ergaenzungen 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 Abhaengigkeitsfallen lassen Delta-Deployments scheitern?

Das ist der Teil, den Tutorials auslassen. Ein vollstaendiges Deployment traegt jede Komponente, also loesen sich implizite Abhaengigkeiten stillschweigend auf. Ein Delta traegt eine Teilmenge, und jede zuvor unsichtbare Abhaengigkeit wird zum Fehler.

Profile und Berechtigungssaetze

Fuege ein Feld im Delta hinzu: Der Zugriff darauf liegt im Profil, einer eigenen Datei. Hat sich diese Datei nicht geaendert, ist sie nicht im Delta, und das Feld landet im Ziel, ohne dass es jemand sieht. Die Retrieve-Seite verschaerft das: Salesforce liefert nur Sicherheitseinstellungen fuer 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 Uebersetzungen

Einen Auswahllistenwert zu entfernen beruehrt Datensatztypen und Uebersetzungen, die ihn referenzieren. sfdx-hardis hat Delta mit Abhaengigkeiten genau dafuer gebaut, denn der Fehler zeigt sich oft gar nicht im Delta-Deployment. Er zeigt sich im naechsten vollstaendigen Deployment, Wochen spaeter, in einer anderen Pipeline.

Apex-Tests

Deployst du eine geaenderte 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 Loeschen eines Flows ueber destructiveChanges.xml ist eine dokumentierte Plattformluecke. 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 Zeilenaenderung markiert die ganze Datei als geaendert, und ihr erzwungenes Einschliessen braucht die vollstaendige Git-Historie, keinen Shallow Clone.

Umbenennungen

Git sieht eine Umbenennung als Loeschen plus Hinzufuegen. In falscher Reihenfolge deployt, loeschst du eine noch referenzierte Komponente oder erzeugst ein Duplikat. Genau dafuer gibt es die post-destruktive Reihenfolge.

Wann solltest du vollstaendig statt delta deployen?

Ein brauchbarer Standard, und der, den sfdx-hardis mitbringt: Delta fuer Feature-Branches, die in einen gemeinsamen Branch mergen, und vollstaendige Deployments zwischen gemeinsamen Umgebungen. Die Begruendung: 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 vollstaendig, wenn eines davon zutrifft:

• Die Ziel-Org hat seit dem letzten Deployment manuelle Aenderungen erhalten.
• Die Aenderung beruehrt Profile, Berechtigungssaetze 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 Uebersteuerung. sfdx-hardis nutzt eine NO_DELTA-Markierung im Commit-Titel, ein gutes Muster fuer jedes Werkzeug: Wer weiss, dass eine Aenderung riskant ist, muss ein vollstaendiges Deployment erzwingen koennen, ohne Pipeline-Konfiguration anzufassen.

Wie sieht eine sichere Delta-Pipeline aus?

1. Vollstaendiger 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 ueberspringen, wenn das Manifest leer ist.
4. Check-only-Deployment, dann das echte, destruktive Aenderungen zuletzt.
5. Vollstaendiges Deployment nach Plan, woechentlich oder pro Release, um die Drift zu fangen, die kein Delta beruehrt hat.

Genau diesen letzten Schritt lassen Teams fallen, und genau er faengt die Auswahllisten-und-Uebersetzungen-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 vollstaendige?

Sie sind schneller und beruehren weniger, was den Wirkungsradius senkt. Sicherer sind sie nicht von sich aus, denn ein Teilpaket kann eine Abhaengigkeit verfehlen, die ein vollstaendiges Paket mitgetragen haette.

Brauche ich sfdx-git-delta fuer 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 fuer 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 loesche ich Metadaten in einem Delta-Deployment?

Ueber destructiveChanges.xml, angewendet nach dem additiven Paket. Flows sind die Ausnahme: Deaktiviere sie zuerst per FlowDefinition-Aenderung.

Sollten Profile Teil des Deltas sein?

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