Eine befüllte Sandbox schlägt eine Kopie der Produktion

Im Leben jedes kleinen Teams kommt der Moment, in dem jemand vorschlägt, die lokale Entwicklung auf eine Kopie der Produktionsdatenbank zu richten, weil die erfundenen Daten dünn wirken und die echten Fehler nur mit echten Datensätzen auftreten. Eine verlockende Idee mit einem langen Rattenschwanz an Reue: Zugangsdaten auf lauter Laptops, Kundennamen in Screenshots, ein Test-Job für E-Mails, der eines Tages echte Adressen findet. Wir sind den anderen Weg gegangen und haben es nie bereut.

Ein ganzes Postgres im Prozess

Eingebettete Postgres-Builds sind inzwischen richtig gut. Unsere Anwendung entscheidet beim Start: Gibt es echte Datenbankzugänge in der Umgebung, nimmt sie die gehostete Datenbank; sind sie leer, startet sie ein Postgres im eigenen Prozess, das in einem lokalen Ordner lebt. Entwicklungsrechner haben diese Zugänge schlicht nie, der schlimmste Fall eines falsch konfigurierten Laptops ist also eine frische leere Datenbank und kein Vorfall in der Produktion.

1// Choose the database at runtime. Blank env = embedded, local, harmless.2function makeDb() {3  const url = process.env.DATABASE_URL;4  if (url) return connectHosted(url);5  // In-process Postgres persisted to a local folder6  const client = new EmbeddedPostgres('./.pgdata');7  return drizzle(client, { schema });8}

Der Weg zum Neuaufbau zählt genauso viel wie die Engine. Wir bauen die lokale Datenbank neu, indem wir dieselben Migrationsdateien anwenden, die auch die Produktion durchlaufen hat, in der Reihenfolge, von der ersten an. Diese eine Entscheidung hat eine ganze Familie von Fehlern gratis gefangen: eine Migration, die eine Spalte aus einer späteren Datei voraussetzte, eine Schemaänderung, die gegen einen alten Abzug funktionierte, aber nicht von null. Wenn der Laptop das Schema nicht aus seiner Geschichte bauen kann, hätte es der nächste Deploy auch nicht gekonnt.

Füll einen Betrieb, keine Zeilen

Der Unterschied zwischen nutzlosen und nützlichen erfundenen Daten ist die Erzählung. Unser Skript legt nicht zehn Nutzer namens test an. Es legt einen Salon mit Namen an, Mitarbeitende mit Spezialgebieten, Leistungen mit ehrlichen Preisen und Dauern, Kunden mit Besuchshistorie, anstehende Termine, Verkaufsprodukte mit Beständen und einem Buch dahinter. Die Seiten sehen bewohnt aus, und das heißt, dass Layoutfehler, leere Zustände und unschön abgeschnittener Text so auftauchen, wie sie es bei einem echten Kunden täten.

Diese letzte Eigenschaft wird leicht unterschätzt. Jeder Screenshot in unserer Dokumentation, unserem Blog und unseren Fehlerberichten kommt aus der befüllten Sandbox. Niemand muss ein Bild anstarren und sich fragen, ob ein Kundenname durchgerutscht ist, weil es keine Kundennamen gibt, die durchrutschen könnten. Das sicherste Schwärzen ist, nichts zum Schwärzen zu haben.

Worauf es ankommt

• Mach den sicheren Weg zum Standardweg. Entwickler sollten sich anstrengen müssen, um an echte Daten zu kommen, nicht um sie zu vermeiden.
• Entschärf auch die Nebenwirkungen: E-Mail, Zahlungen und Speicherschlüssel bleiben lokal leer, eine Schleife über erfundene Kunden kann also nie einen echten Menschen anschreiben.
• Füll die Zustände, vor denen du dich fürchtest: das brandneue Konto, den ausgebuchten Tag, das ausverkaufte Produkt, den Kunden mit einem einzigen Besuch vor Jahren.
• Lass die Befüllung im Code-Review. Wenn eine Funktion eine Tabelle hinzufügt, wächst die Befüllung mit, sonst fault die Sandbox still vor sich hin.

Der Nutzen summiert sich. Neue Kolleginnen und Kollegen führen zwei Befehle aus und haben einen funktionierenden Betrieb zum Herumstochern. Die visuelle Prüfung kann jede Seite fotografieren, ohne dass jemand den Datenschutz gegenlesen muss. Und die Demo-Umgebung ist immer fünf Minuten von makellos entfernt, weil makellos nur ein Neuaufbau ist.

Produktionsdaten beantworten Fragen. Befüllte Daten lassen dich die Fragen gefahrlos stellen.