Destruktive Aenderungen in einem Salesforce-Deployment sicher handhaben

Metadaten loeschst du in Salesforce mit einem destructiveChanges.xml-Manifest, das du zusammen mit einer package.xml deployst, wobei du waehlst, ob die Loeschungen vor oder nach dem additiven Teil laufen. Gefaehrlich ist nicht die Syntax. Gefaehrlich ist, dass eine erfolgreiche Loeschung von keinem Deployment-Rollback rueckgaengig 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 unterstuetzt. 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, ueber die man beim ersten Versuch stolpert:

• Eine package.xml muss weiterhin vorhanden sein, im selben Verzeichnis. Bei einem reinen Loesch-Deployment traegt sie die API-Version und listet keine Komponenten.
• Loeschversuche 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 Loeschungen vor oder nach dem Deployment laufen?

Die Salesforce CLI bietet beides ueber zwei getrennte Manifeste: --pre-destructive-changes loescht vor dem Deployment, --post-destructive-changes danach.

Nimm standardmaessig post-destructive. Das additive Paket landet zuerst, sodass alles, was die verurteilte Komponente noch referenziert, im selben Deployment umgehaengt werden kann, bevor sie verschwindet.

Nimm pre-destructive, wenn Alt und Neu kollidieren. Die klarsten Faelle:

• Du verwendest einen API-Namen fuer eine andere Komponente wieder.
• Du aenderst den Typ eines Feldes, indem du es loeschst und neu anlegst.
• Eine Validierungsregel oder ein Pflichtfeld wuerde die Daten- oder Konfigurationsaenderung blockieren, die du ausrollst.

Vertauscht ergibt das die zwei klassischen Fehler: eine Loeschung, die scheitert, weil noch etwas referenziert, oder eine Ergaenzung, die scheitert, weil der Name belegt ist.

Was nimmt eine Loeschung tatsaechlich mit?

Hier lohnt Deutlichkeit. Ein Feld zu loeschen loescht seine Daten. Geloeschte Komponenten wandern in den Papierkorb, es sei denn, das Deployment setzt purgeOnDelete, womit sie sofort zur Loeschung freigegeben sind. Rollup-Summenfelder umgehen den Papierkorb unabhaengig von dieser Einstellung.

Und rollbackOnError, fuer Produktions-Deployments verpflichtend, macht die Aenderungen eines fehlgeschlagenen Deployments rueckgaengig. Es ist kein Rueckgaengig-Knopf fuer eine erfolgreiche Loeschung. Brauchst du die Daten nach einer erfolgreichen Bereinigung zurueck, fuehrst du ein Wiederherstellungsgespraech, kein Deployment-Gespraech.

Es gibt ausserdem 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 Vorabpruefungen verhindern eine missgluecke Feldloeschung?

1. Fuehre die Abhaengigkeitspruefung 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 Berechtigungssaetze referenzieren Felder als Zeichenketten, und solche Referenzen erscheinen nicht in jeder Abhaengigkeitsansicht.
3. Pruefe Berichte und Listenansichten separat. Nichts in deiner Pipeline weiss 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. Fuehre die lokalen Tests aus. Fuer Apex-Klassen und -Trigger empfiehlt Salesforce selbst, alle lokalen Tests laufen zu lassen, denn so findest du Code, der die zu loeschende Sache noch referenziert.
6. Pruefe auf eine aktive Lightning-Seite. Eine Komponente, die zu einer aktiven Lightning-Seite gehoert, laesst sich nicht loeschen. Deaktiviere zuerst die Aktionsueberschreibung im Lightning App Builder.
7. Validiere gegen die Produktion. Ein checkOnly-Deployment oder --dry-run aus der CLI validiert und fuehrt Tests aus, ohne etwas zu speichern.

Wie verteilst du eine Loeschung auf zwei Releases?

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

1. Release N, Abkuendigung. Entferne jede Referenz: Layouts, Formeln, Flows, Apex, Berechtigungssaetze, Berichte. Markiere das Feld in seiner Beschreibung als abgekuendigt, damit die naechste Person es weiss. Schreibe nicht mehr hinein. Liefere nichts Destruktives aus.
2. Ruhen lassen. Lass einen Berichtszyklus vergehen. Dann taucht der Bericht auf, den niemand erwaehnt hat, und er taucht als Frage auf statt als Stoerung.
3. Release N+1, loeschen. Exportiere die Daten und deploye dann das destructiveChanges-Manifest allein, ohne alles andere.

Eine Loeschung allein auszuliefern ist wichtig. Steckt sie zwischen zwanzig anderen Aenderungen und etwas geht schief, isolierst du die Ursache nicht schnell, und der Rollback nimmt die guten Aenderungen mit.

Dieselbe Disziplin gilt fuer Umbenennungen, die Git als Loeschen plus Hinzufuegen erfasst. Behandle jede Umbenennung als zweistufige Abkuendigung, 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 unterstuetzt. Jede zu loeschende Komponente muss ausdruecklich genannt werden.

Brauche ich eine package.xml, wenn ich nur loesche?

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

Kann ich ein per Deployment geloeschtes 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 geloescht?

Loeschversuche laufen weiter, wenn eine gelistete Komponente im Ziel fehlt. Ein falscher API-Name erzeugt also ein gruenes Deployment und keine Aenderung. Vergleiche das Ziel vorher und nachher.

Wann sollten Loeschungen 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 wuerde.