Eine Salesforce-Sandbox mit realistischen Daten befuellen

Kurze Antwort: Eine Salesforce-Sandbox gut zu befuellen 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-Saetze umbringt, ist nicht der erste Ladelauf, sondern die Schemaaenderung drei Sprints spaeter.

Was ist Sandbox Seeding?

Sandbox Seeding heisst, eine Teilmenge produktiver Datensaetze 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 hinterlaesst Ihnen in den meisten Faellen eine leere oder unbrauchbare Org.

Welche Sandboxes muessen wirklich befuellt werden?

Nur die, die keine Daten fuer 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 taeglich aktualisieren, diese befuellen Sie. Partial Copy (5 GB, alle 5 Tage) bringt eine ueber eine Vorlage gewaehlte Stichprobe, die Luecken fuellen Sie selbst. Full (so gross 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 waehlt man einen beziehungsbewussten Ausschnitt?

Der uebliche Fehler ist die Auswahl nach Menge: 500 Accounts, 500 Contacts, und die Hoffnung, dass sie zusammenhaengen. Tun sie nicht, und die Tester bauen eine Woche lang genau die Datensaetze, die ihnen versprochen wurden.

Waehlen Sie stattdessen nach Graph, ausgehend von einer kleinen Menge Wurzeldatensaetze:

1. Waehlen Sie die Wurzeln bewusst. Zwanzig bis fuenfzig Accounts, die zusammen Ihre Record Types, Waehrungen, Laender, Territories und Randfaelle abdecken. Ein Grosskunde, 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 ueber 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-Eintraege und Konfigurationsdatensaetze sind die Vollkopie einer kleinen Tabelle, kein Graphausschnitt.

Ein paar hundert gut verbundene Datensaetze schlagen hunderttausend unverbundene, ausser beim Lasttest.

In welcher Reihenfolge muessen die Datensaetze geladen werden?

Strikte Abhaengigkeitsreihenfolge, Eltern vor Kindern, und jedes Objekt auf etwas Stabilem verschluesselt.

• Tragen Sie niemals Salesforce-IDs zwischen Orgs. Sie ueberleben nicht. Legen Sie auf jedem befuellten Objekt ein Textfeld als External ID an, fuellen Sie es aus dem Quelldatensatz und machen Sie ein upsert darauf. Damit ist der Ladelauf idempotent: zweimal ausgefuehrt aktualisiert er, statt zu duplizieren.
• Zirkulaere Referenzen in zwei Durchlaeufen. Selbstbezuege wie Account.ParentId und Paare, die aufeinander zeigen, lassen sich nicht in einem Insert aufloesen. Laden Sie die Datensaetze mit leerem Lookup und setzen Sie das Lookup in einem zweiten Durchlauf.
• Bilden Sie die Eigentuemer ab. Owner und jedes User-Lookup loesen nicht auf: Sandbox-Benutzernamen tragen ein Suffix und Ihre Produktionsnutzer fehlen dort moeglicherweise. 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. Waehlen Sie die Technik pro Feld:

• Deterministische Pseudonyme fuer alles, was in Joins, Abgleich oder Dublettenpruefung genutzt wird. Dieselbe Eingabe muss immer dieselbe Ausgabe liefern, damit ein Kunde ueber alle Objekte hinweg ein Kunde bleibt.
• Innerhalb der Spalte mischen, wo die Verteilung wichtiger ist als der Wert, etwa Umsatzbaender oder Abschlussdaten, ueber die Sie berichten.
• Vollstaendig loeschen bei Feldern, die kein Test beruehrt. Freitextnotizen, Beschreibungsfelder und Anhaenge 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 geprueft.

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 fuer Datenschutz zustaendigen Person freigegeben werden.

Was passiert, wenn sich das Schema aendert?

Das ist der Teil, den fast niemand behandelt, und der Grund, warum die meisten Seed-Saetze 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 abhaengt, damit Schemaaenderung und Seed-Aenderung im selben Pull Request landen.
• Leiten Sie Spalten aus einem Describe-Aufruf ab, statt eine manuelle Feldliste festzuschreiben, damit neue Felder nicht stillschweigend herausfallen.
• Fuehren Sie den Ladelauf in der CI aus, gegen eine Scratch Org, bei jedem Pull Request, der Objekte, Felder oder Validierungsregeln beruehrt. 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 Maerz 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 stuetzt.

Binden Sie den Takt schliesslich an Ihre Releases: jede Iteration fuer Entwicklungssandboxes, jeder Testzyklus fuer UAT, immer nach einem Refresh. Weil der Ladelauf idempotent und versioniert ist, ist das ein Pipelinelauf und kein Projekt. Weitere Salesforce-DevOps-Leitfaeden.

FAQ

Wie viele Daten braucht eine befuellte Sandbox?

So viele, dass jeder Record Type, Pfad und Randfall abgedeckt ist, meist ein paar hundert verbundene Datensaetze. Menge zaehlt nur beim Lasttest.

Reicht nicht einfach der Data Loader?

Fuer 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 befuellten Daten nach einem Refresh erhalten?

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