Rollback-Strategien für fehlgeschlagene Salesforce-Deployments

Kurze Antwort: Salesforce hat keinen Rückgängig-Knopf. Ein fehlgeschlagenes Produktiv-Deployment macht sich selbst rückgängig, weil rollbackOnError in der Produktion auf true stehen muss. Ein Deployment, das durchläuft und sich als falsch herausstellt, müssen Sie dagegen selbst zurücknehmen. Realistisch bleiben drei Wege: ein umgekehrtes Deployment aus einem Snapshot vor der Release, gezielte destructive changes oder ein Fix nach vorn. Welcher davon Ihnen offensteht, entscheidet sich vor dem Deployment, nicht danach.

Warum gibt es in Salesforce keinen Rollback-Knopf?

Salesforce schreibt Metadaten direkt in die Org. Es gibt kein Transaktionsprotokoll zum Zurücknehmen und keine frühere Version der Org, auf die man umschalten könnte. Die Metadata API bietet genau ein Sicherheitsnetz, und das greift nur beim echten Fehlschlag: Bei einem Produktiv-Deployment muss rollbackOnError auf true stehen, sodass ein fehlerhafter Bestandteil das gesamte Paket verwirft und die Org unverändert bleibt (Salesforce Metadata API Developer Guide).

Für den Fall, den Teams wirklich fürchten, hilft dieses Netz nicht. Ein Release, das sauber deployt, alle Tests besteht und um neun Uhr morgens einen Geschäftsprozess bricht, ist aus Sicht von Salesforce kein fehlgeschlagenes Deployment. Es zurückzunehmen bedeutet, ein neues Deployment zu bauen, und bauen können Sie es nur aus etwas, das Sie vorher gesichert haben.

Was lässt sich wirklich zurücknehmen und was nicht?

Mit dieser Frage sollte jeder Rollback-Plan beginnen, und genau hier schweigen die meisten. Sortieren Sie Ihr Release in drei Gruppen, bevor Sie den ersten Schritt aufschreiben.

• Durch erneutes Deployen der alten Version umkehrbar. Apex-Klassen und Trigger, Lightning Web Components, Flows, Layouts, Validierungsregeln, Berechtigungssätze und der größte Teil der deklarativen Konfiguration. Wer die vorherige Quelle hat, spielt sie zurück.
• Innerhalb eines Zeitfensters wiederherstellbar. Ein gelöschtes benutzerdefiniertes Feld landet unter Deleted Fields im Objekt-Manager und lässt sich samt Daten 15 Tage lang wiederherstellen, danach ist es weg. Das Feld zurückzuholen bringt die Seitenlayouts nicht zurück (Hintergrund zur Wiederherstellung gelöschter Felder).
• Praktisch unumkehrbar. Gelöschte Auswahllistenwerte, Feldtyp-Konvertierungen, die Daten abschneiden, Datensätze, die ein fehlerhafter Flow oder Trigger überschrieben hat, sowie über die Metadata API gelöschte Roll-up-Summary-Felder, die den Papierkorb vollständig umgehen (Salesforce-Dokumentation zum Löschen von Komponenten).

An dieser dritten Gruppe scheitern Rollback-Pläne. Ein Metadaten-Rollback stellt Konfiguration wieder her, niemals Daten. Wenn Ihr Release eine Automatisierung über 400.000 Datensätze laufen ließ, ändert das Zurückspielen des gestrigen Apex daran nichts.

Welche Rollback-Strategien sind realistisch?

1. Umgekehrtes Deployment aus der Versionsverwaltung

Die verlässlichste Variante. Liegt der Branch, aus dem das Release entstand, in Git, ist der vorherige Commit Ihr Rollback-Artefakt. Sie bauen ein Paket aus dem letzten guten Commit und deployen es darüber. Das deckt nur geänderte oder hinzugefügte Komponenten ab, kombinieren Sie es also mit Strategie drei.

2. Wiederherstellung aus einem Metadaten-Snapshot

Sichern Sie den Zustand der Ziel-Org unmittelbar vor dem Deployment und erzeugen Sie daraus bei Bedarf das Rückwärtspaket. Das deckt den Fall ab, dass die Org von Git abgedriftet ist, was in den meisten Salesforce-Teams zutrifft. Werkzeuge dieser Kategorie automatisieren Sicherung und Diff: Gearset, AutoRABIT und Blue Canvas dokumentieren jeweils snapshot- oder restore-basiertes Rollback, und Serpent liefert Ein-Klick-Rollback in jedem Plan, auch im kostenlosen. Ab Scale deckt Backup & Restore die Daten ab.

3. Destructive changes für alles, was neu dazukam

Ein umgekehrtes Deployment aktualisiert Komponenten, die vorher existierten. Es entfernt nicht, was Ihr Release erzeugt hat, ein neues Objekt oder Feld bleibt also stehen, solange Sie es nicht ausdrücklich löschen. Dafür brauchen Sie ein destructiveChanges.xml-Manifest, ein eigenes Artefakt, das geschrieben werden will. Mit destructiveChangesPre.xml löschen Sie vor den Ergänzungen, mit destructiveChangesPost.xml danach, womit sich Abhängigkeiten lösen lassen, etwa eine Apex-Klasse, die noch auf das zu löschende Objekt verweist.

4. Nach vorn reparieren statt zurückrollen

Oft die richtige Wahl. Liegt der Fehler in einer Validierungsregel oder einer Zeile Apex, ist ein Hotfix über die normale Pipeline schneller und sicherer, als ein Paket mit 200 Komponenten umzukehren. Rollen Sie zurück, wenn die Auswirkung unklar ist. Reparieren Sie nach vorn, wenn sie klein und verstanden ist.

Wie nimmt man ein fehlgeschlagenes Salesforce-Deployment Schritt für Schritt zurück?

1. Pipeline anhalten, damit sich kein weiteres Release auf das kaputte legt.
2. Auswirkung benennen: welche Komponenten, welche Automatisierungen, welche Datensätze.
3. Rollback oder Fix nach vorn entscheiden und den Beteiligten sagen, was gilt.
4. Rückwärtspaket aus dem Snapshot oder dem letzten guten Commit bauen.
5. Destructive-Manifest für alles ergänzen, was das Release erzeugt hat.
6. Rückwärtspaket vor der Ausführung gegen die Produktion validieren, damit aus einem Vorfall nicht zwei werden.
7. Deployen und danach den Geschäftsprozess prüfen, nicht den Deployment-Status.
8. Daten getrennt aus dem Backup reparieren, erst wenn die Metadaten stabil sind.

Was sollten Sie vor dem Deployment entscheiden?

Ein Rollback ist eine Entwurfsentscheidung zur Bauzeit. Beantworten Sie diese fünf Punkte, bevor das Release rausgeht.

• Wo liegt der Snapshot der Ziel-Org von vor dem Release, und ist er tatsächlich gelaufen?
• Welche Komponenten dieses Releases fallen in die unumkehrbare Gruppe?
• Braucht etwas ein Destructive-Manifest, und ist es geschrieben und geprüft?
• Gibt es ein Daten-Backup nahe genug am Release, um brauchbar zu sein?
• Wer entscheidet den Rollback, und welches Signal löst ihn aus?

Vor dem Deployen zu validieren ist die billigste Vorsorge. Eine Validierung mit Tests bleibt 10 Tage nutzbar und erlaubt einen Quick Deploy desselben Pakets, ohne die Apex-Tests erneut laufen zu lassen, Compile-Fehler haben in der Produktion also nichts verloren. Weitere Release-Playbooks stehen in unserer SF-Guides-Bibliothek.

FAQ

Macht Salesforce ein fehlgeschlagenes Deployment automatisch rückgängig?

Ja, aber nur solche, die fehlschlagen. Produktiv-Deployments verlangen rollbackOnError auf true, eine fehlerhafte Komponente verwirft also das ganze Paket. Ein erfolgreiches Deployment wird nie für Sie zurückgenommen.

Lassen sich Change Sets zurücknehmen?

Nicht nativ. Es gibt keinen Umkehrknopf, also bauen Teams ein zweites Change Set, das die vorherige Version erneut deployt, was nur funktioniert, wenn jemand diese Version vorher gesichert hat.

Stellt ein Metadaten-Rollback meine Daten wieder her?

Nein. Metadaten und Daten sind getrennte Probleme. Konfiguration zurückzunehmen macht Datensätze nicht rückgängig, die eine Automatisierung angelegt, geändert oder gelöscht hat. Dafür brauchen Sie Backup und Wiederherstellungsplan.

Wie lange kann ich ein gelöschtes benutzerdefiniertes Feld retten?

15 Tage. Das Feld steht unter Deleted Fields im Objekt-Manager und lässt sich in diesem Fenster samt Daten wiederherstellen, muss aber gegebenenfalls von Hand wieder in die Seitenlayouts.