Rollback-Strategien fur fehlgeschlagene Salesforce-Deployments

Kurze Antwort: Salesforce hat keinen Ruckgangig-Knopf. Ein fehlgeschlagenes Produktiv-Deployment macht sich selbst ruckgangig, weil rollbackOnError in der Produktion auf true stehen muss. Ein Deployment, das durchlauft und sich als falsch herausstellt, mussen Sie dagegen selbst zurucknehmen. 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 Zurucknehmen und keine fruhere Version der Org, auf die man umschalten konnte. 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 unverandert bleibt (Salesforce Metadata API Developer Guide).

Fur den Fall, den Teams wirklich furchten, hilft dieses Netz nicht. Ein Release, das sauber deployt, alle Tests besteht und um neun Uhr morgens einen Geschaftsprozess bricht, ist aus Sicht von Salesforce kein fehlgeschlagenes Deployment. Es zuruckzunehmen bedeutet, ein neues Deployment zu bauen, und bauen konnen Sie es nur aus etwas, das Sie vorher gesichert haben.

Was lasst sich wirklich zurucknehmen 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, Berechtigungssatze und der grosste Teil der deklarativen Konfiguration. Wer die vorherige Quelle hat, spielt sie zuruck.
• Innerhalb eines Zeitfensters wiederherstellbar. Ein geloschtes benutzerdefiniertes Feld landet unter Deleted Fields im Objekt-Manager und lasst sich samt Daten 15 Tage lang wiederherstellen, danach ist es weg. Das Feld zuruckzuholen bringt die Seitenlayouts nicht zuruck (Hintergrund zur Wiederherstellung geloschter Felder).
• Praktisch unumkehrbar. Geloschte Auswahllistenwerte, Feldtyp-Konvertierungen, die Daten abschneiden, Datensatze, die ein fehlerhafter Flow oder Trigger uberschrieben hat, sowie uber die Metadata API geloschte Roll-up-Summary-Felder, die den Papierkorb vollstandig umgehen (Salesforce-Dokumentation zum Loschen von Komponenten).

An dieser dritten Gruppe scheitern Rollback-Plane. Ein Metadaten-Rollback stellt Konfiguration wieder her, niemals Daten. Wenn Ihr Release eine Automatisierung uber 400.000 Datensatze laufen liess, andert das Zuruckspielen des gestrigen Apex daran nichts.

Welche Rollback-Strategien sind realistisch?

1. Umgekehrtes Deployment aus der Versionsverwaltung

Die verlasslichste 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 daruber. Das deckt nur geanderte oder hinzugefugte 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 Ruckwartspaket. 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.

3. Destructive changes fur 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 ausdrucklich loschen. Dafur brauchen Sie ein destructiveChanges.xml-Manifest, ein eigenes Artefakt, das geschrieben werden will. Mit destructiveChangesPre.xml loschen Sie vor den Erganzungen, mit destructiveChangesPost.xml danach, womit sich Abhangigkeiten losen lassen, etwa eine Apex-Klasse, die noch auf das zu loschende Objekt verweist.

4. Nach vorn reparieren statt zuruckrollen

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

Wie nimmt man ein fehlgeschlagenes Salesforce-Deployment Schritt fur Schritt zuruck?

1. Pipeline anhalten, damit sich kein weiteres Release auf das kaputte legt.
2. Auswirkung benennen: welche Komponenten, welche Automatisierungen, welche Datensatze.
3. Rollback oder Fix nach vorn entscheiden und den Beteiligten sagen, was gilt.
4. Ruckwartspaket aus dem Snapshot oder dem letzten guten Commit bauen.
5. Destructive-Manifest fur alles erganzen, was das Release erzeugt hat.
6. Ruckwartspaket vor der Ausfuhrung gegen die Produktion validieren, damit aus einem Vorfall nicht zwei werden.
7. Deployen und danach den Geschaftsprozess prufen, 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 funf Punkte, bevor das Release rausgeht.

• Wo liegt der Snapshot der Ziel-Org von vor dem Release, und ist er tatsachlich gelaufen?
• Welche Komponenten dieses Releases fallen in die unumkehrbare Gruppe?
• Braucht etwas ein Destructive-Manifest, und ist es geschrieben und gepruft?
• Gibt es ein Daten-Backup nahe genug am Release, um brauchbar zu sein?
• Wer entscheidet den Rollback, und welches Signal lost 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 ruckgangig?

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 fur Sie zuruckgenommen.

Lassen sich Change Sets zurucknehmen?

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 zuruckzunehmen macht Datensatze nicht ruckgangig, die eine Automatisierung angelegt, geandert oder geloscht hat. Dafur brauchen Sie Backup und Wiederherstellungsplan.

Wie lange kann ich ein geloschtes benutzerdefiniertes Feld retten?

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