Die Sandbox

Eine Sandbox ist ein zweiter Tenant: eigener Slug, eigene Daten, eigene API-Schlüssel, eigene Storefront. Sie existiert, damit die Antwort auf „darf ich das ausprobieren?" Ja lautet.

Was sie ist

Stellen Sie sie sich als vollständige Kopie der Plattform vor, die zufällig Daten enthält, über die sich niemand ärgern wird.

Die wichtige Zeile ist die vorletzte. Eine Testbestellung in Produktion, die eine echte Bestellbestätigung an einen echten Käufer auslöst, ist kein Test; sie ist ein Vorfall mit angehängtem Support-Ticket.

Was sie nicht ist

Drei Missverständnisse, jedes teuer:

Sie ist keine Staging-Umgebung für die Plattform selbst. Die Releases der Plattform stagen Sie nicht. Was Sie testen, sind Ihre Konfiguration und Ihre Integrationen.

Sie ist kein Performance-Prüfstand. Rate-Limits gelten dort wie in Produktion, und die Sandbox hält einen Bruchteil Ihres Datenvolumens. Ein Import, der auf 3.000 Sandbox-Produkten vier Minuten braucht, sagt Ihnen nichts über 400.000 Produktionsprodukte. Siehe Rate-Limits, Kontingente und Fair Use.

Sie ist nicht dauerhaft. Sandbox-Daten driften binnen Wochen von der Produktion weg — neue Attribute, neue Preislisten, neue Kunden auf der einen Seite und nicht auf der anderen. Planen Sie, sie aufzufrischen, statt sie zu pflegen.

Was Produktion nie verlassen darf

Diesen Absatz lesen Sie zweimal, denn ein Fehler hier ist ein DSGVO-Problem, kein Engineering-Problem.

Eine Sandbox ist absichtlich ein Ort, an dem die Zugangskontrollen locker sind und die Zugangsdaten mit Leuten außerhalb Ihres Unternehmens geteilt werden. Echte personenbezogene Daten haben darin nichts verloren.

Die praktikable Variante für die meisten Unternehmen: die Struktur kopieren, die Menschen erfinden. Nehmen Sie den echten Katalog, den echten Preislistenaufbau und die echten Freigaberegeln, und befüllen Sie sie mit einem Dutzend erfundener Organisationen — Testkunde Nord GmbH mit Kontakten unter @example.com —, die sich wie Ihre echten Kunden verhalten, ohne einer davon zu sein.

Seed-Daten: was eine brauchbare Sandbox enthält

Eine leere Sandbox ist nicht testbar. Eine Vollkopie der Produktion ist nicht zulässig. Die brauchbare Mitte ist ein bewusster Seed:

• Ein Ausschnitt des Katalogs, ein paar tausend Artikel, so gewählt, dass die sperrigen Fälle dabei sind: eine Variantenfamilie, ein Artikel mit Maß-Attribut, einer mit langer Beschreibung, einer in Verpackungseinheit 12, einer, der ausläuft.
• Die echte Preislistenstruktur — eine Standardliste, eine Kundenliste, ein Staffelpreis, ein zeitlich befristeter Preis — mit erfundenen Beträgen.
• Zehn bis zwanzig erfundene Organisationen, die die relevante Bandbreite abdecken: eine mit Freigabeschwelle, eine gesperrte, eine auf einem Punchout-Kanal, eine auf Rechnung, eine in einer zweiten Währung.
• Eine Handvoll Bestellungen in jedem Status, damit ein Integrator das Lesen von pending, placed, in_fulfillment, completed und cancelled testen kann, ohne auf eine echte zu warten.
• Bestandswerte, die Null- und Negativverfügbarkeit enthalten, denn an denen brechen Integrationen.

Diesen Seed bauen Sie einmal, sorgfältig, und behalten ihn als Definition eines Sandbox-Refreshs.

Zurücksetzen

Ein Reset wischt die Sandbox auf ihren Seed zurück. Er ist bewusst, und er macht die Sandbox erst gefahrlos kaputtbar: Die Erholung von einem katastrophalen Test ist keine Reparatur, sondern ein Reset.

Zwei Gewohnheiten machen Resets schmerzfrei:

• Bewahren Sie nichts in der Sandbox auf, das nur dort existiert. Konfiguration, die es wert ist, wird aufgeschrieben oder exportiert. Ein Reset sollte nichts zerstören, das jemandem fehlt.
• Vereinbaren Sie den Reset-Rhythmus vorab mit Ihrem Integrator — typischerweise vor jeder großen Testrunde. Ein Reset mitten in jemandes Testwoche ist schlimmer als gar keiner.

Konfiguration nach Produktion befördern

Der Sinn des Testens in der Sandbox ist, dass das Getestete live geht. Das passiert nicht von allein.

Was sauber wandert, und wie:

Beachten Sie, was nicht auf der Liste steht: Es gibt keinen Knopf, der eine Sandbox über die Produktion kopiert. Behandeln Sie die Beförderung als dokumentiertes, wiederholbares Verfahren, und schreiben Sie es beim ersten Mal mit — dieses Dokument ist zugleich Ihr Disaster-Recovery-Runbook.

Wenn Sie keinen Sandbox-Tenant haben

Zwei kleinere Sicherheitsnetze existieren innerhalb eines einzelnen Tenants und sind es wert, gekannt zu werden, denn sie decken viel Alltagsrisiko ab:

• Staging beim Import. Import & Export kann eine Datei in einen Vorschaubereich laden statt in Ihre Live-Daten, sodass Sie ansehen können, was passiert wäre, bevor es passiert. Nutzen Sie das beim ersten Lauf jeder neuen Datei — siehe Massenexporte.
• Ein Testkanal. Ein Kanal, den keiner Ihrer Kunden erreicht, lässt Sie storefront-sichtbare Konfiguration ohne zweiten Tenant prüfen.

Keines der beiden ersetzt eine Sandbox für Integrationsarbeit, denn keines gibt einem externen Integrator einen Ort, an dem ein Fehler nichts kostet.

Weiter

• Eine Sandbox einrichten — bereitstellen, befüllen, übergeben.
• Eine Integration durchgängig testen — was Sie darin vor dem Go-live tatsächlich durchspielen.