So schreiben Sie ein Sandbox-Refresh-Runbook, dem Ihr Team folgt

Ein Sandbox-Refresh-Runbook, dem Ihr Team folgt, ist kurz, liegt neben Ihrem Code und gibt jedem Schritt einen Verantwortlichen, eine Zeitschätzung und eine Prüfung, die belegt, dass er erledigt ist. Die meisten Refresh-Dokumente scheitern, weil sie lange Wiki-Seiten sind, für die niemand zuständig ist. Schreiben Sie Ihres als Checkliste in vier Phasen, automatisieren Sie die Schritte, die gern übersprungen werden, und proben Sie es einmal, bevor Sie sich darauf verlassen.

Was ist ein Sandbox-Refresh-Runbook?

Ein Sandbox-Refresh-Runbook ist die Schritt-für-Schritt-Anleitung, die Ihr Team jedes Mal ausführt, wenn eine Salesforce-Sandbox aus der Produktion aktualisiert wird: was vorher gesichert wird, was danach wiederhergestellt wird, wer welchen Schritt übernimmt und woran Sie erkennen, dass es funktioniert hat. Es ist nicht Ihre Sandbox-Strategie, die festlegt, welche Sandboxes es gibt und warum. Das Runbook ist der Teil, den man am Morgen des Refreshs abarbeitet.

Warum ignorieren Teams Refresh-Runbooks?

• Kein Verantwortlicher pro Schritt. Wenn das Team die Integrationen wiederherstellt, tut es niemand.
• Keine Definition von erledigt. Integrationen neu konfigurieren lässt sich nicht prüfen. Ein Test-Callout über den Named Credential liefert 200 schon.
• Es liegt am falschen Ort. Eine Wiki-Seite entfernt sich von der Org. Eine Markdown-Datei im Repo wird geprüft, wenn sich die Org ändert.
• Zu viele manuelle Schritte. Jeder manuelle Schritt ist einer, den jemand unter Zeitdruck auslässt.

Wie oft können Sie welchen Sandbox-Typ aktualisieren?

Salesforce begrenzt Ihren Rhythmus, also stellen Sie die Grenzen an den Anfang des Runbooks. Laut dem Sandbox-Leitfaden von Salesforce Ben:

• Developer und Developer Pro: einmal pro Tag, nur Metadaten.
• Partial Copy: alle fünf Tage, Metadaten plus ein Teil Ihrer Daten.
• Full: alle 29 Tage, alle Produktionsmetadaten und -daten.

Ein verpatzter Full-Refresh kann Sie einen Monat kosten, deshalb verdient dieses Runbook die größte Sorgfalt.

Was gehört in jede Phase des Runbooks?

Schreiben Sie jeden Schritt im gleichen Format: Schritt | Verantwortlich | automatisiert? | Minuten | erledigt wenn. Gruppieren Sie die Schritte dann in vier Phasen.

1. Vor dem Refresh

• Kündigen Sie das Zeitfenster bei Entwicklern, QA und Fachtestern an und holen Sie eine Bestätigung ein.
• Committen oder deployen Sie jede laufende Änderung in die Versionskontrolle. Ein Refresh überschreibt die Sandbox, und alles, was nicht in Git ist, ist weg.
• Exportieren Sie Konfiguration, die als Daten gespeichert ist, etwa Einstellungsdatensätze, die manche AppExchange-Pakete außerhalb der Metadaten halten.
• Listen Sie die Integrations-Endpoints, Named Credentials und Connected Apps auf, die Sie umstellen müssen.

2. Während des Refreshs

• Prüfen Sie, dass die Produktion stabil ist und nicht mitten in einem Release steckt.
• Geben Sie beim Start des Refreshs Ihre Post-Copy-Apex-Klasse an, damit die Automatisierung läuft, ohne dass jemand daran denken muss.
• Notieren Sie Startzeit und wer den Refresh ausgelöst hat.

3. Nach dem Refresh

• Lassen Sie die E-Mail-Zustellbarkeit auf System email only, laut Apex Hours die Standardeinstellung für neue und aktualisierte Sandboxes, bis die Daten maskiert sind.
• Entfernen Sie das Suffix .invalid nur für Nutzer, die in der Sandbox E-Mails brauchen. Salesforce hängt es bei jedem Refresh oder Klon an die E-Mail-Adressen der Nutzer an, wie der Hilfeartikel erklärt.
• Maskieren oder löschen Sie personenbezogene Daten, bevor Sie den Zugriff erweitern.
• Stellen Sie Integrationen auf ihre Sandbox-Endpoints um und authentifizieren Sie sie neu.
• Deployen Sie Arbeit, die der Produktion voraus ist, erneut aus der Versionskontrolle und laden Sie danach Testdaten.

4. Validieren und übergeben

• Machen Sie einen Smoke-Test: als Tester anmelden, einen zentralen Flow durchlaufen, einen Test-Callout ausführen.
• Lassen Sie Ihre Apex-Tests laufen, mindestens die Teilmenge, die Ihre Integrationen abdeckt.
• Melden Sie, dass die Sandbox bereit ist, mit bekannten Problemen, und korrigieren Sie im Runbook selbst, was schiefging.

Welche Refresh-Schritte sollten Sie zuerst automatisieren?

Automatisieren Sie die Schritte, die häufig, fehleranfällig und mühsam sind. Mit dem Salesforce-Interface SandboxPostCopy schreiben Sie eine Apex-Klasse, die beim Anlegen der Sandbox automatisch läuft, und die Refresh-Best-Practices von Salto nennen das Maskieren von E-Mail-Adressen und das Aktualisieren von Custom Settings und Custom Metadata als typische Einsätze. Gute erste Kandidaten:

1. Personenbezogene Daten bei Kontakten und Leads maskieren.
2. Custom Settings und Endpoint-Konfiguration auf Sandbox-Werte zurücksetzen.
3. E-Mail für die kleine Gruppe von Nutzern wiederherstellen, die sie braucht.
4. Basis-Testdaten neu laden. Unser Leitfaden, wie Sie eine Salesforce-Sandbox mit realistischen Daten befüllen, beschreibt die Optionen.

Machen Sie die Klasse idempotent und protokollieren Sie, was sie geändert hat, damit ein fehlgeschlagener Lauf sicher wiederholt werden kann.

Wie passt das Runbook in Ihre Release-Pipeline?

Ein Refresh setzt eine Sandbox auf den Stand der Produktion zurück, also verschwindet alles zwischen dieser Sandbox und der Produktion, sofern Ihre Pipeline es nicht zurückbringt. Zwei Gewohnheiten verhindern diesen Verlust. Erstens: Machen Sie Git zur Quelle der Wahrheit, damit laufende Arbeit neu deployt und nicht neu gebaut wird. Zweitens: Richten Sie Back-Promotion in Ihrer Salesforce-DevOps-Pipeline ein, damit Hotfixes aus der Produktion zwischen den Refreshs in die unteren Umgebungen fließen. Führen Sie nach dem Refresh dieselben Prüfungen aus wie bei jedem Pull Request. Unser Leitfaden zur Salesforce-Testautomatisierung in CI trennt, was bei jedem Pull Request und was nachts laufen sollte.

Wenn das erneute Deployen nach jedem Refresh noch ein manueller Nachmittag ist, nimmt Ihnen eine DevOps-Plattform das meiste davon ab. Der kostenlose Essentials-Plan von Serpent enthält Delta-Deployments und Rollback mit einem Klick; vergleichen Sie die Pläne auf der Preisseite von Serpent.

Wie bringen Sie das Team dazu, es wirklich zu befolgen?

• Halten Sie jede Phase auf einem Bildschirm und verlinken Sie Details.
• Legen Sie das Runbook ins Repo und prüfen Sie Änderungen daran wie Code.
• Proben Sie es auf einer Developer-Sandbox, die täglich aktualisiert werden kann, vor dem nächsten Full-Refresh.
• Aktualisieren Sie es am selben Tag, an dem etwas schiefgeht. Ein Runbook, das einmal falsch war, wird für immer ignoriert.
• Benennen Sie für jeden Schritt einen Stellvertreter.

Weitere praktische Leitfäden wie diesen finden Sie in der SF-Guides-Bibliothek.

FAQ

Wie lang sollte ein Sandbox-Refresh-Runbook sein?

Kurz genug für einen Bildschirm pro Phase. Halten Sie das Runbook als Checkliste und lagern Sie Details in verlinkte Dokumente aus.

Wofür wird SandboxPostCopy verwendet?

Es ist ein Apex-Interface für eine Klasse, die beim Anlegen einer Sandbox automatisch läuft, meist um Daten zu maskieren und Einstellungen zurückzusetzen.

Warum enden Nutzer-E-Mails nach einem Refresh auf .invalid?

Salesforce hängt .invalid an, damit Produktionsnutzer keine E-Mails aus der Sandbox erhalten. Entfernen Sie es nur für Nutzer, die Sandbox-E-Mails brauchen.

Wie oft können Sie eine Full-Sandbox aktualisieren?

Einmal alle 29 Tage. Partial-Copy-Sandboxes lassen sich alle fünf Tage aktualisieren, Developer-Sandboxes täglich.