Staging ohne Produktionsdaten: Seed in der Pipeline statt Dump

Staging ohne Produktionsdaten klingt nach Verzicht. In der Praxis ist es der schnellere Weg. Neue Teammitglieder, Product Owner und Externe arbeiten auf einer gefüllten Umgebung, und niemand muss klären, wer welche Kundendaten sehen darf. Wir zeigen, wie der Seed nach jedem Deployment automatisch auf Staging landet. In PHP, JavaScript und Python nach demselben Muster.

Teil 3 der Serie zu Seed Daten im Team. Teil 1: Team Onboarding mit Seed Daten. Teil 2: Seed Daten als Teamstandard.

Warum der Dump auf Staging bremst

Viele Teams spielen alle paar Wochen einen Dump aus Production auf Staging. Das wirkt bequem. Mit jedem neuen Teammitglied wird es teurer:

• Jeder Zugang ist ein Datenschutzthema. Wer Staging sieht, sieht echte Kundendaten. Für Werkstudenten, Freelancer und Agenturen braucht es jedes Mal eine Klärung.
• Anonymisierung ist Handarbeit. Namen und Mails lassen sich ersetzen. Freitexte, Anhänge und Notizfelder rutschen gern durch.
• Der Stand veraltet schnell. Neue Migrations passen nicht mehr zum alten Dump, und jemand muss nachbessern.
• Echte Mails gehen raus. Ein falsch konfigurierter Mailer auf Staging schreibt echte Kunden an.

Das Prinzip: Deployment, Reset, Seed

Auf Staging laufen bei uns dieselben Seeds wie lokal. Die Reihenfolge ist immer gleich:

1. Die Pipeline baut das Staging Image und deployt es.
2. Ein eigener Job setzt die Datenbank zurück und spielt die Migrations ein.
3. Derselbe Job lädt die Seeds mit festem Seed-Wert.
4. Cypress läuft gegen die frisch gefüllte Umgebung.

Nach jedem Deployment ist Staging also in einem bekannten Zustand. Was gestern bei der Abnahme kaputt geklickt wurde, ist heute wieder sauber. Und weil lokal dieselben Daten liegen, lässt sich jeder Fund von Staging am eigenen Rechner nachstellen. Wie der gemeinsame Seed als Teamstandard funktioniert, steht in Teil 2: Seed Daten als Teamstandard.

Staging Image mit Dev Paketen, Production ohne

Faker ist eine Dev Abhängigkeit und hat in Production nichts verloren. Staging braucht sie aber für den Seed. Die saubere Lösung ist ein Dockerfile mit zwei Zielen:

FROM php:8.4-fpm AS base
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer
WORKDIR /app
COPY . .

FROM base AS staging
RUN composer install --no-interaction

FROM base AS production
RUN composer install --no-dev --no-interaction --optimize-autoloader

Gebaut wird mit docker build --target staging oder --target production. Das Production Image bleibt schlank und enthält keine Testwerkzeuge. In JavaScript und Python funktioniert es genauso, mit npm ci gegenüber npm ci --omit=dev oder der dev Gruppe in der pyproject.toml.

Symfony: Fixtures auch für Staging freischalten

Ein Stolperstein in Symfony Projekten: Das Fixtures Bundle ist standardmäßig nur für dev und test registriert. Für Staging muss die Umgebung ergänzt werden:

// config/bundles.php
return [
    // ...
    Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle::class => [
        'dev' => true,
        'test' => true,
        'staging' => true,
    ],
];

Production bleibt außen vor. Der Befehl zum Laden der Fixtures existiert dort gar nicht, und niemand kann versehentlich die Live Datenbank leeren.

Der Seed Job in der Pipeline

Der Job läuft direkt nach dem Deployment auf Staging. In GitLab CI:

seed_staging:
  stage: seed
  needs: ["deploy_staging"]
  environment: staging
  script:
    - ssh deploy@$STAGING_HOST "cd /srv/app && docker compose exec -T app php bin/console doctrine:fixtures:load --no-interaction"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

Und dasselbe als Job in GitHub Actions:

seed-staging:
  needs: deploy-staging
  runs-on: ubuntu-latest
  environment: staging
  steps:
    - name: Reset und Seed auf Staging
      run: ssh deploy@${{ secrets.STAGING_HOST }} "cd /srv/app && docker compose exec -T app php bin/console doctrine:fixtures:load --no-interaction"

doctrine:fixtures:load leert die Tabellen vor dem Laden. Reset und Seed passieren also in einem Schritt. SSH Schlüssel und Host liegen als geschützte Variablen in der Pipeline. JavaScript und Python Projekte rufen an derselben Stelle ihr Seed Skript auf. Die Grundlagen stehen in der Dokumentation zu GitLab CI und zu GitHub Actions. Wie wir Staging Umgebungen mit Docker und Preview URLs aufbauen, zeigt unsere Seite zur CI CD Pipeline mit Docker und Staging.

Mails landen im Mailcatcher

Seed Daten sehen echt aus. Eine generierte Adresse kann zufällig einer echten Person gehören. Deshalb geht auf Staging keine Mail in den echten Versand. Ein Mailcatcher wie Mailpit fängt alles ab und zeigt es im Browser an. In Symfony reicht eine Zeile in der Umgebungskonfiguration:

MAILER_DSN=smtp://mailpit:1025

Für die Abnahme ist das sogar ein Gewinn. Der Product Owner sieht jede Mail, die das System verschickt, ohne ein Testpostfach einzurichten.

Wer im Team davon profitiert

• Neue Teammitglieder klicken sich am ersten Tag durch eine gefüllte Anwendung. Lokal steht dasselbe Setup mit einem Befehl, wie in Teil 1 beschrieben: Team Onboarding mit Seed Daten.
• Product Owner nehmen Features auf Daten ab, die alle Sonderfälle enthalten.
• Externe und Agenturen bekommen Zugang ohne Datenschutzklärung.
• QA und E2E Tests laufen gegen einen bekannten Zustand. Wie wir das mit Cypress aufsetzen, zeigt unser Cypress E2E Testing Setup.

So setzen wir das bei euch um

Faker nutzen wir in allen Projekten, lokal und auf Staging. In bestehenden Pipelines gehen wir in kleinen Schritten vor. Zuerst trennen wir die Images für Staging und Production. Dann kommen Seed Job und Mailcatcher dazu. Zum Schluss läuft Cypress gegen die frisch gefüllte Umgebung. Euer Team ist dabei, damit es die Pipeline danach selbst weiterführt.

Den Überblick über Faker in PHP, JavaScript und Python findet ihr auf unserer Seite zu Faker Testdaten. Datenschutz in KI gestützten Projekten behandeln wir auf der Seite zur Vibe Coding Datenschutz Beratung.