Eine Salesforce-Sandbox mit realistischen Daten befüllen

Kurze Antwort: Eine Salesforce-Sandbox gut zu befüllen sind drei Aufgaben, nicht eine. Ziehen Sie einen beziehungsbewussten Ausschnitt aus der Produktion statt einer Datensatzzahl, laden Sie ihn von den Eltern zu den Kindern mit stabilen External IDs, damit derselbe Satz erneut geladen werden kann, und anonymisieren Sie deterministisch, damit sich die Daten weiterhin wie echte Daten verhalten. Danach versionieren Sie die Seed-Definition neben Ihren Metadaten, denn was Seed-Sätze umbringt, ist nicht der erste Ladelauf, sondern die Schemaänderung drei Sprints später.

Was ist Sandbox Seeding?

Sandbox Seeding heißt, eine Teilmenge produktiver Datensätze in eine niedrigere Umgebung zu kopieren, damit die Org realistische Daten zum Entwickeln und Testen hat, wobei sensible Werte vor dem Laden maskiert werden. Das ist ein Datenproblem, kein Metadatenproblem: Ein Sandbox-Refresh bringt die Konfiguration und hinterlässt Ihnen in den meisten Fällen eine leere oder unbrauchbare Org.

Welche Sandboxes müssen wirklich befüllt werden?

Nur die, die keine Daten für Sie kopieren. Laut der Salesforce-Dokumentation zu Sandbox-Lizenzen und Speichergrenzen: Developer (200 MB) und Developer Pro (1 GB) kopieren nur Metadaten und lassen sich täglich aktualisieren, diese befüllen Sie. Partial Copy (5 GB, alle 5 Tage) bringt eine über eine Vorlage gewählte Stichprobe, die Lücken füllen Sie selbst. Full (so groß wie die Produktion, alle 29 Tage) bringt alles, und genau deshalb wiegt Maskierung dort schwerer. Scratch Orgs starten immer leer, dort ist Seeding Pflicht.

Wie wählt man einen beziehungsbewussten Ausschnitt?

Der übliche Fehler ist die Auswahl nach Menge: 500 Accounts, 500 Contacts, und die Hoffnung, dass sie zusammenhängen. Tun sie nicht, und die Tester bauen eine Woche lang genau die Datensätze, die ihnen versprochen wurden.

Wählen Sie stattdessen nach Graph, ausgehend von einer kleinen Menge Wurzeldatensätze:

1. Wählen Sie die Wurzeln bewusst. Zwanzig bis fünfzig Accounts, die zusammen Ihre Record Types, Währungen, Länder, Territories und Randfälle abdecken. Ein Großkunde, ein brandneuer, einer mit kaputter Adresse.
2. Gehen Sie zu den Kindern hinunter. Contacts, Opportunities, Positionen, Cases, Custom Objects und die Junction Objects dazwischen.
3. Gehen Sie über die Lookups wieder hinauf. Zeigt eine Opportunity auf ein Pricebook, eine Campaign oder einen eigenen Vertrag, kommen diese Eltern mit, sonst scheitert das Insert.
4. Behandeln Sie Referenzdaten getrennt. Produkte, Pricebook-Einträge und Konfigurationsdatensätze sind die Vollkopie einer kleinen Tabelle, kein Graphausschnitt.

Ein paar hundert gut verbundene Datensätze schlagen hunderttausend unverbundene, außer beim Lasttest.

In welcher Reihenfolge müssen die Datensätze geladen werden?

Strikte Abhängigkeitsreihenfolge, Eltern vor Kindern, und jedes Objekt auf etwas Stabilem verschlüsselt.

• Tragen Sie niemals Salesforce-IDs zwischen Orgs. Sie überleben nicht. Legen Sie auf jedem befüllten Objekt ein Textfeld als External ID an, füllen Sie es aus dem Quelldatensatz und machen Sie ein upsert darauf. Damit ist der Ladelauf idempotent: zweimal ausgeführt aktualisiert er, statt zu duplizieren.
• Zirkuläre Referenzen in zwei Durchläufen. Selbstbezüge wie Account.ParentId und Paare, die aufeinander zeigen, lassen sich nicht in einem Insert auflösen. Laden Sie die Datensätze mit leerem Lookup und setzen Sie das Lookup in einem zweiten Durchlauf.
• Bilden Sie die Eigentümer ab. Owner und jedes User-Lookup lösen nicht auf: Sandbox-Benutzernamen tragen ein Suffix und Ihre Produktionsnutzer fehlen dort möglicherweise. Bilden Sie sie vor dem Laden neu ab.
• Junctions zuletzt. Laden Sie ein Junction Object erst, wenn beide Master existieren.
• Automatisierung umgehen, nicht deaktivieren. Trigger, Flows, Validierungs- und Dublettenregeln feuern beim Seed-Lauf. Ein Bypass-Schalter, den Ihre Automatisierung abfragt, ist besser als Deaktivierungen in eine Org zu deployen.

Wie anonymisiert man, ohne die Daten wertlos zu machen?

Maskierung, die Rauschen erzeugt, ist so schlecht wie keine Maskierung, denn niemand vertraut einem Test, der an Unsinn gescheitert ist. Wählen Sie die Technik pro Feld:

• Deterministische Pseudonyme für alles, was in Joins, Abgleich oder Dublettenprüfung genutzt wird. Dieselbe Eingabe muss immer dieselbe Ausgabe liefern, damit ein Kunde über alle Objekte hinweg ein Kunde bleibt.
• Innerhalb der Spalte mischen, wo die Verteilung wichtiger ist als der Wert, etwa Umsatzbänder oder Abschlussdaten, über die Sie berichten.
• Vollständig löschen bei Feldern, die kein Test berührt. Freitextnotizen, Beschreibungsfelder und Anhänge sind die eigentlichen Verstecke personenbezogener Daten.
• Neutralisieren Sie alles Zustellbare. E-Mail-Adressen, Telefonnummern und von Integrationen genutzte externe Ids werden auf Werte umgeschrieben, die keine reale Person erreichen, und die E-Mail-Zustellbarkeitseinstellung der Sandbox wird vor dem ersten Laden geprüft.

Salesforce liefert Anonymize for Salesforce, und Gearset, Odaseva sowie Flosum verkaufen Seeding-Werkzeuge mit eingebauter Maskierung. Was Sie auch nutzen: Das Regelwerk muss einmal schriftlich von der für Datenschutz zuständigen Person freigegeben werden.

Was passiert, wenn sich das Schema ändert?

Das ist der Teil, den fast niemand behandelt, und der Grund, warum die meisten Seed-Sätze binnen eines Quartals tot sind. Eine Seed-Definition ist ein festgeschriebenes Abbild Ihres Schemas: Feldlisten, Picklist-Werte, Pflichtfelder, Validierungsregeln. Liefern Sie ein neues Pflichtfeld aus, und jeder folgende Ladelauf scheitert.

Behandeln Sie den Seed-Satz als Quellcode:

• Versionieren Sie die Seed-Definition im Repository, neben den Metadaten, von denen sie abhängt, damit Schemaänderung und Seed-Änderung im selben Pull Request landen.
• Leiten Sie Spalten aus einem Describe-Aufruf ab, statt eine manuelle Feldliste festzuschreiben, damit neue Felder nicht stillschweigend herausfallen.
• Führen Sie den Ladelauf in der CI aus, gegen eine Scratch Org, bei jedem Pull Request, der Objekte, Felder oder Validierungsregeln berührt. Ein fehlgeschlagener Seed-Lauf ist ein berechtigter Build-Fehler: Er zeigt, dass Sie gerade die Datenerzeugung kaputtgemacht haben.
• Nach jedem Refresh neu ableiten. Picklist-Werte werden umbenannt und Record Types abgeschafft; ein im März korrekter Seed-Satz ist im Juni eine Schlange von Validierungsfehlern.

In Serpent ist eine Datenoperation eine vollwertige Pipeline-Aktion statt Handarbeit, wodurch der Seed-Lauf in derselben Pipeline liegt wie das Deployment, das er stützt.

Binden Sie den Takt schließlich an Ihre Releases: jede Iteration für Entwicklungssandboxes, jeder Testzyklus für UAT, immer nach einem Refresh. Weil der Ladelauf idempotent und versioniert ist, ist das ein Pipelinelauf und kein Projekt. Weitere Salesforce-DevOps-Leitfäden.

FAQ

Wie viele Daten braucht eine befüllte Sandbox?

So viele, dass jeder Record Type, Pfad und Randfall abgedeckt ist, meist ein paar hundert verbundene Datensätze. Menge zählt nur beim Lasttest.

Reicht nicht einfach der Data Loader?

Für einen kleinen Satz ja. Ladereihenfolge, ID-Neuzuordnung und Maskierung verantworten Sie dann selbst, und Sie wiederholen alle drei nach jedem Refresh von Hand.

Bleiben meine befüllten Daten nach einem Refresh erhalten?

Nein. Ein Refresh ersetzt die Sandbox, alles Befüllte ist weg. Planen Sie den Seed-Lauf als festen Schritt nach dem Refresh ein.