Team Onboarding mit Seed Daten: neue Entwickler am ersten Tag produktiv

Team Onboarding entscheidet, wie schnell ein neuer Entwickler echten Wert liefert. In vielen Teams hängt es an einer einzigen Frage: Woher kommen die Daten für die lokale Umgebung? Solange die Antwort „frag mal Ops nach einem Dump“ lautet, verliert ihr Tage. Wir zeigen, wie ein einziger Befehl eine laufende Anwendung mit realistischen Seed Daten aufsetzt. Ganz ohne einen Datensatz aus Production.

Teil 1 der Serie zu Seed Daten im Team. Teil 2: Seed Daten als Teamstandard. Teil 3: Staging ohne Produktionsdaten.

Montag, 9 Uhr: Laptop da, Daten fehlen

Der neue Kollege hat Zugriff aufs Repository. Composer und npm laufen durch. Dann startet die App und zeigt leere Tabellen. Ab hier beginnt die Suche. Jemand hat noch einen Dump vom letzten Quartal. Der ist zu groß für den Chat. Und eigentlich darf ihn der Neue gar nicht haben, weil echte Kundendaten drin stecken.

Am Mittwoch läuft etwas. Mit alten Daten, einem halb passenden Schema und drei Workarounds, die nirgends stehen. Die Zeitfresser sind fast immer dieselben:

• Freigabe für den Dump: Datenschutz und Ops müssen erst zustimmen.
• Veraltete Daten: Der Dump passt nicht mehr zu den aktuellen Migrations.
• Wissen in einzelnen Köpfen: Welcher Testaccount funktioniert, weiß nur eine Person.
• Externe bleiben draußen: Freelancer und Agenturen dürfen keine Produktionsdaten sehen und warten.

Das Ziel: git clone und ein Befehl

Ein gutes Onboarding Setup passt in drei Zeilen. Repository klonen, in den Ordner wechseln, Setup starten. Danach läuft die Anwendung lokal, gefüllt mit Daten, die echt aussehen und keiner echten Person gehören.

git clone git@gitlab.example.de:team/app.git
cd app
make setup

Hinter make setup steckt kein Zauber. Es ist eine Reihenfolge, die einmal sauber festgelegt wird und dann für alle gilt. In einem Symfony Projekt sieht das so aus:

setup:
	docker compose up -d
	docker compose exec app composer install
	docker compose exec app php bin/console doctrine:migrations:migrate --no-interaction
	docker compose exec app php bin/console doctrine:fixtures:load --no-interaction
	npm ci
	npm run build

Container hoch, Abhängigkeiten rein, Schema über Doctrine Migrations, Daten über Fixtures mit Faker. Ob ihr dafür Docker Compose oder DDEV nutzt, ist Geschmack. Wichtig ist ein einziger Einstieg, den jeder kennt.

In Astro Projekten gilt dasselbe Prinzip. Hier mit Drizzle gegen SQLite mit libSQL:

{
  "scripts": {
    "db:reset": "rm -f local.db && drizzle-kit migrate",
    "db:seed": "tsx scripts/seed.ts",
    "setup": "npm ci && npm run db:reset && npm run db:seed"
  }
}

Warum Seed Daten das Onboarding beschleunigen

• Keine Freigabe nötig. In den Seed Daten steckt keine echte Person. Datenschutz muss nicht gefragt werden, und Externe arbeiten ab dem ersten Tag mit.
• Immer passend zum Schema. Fixtures liegen im Repository und ändern sich mit dem Code. Ein alter Dump tut das nie.
• Alle sehen dieselbe Welt. Mit festem Seed hat jeder Rechner die gleichen Datensätze. Kunde Nummer 42 ist bei allen derselbe Kunde.
• Der Seed erklärt die Fachlichkeit. Wer die Fixtures liest, sieht, wie eine gültige Bestellung, ein aktiver Vertrag oder ein gesperrter Account aussieht.

Der letzte Punkt wird oft unterschätzt. Ein gut gepflegtes Seed Skript ist die ehrlichste Dokumentation, die ein Team hat. Sie muss laufen, sonst bricht das Setup. Die Daten selbst kommen aus Faker. Die Dokumentation von FakerPHP und von Faker für JavaScript zeigt, wie viel davon fertig mitgeliefert wird.

Senior Entwickler erklären weniger und reviewen mehr

Onboarding ist in vielen Teams eine Last für die Erfahrenen. Sie suchen Dumps, erklären Testaccounts und reparieren lokale Umgebungen. Mit einem Setup Befehl verschiebt sich das. Die Seniors sprechen über Architektur und Code Reviews. Die Umgebung erklärt sich selbst.

Das gilt genauso für KI Agenten. Ein Coding Agent wie OpenCode startet in derselben gefüllten Umgebung wie der neue Kollege. Er sieht Pagination, lange Namen und Umlaute, bevor er die erste Komponente baut. Wie ihr dafür feste Regeln aufstellt, zeigt Teil 2: Seed Daten als Teamstandard.

Der Härtetest: ein leerer Rechner

Ein Setup, das nur auf den Rechnern der alten Hasen läuft, ist kaputt. Deshalb gehört der Onboarding Befehl in die Pipeline. Ein Job in GitHub Actions oder GitLab CI startet auf einem frischen Runner, klont das Repository und führt das Setup aus. Danach laufen die Tests gegen die frisch geseedete Datenbank. Wird der Job rot, weiß das Team sofort: Der nächste neue Kollege würde genau hier hängen bleiben.

Damit wird Onboarding zu einer Eigenschaft des Projekts. Es hängt an keiner Person mehr und an keinem Wiki Artikel, der seit Monaten keiner mehr angefasst hat. Passende Quality Gates für KI Code laufen in derselben Pipeline mit.

So setzen wir das bei euch um

Faker steckt bei uns in jedem Projekt, in PHP, JavaScript und Python, lokal und auf Staging. Genau dieses Setup bauen wir auch in bestehende Projekte ein. Der Ablauf:

1. Bestandsaufnahme: Wie kommt ein neuer Entwickler heute zu einer laufenden App, und wo hängt es?
2. Ein Einstieg: ein Setup Befehl, der Container, Migrations und Seeds in der richtigen Reihenfolge startet.
3. Seeds mit Fachlichkeit: Fixtures mit Faker und festem Seed, die eure wichtigsten Fälle abbilden.
4. Pipeline Check: Das Setup läuft bei jedem Merge auf einem frischen Runner.
5. Übergabe ans Team: Wir zeigen euren Leuten, wie sie Seeds pflegen, damit das Setup nicht verwittert.

Was Faker in den drei Sprachen im Detail kann, steht auf unserer Seite zu Faker Testdaten. Wie dieselben Daten nach jedem Deployment auf Staging landen, zeigt Teil 3: Staging ohne Produktionsdaten. Und wenn ihr euer Team generell fit für KI gestützte Entwicklung machen wollt, lohnt ein Blick auf die NCA AI Coding Guardrails für bestehende Projekte.