Seed-Daten und Fixtures für lokale Datenbanken: klein, idempotent und mit dem Schema versioniert

Ziel

Jede Entwicklerin und jeder Entwickler, jeder Agent und jeder CI-Job kann mit einem einzigen Befehl in Sekunden eine lokale Datenbank mit genug realistischen, konsistenten Daten erzeugen, um die Anwendung und ihre Tests auszuführen, ohne eine Kopie der Produktion.

Voraussetzungen

Schema-Migrationen unter Versionskontrolle und eine lokale Datenbank, die sich frei löschen und neu erzeugen lässt (ein Container genügt; siehe den verwandten Artikel zu ephemeren Datenbanken). Eine Einteilung der Tabellen in Referenzdaten (Länder, Rollen, Pläne), Beispieldaten (einige Nutzer, Bestellungen, Dokumente) und umfangreiche Historie, die für lokale Arbeit nicht gebraucht wird.

Schritte

1. Die drei Arten trennen. Referenzdaten gehören zu den Migrationen oder zu einem Seed-Schritt, der in jeder Umgebung läuft, auch in der Produktion. Beispieldaten sind für Entwicklung und Demos gedacht. Testspezifische Zeilen werden innerhalb der Tests von Buildern oder Fixtures erzeugt, nie vom globalen Seed.
2. Den Seed als idempotenten Code schreiben. Der Rails-Guide sagt zu db/seeds.rb, der Code solle idempotent sein, damit er jederzeit in jeder Umgebung ausgeführt werden kann; Upserts anhand natürlicher Kennungen (email, slug) verwenden, keine blossen Inserts.
3. Den Beispieldatensatz klein und benannt halten: eine Handvoll Nutzer mit bekannten Zugangsdaten und jeweils ein Datensatz in jedem interessanten Zustand (eine bezahlte Bestellung, eine rückerstattete, ein gesperrtes Konto). Die Namen im README auflisten, damit «einloggen als alice@example.test» ein bekannter Ausgangspunkt ist.
4. Das vom Stack unterstützte Format verwenden: Djangos loaddata liest Fixture-Dateien, die dumpdata erzeugt; andere Stacks nutzen SQL-Dateien, CSV mit COPY oder ein Skript in der Anwendungssprache. Die Anwendungssprache bevorzugen, wenn Zeilen Validierungen und Hooks durchlaufen müssen.
5. Wird realistisches Volumen benötigt, die Produktion mit pg_dump --exclude-table-data für sensible oder riesige Tabellen dumpen, den Rest in einem eigenen Schritt anonymisieren und das Ergebnis ausserhalb des Repositorys mit einem Ablaufdatum speichern. Entwicklermaschinen nie mit rohen Produktionsdaten seeden.
6. Den Seed sowohl in das Setup-Skript als auch in den CI-Datenbankschritt einbinden, in beiden nach den Migrationen; ein durch eine neue Spalte kaputter Seed fällt so noch am selben Tag auf.
7. Den Seed bei jeder Schemaänderung zum Bestandteil des Reviews machen: Eine Migration, die eine Pflichtspalte hinzufügt, aktualisiert auch den Seed.

Erwartetes Ergebnis

Ein einziger Task löscht, migriert und seedet; zwei Maschinen, die vom selben Commit geseedet wurden, halten identische Beispieldaten, und Tests hängen nicht von Zeilen ab, die sie nicht selbst erzeugt haben.

Grenzen und Prüfbasis

Seeds ersetzen die leere Datenbank, nicht Testdaten-Builder. Generierte Kennungen unterscheiden sich zwischen Läufen, sofern der Seed sie nicht explizit setzt. Anonymisierung ist eine eigene Disziplin und wird hier nicht behandelt. Die Schritte sind eine Synthese der zitierten Dokumentation; es werden keine Zeitangaben behauptet.