Destruktive Änderungen in einem Salesforce-Deployment sicher handhaben

Metadaten löschst du in Salesforce mit einem destructiveChanges.xml-Manifest, das du zusammen mit einer package.xml deployst, wobei du wählst, ob die Löschungen vor oder nach dem additiven Teil laufen. Gefährlich ist nicht die Syntax. Gefährlich ist, dass eine erfolgreiche Löschung von keinem Deployment-Rollback rückgängig gemacht wird, und dass ausgerechnet die Komponenten brechen, die niemand in der Versionskontrolle hat.

Was ist ein destructiveChanges-Manifest?

Ein destructiveChanges-Manifest nutzt dasselbe Format wie package.xml, mit einem wichtigen Unterschied: Platzhalter werden nicht unterstützt. Jede zu entfernende Komponente muss namentlich genannt werden.

Ein minimaler Eintrag sieht so aus: <types><members>Account.Legacy_Score__c</members><name>CustomField</name></types>.

Zwei Regeln, über die man beim ersten Versuch stolpert:

• Eine package.xml muss weiterhin vorhanden sein, im selben Verzeichnis. Bei einem reinen Lösch-Deployment trägt sie die API-Version und listet keine Komponenten.
• Löschversuche laufen weiter, auch wenn gelistete Komponenten im Ziel nicht existieren. Das ist bequem, und es bedeutet zugleich, dass ein Tippfehler leise scheitert statt laut.

Sollen Löschungen vor oder nach dem Deployment laufen?

Die Salesforce CLI bietet beides über zwei getrennte Manifeste: --pre-destructive-changes löscht vor dem Deployment, --post-destructive-changes danach.

Nimm standardmäßig post-destructive. Das additive Paket landet zuerst, sodass alles, was die verurteilte Komponente noch referenziert, im selben Deployment umgehängt werden kann, bevor sie verschwindet.

Nimm pre-destructive, wenn Alt und Neu kollidieren. Die klarsten Fälle:

• Du verwendest einen API-Namen für eine andere Komponente wieder.
• Du änderst den Typ eines Feldes, indem du es löschst und neu anlegst.
• Eine Validierungsregel oder ein Pflichtfeld würde die Daten- oder Konfigurationsänderung blockieren, die du ausrollst.

Vertauscht ergibt das die zwei klassischen Fehler: eine Löschung, die scheitert, weil noch etwas referenziert, oder eine Ergänzung, die scheitert, weil der Name belegt ist.

Was nimmt eine Löschung tatsächlich mit?

Hier lohnt Deutlichkeit. Ein Feld zu löschen löscht seine Daten. Gelöschte Komponenten wandern in den Papierkorb, es sei denn, das Deployment setzt purgeOnDelete, womit sie sofort zur Löschung freigegeben sind. Rollup-Summenfelder umgehen den Papierkorb unabhängig von dieser Einstellung.

Und rollbackOnError, für Produktions-Deployments verpflichtend, macht die Änderungen eines fehlgeschlagenen Deployments rückgängig. Es ist kein Rückgängig-Knopf für eine erfolgreiche Löschung. Brauchst du die Daten nach einer erfolgreichen Bereinigung zurück, führst du ein Wiederherstellungsgespräch, kein Deployment-Gespräch.

Es gibt außerdem eine Kategorie von Schaden, die nie im Repository auftaucht: Berichte, Listenansichten und Dashboards, die das Feld referenzieren. Das ist Konfiguration, die ein Fachanwender gebaut hat, meist nicht in Git, und das Deployment warnt dich nicht davor.

Welche Vorabprüfungen verhindern eine missglücke Feldlöschung?

1. Führe die Abhängigkeitsprüfung im Setup aus. Salesforce meldet Formelfelder, Validierungsregeln, Layouts und andere deklarative Referenzen. Notwendig, aber nicht hinreichend.
2. Suche die Metadaten nach API-Namen. Greppe das Repository. Flows, Apex, E-Mail-Vorlagen und Berechtigungssätze referenzieren Felder als Zeichenketten, und solche Referenzen erscheinen nicht in jeder Abhängigkeitsansicht.
3. Prüfe Berichte und Listenansichten separat. Nichts in deiner Pipeline weiß von ihnen. Jemand muss nachsehen.
4. Exportiere zuerst die Daten. Eine CSV mit der Spalte und den Datensatz-IDs. Kostet zehn Minuten und ist das einzige echte Auffangnetz.
5. Führe die lokalen Tests aus. Für Apex-Klassen und -Trigger empfiehlt Salesforce selbst, alle lokalen Tests laufen zu lassen, denn so findest du Code, der die zu löschende Sache noch referenziert.
6. Prüfe auf eine aktive Lightning-Seite. Eine Komponente, die zu einer aktiven Lightning-Seite gehört, lässt sich nicht löschen. Deaktiviere zuerst die Aktionsüberschreibung im Lightning App Builder.
7. Validiere gegen die Produktion. Ein checkOnly-Deployment oder --dry-run aus der CLI validiert und führt Tests aus, ohne etwas zu speichern.

Wie verteilst du eine Löschung auf zwei Releases?

Das sichere Muster ist kein besseres Manifest. Es ist, die Löschung auf zwei Releases zu teilen.

1. Release N, Abkündigung. Entferne jede Referenz: Layouts, Formeln, Flows, Apex, Berechtigungssätze, Berichte. Markiere das Feld in seiner Beschreibung als abgekündigt, damit die nächste Person es weiß. Schreibe nicht mehr hinein. Liefere nichts Destruktives aus.
2. Ruhen lassen. Lass einen Berichtszyklus vergehen. Dann taucht der Bericht auf, den niemand erwähnt hat, und er taucht als Frage auf statt als Störung.
3. Release N+1, löschen. Exportiere die Daten und deploye dann das destructiveChanges-Manifest allein, ohne alles andere.

Eine Löschung allein auszuliefern ist wichtig. Steckt sie zwischen zwanzig anderen Änderungen und etwas geht schief, isolierst du die Ursache nicht schnell, und der Rollback nimmt die guten Änderungen mit.

Dieselbe Disziplin gilt für Umbenennungen, die Git als Löschen plus Hinzufügen erfasst. Behandle jede Umbenennung als zweistufige Abkündigung, es sei denn, du kannst beweisen, dass nichts den alten Namen referenziert. Weitere Auslieferungs-Playbooks stehen in unserer SF Guides-Bibliothek.

FAQ

Kann ich in destructiveChanges.xml einen Platzhalter verwenden?

Nein. Platzhalter werden nicht unterstützt. Jede zu löschende Komponente muss ausdrücklich genannt werden.

Brauche ich eine package.xml, wenn ich nur lösche?

Ja. Sie muss im selben Verzeichnis liegen, die API-Version tragen und keine Komponenten listen.

Kann ich ein per Deployment gelöschtes Feld wiederherstellen?

Es landet im Papierkorb, sofern purgeOnDelete nicht gesetzt war, und Rollup-Summenfelder umgehen den Papierkorb ohnehin. Betrachte den Datenexport als den echten Wiederherstellungsplan.

Warum war mein destruktives Deployment erfolgreich, hat aber nichts gelöscht?

Löschversuche laufen weiter, wenn eine gelistete Komponente im Ziel fehlt. Ein falscher API-Name erzeugt also ein grünes Deployment und keine Änderung. Vergleiche das Ziel vorher und nachher.

Wann sollten Löschungen vor statt nach dem Deployment laufen?

Wenn alte und neue Komponenten in Konflikt stehen: Wiederverwendung eines API-Namens, Neuanlage eines Feldes mit anderem Typ, oder Entfernen einer Regel, die den Rest des Deployments blockieren würde.