Staging-Umgebung für deine App einrichten

Um eine Staging-Umgebung einzurichten, deployst du eine zweite Kopie deiner App unter einer eigenen, nicht öffentlichen URL, gibst ihr eine eigene Datenbank und eigene Test-API-Schlüssel und sorgst dafür, dass sie der Einrichtung der Produktion so nah wie möglich kommt. Dann veröffentlichst du jede wichtige Änderung zuerst auf Staging, durchläufst die wichtigsten Abläufe und publizierst erst in die Produktion, wenn Staging gut aussieht.

Wenn dir die Idee neu ist, erklärt was eine Staging-Umgebung ist das Konzept. Dieser Leitfaden ist die praktische Einrichtung, geschrieben für Menschen, die mit KI-Tools bauen und kein DevOps-Team betreiben.

Entwicklung, Staging und Produktion

Die meisten kleinen Apps brauchen drei Umgebungen, auch wenn die erste nur die Vorschau deines Builders ist:

Der Sinn von Staging ist, dass es sich wie die Produktion verhält, also derselbe Code, derselbe Stack und ähnliche Einstellungen, aber ein Fehler dort niemandem schadet.

Schritt 1: Festlegen, was Staging abbilden muss

Staging ist nur nützlich, wenn Probleme dort auftauchen, bevor sie in der Produktion auftauchen. Gleiche an:

• Denselben Code, auf dieselbe Art veröffentlicht.
• Denselben Stack und dieselben Versionen: Framework, Laufzeitumgebung, Datenbanktyp.
• Dieselbe Art der Konfiguration: dieselben Namen der Umgebungsvariablen, mit Testwerten.
• Dieselben Dienste: Hat die Produktion eine Web-App und eine API, hat Staging beides.

Es darf sich in der Größe (eine kleinere Maschine ist in Ordnung) und bei den Daten unterscheiden.

Schritt 2: Die Kopie anlegen

Der einfachste Weg ist ein zweites Deployment desselben Projekts unter einer anderen URL, etwa staging.deineapp.com oder deineapp-staging.example.com.

Wie du das machst, hängt von deinem Host ab:

• Hosts mit eingebauten Preview- oder Staging-Deployments können eines automatisch für einen Git-Branch anlegen.
• Hosts ohne das: Lege eine zweite App oder ein zweites Projekt aus demselben Code an und deploye es separat.
• Code in Git: Halte einen Branch staging oder main vor, der nach Staging deployt, und deploye die Produktion aus einem Release. Siehe wie du Git mit einer KI-gebauten App nutzt.

Schritt 3: Staging eine eigene Datenbank geben

Dieser Schritt schützt dich. Wenn Staging und Produktion sich eine Datenbank teilen, löscht ein Test, der Datensätze entfernt, echte Datensätze.

• Lege eine separate Datenbank für Staging an.
• Befülle sie mit Seed-Daten, also realistischen erfundenen Datensätzen, die die KI dir erzeugen kann.
• Wenn du eine Kopie der Produktivdaten brauchst, entferne oder verfremde vorher Namen, E-Mails und alles Persönliche.

Schreib ein Seed-Skript, das eine leere Datenbank mit realistischen Testdaten füllt: 20 Kunden, 50 Bestellungen in verschiedenen Zuständen und zwei Admin-Nutzer. Verwende offensichtlich erfundene Namen und E-Mail-Adressen unter example.com.

Bevor du der Einrichtung vertraust, prüfe, mit welcher Datenbank jede Kopie verbunden ist. Frag direkt nach:

Mit welcher Datenbank verbindet sich diese App, und woher kommt diese Einstellung? Zeig mir den Namen der Variable, nicht das Passwort.

Schritt 4: Testschlüssel und getrennte Einstellungen verwenden

Alles, was mit einem externen Dienst spricht, sollte in Staging Test-Zugangsdaten verwenden:

• Zahlungen im Testmodus (zum Beispiel Stripe-Testschlüssel), damit keine echte Karte belastet wird.
• E-Mail an eine Sandbox oder nur an deine eigene Adresse, damit Kunden nie eine Testnachricht bekommen.
• KI- und andere kostenpflichtige APIs mit eigenem Schlüssel und niedriger Ausgabengrenze.
• Webhooks, die auf die Staging-URL zeigen und nicht auf die Produktion.

Behalte die Variablen-Namen in beiden Umgebungen gleich und ändere nur die Werte. So muss der Code nicht wissen, wo er gerade läuft. Mehr dazu erfährst du in wie du API-Schlüssel sicher aufbewahrst.

Schritt 5: Staging privat halten

Staging sollte nicht öffentlich sein:

• Setze es hinter einen Login, ein Passwort oder eine Allow-List mit Team-E-Mails.
• Verhindere die Indexierung durch Suchmaschinen mit einem noindex-Meta-Tag oder dem Header X-Robots-Tag.
• Verlinke nicht von deiner öffentlichen Seite darauf.
• Sorge für ein anderes Aussehen, zum Beispiel ein auffälliges farbiges Banner „STAGING“. Das verhindert, dass du im falschen Tab testest.

Füge auf jeder Seite oben ein auffälliges gelbes Banner mit dem Text „STAGING: nur Testdaten“ hinzu, wenn die Umgebungsvariable APP_ENV den Wert „staging“ hat. Setze in diesem Fall außerdem ein noindex-Meta-Tag.

Schritt 6: Eine Release-Routine festlegen

Staging hilft nur, wenn du es jedes Mal benutzt. Eine einfache Routine:

1. Mach die Änderung in der Entwicklung und prüfe sie in der Vorschau.
2. Veröffentliche sie auf Staging.
3. Durchlaufe deine wichtigsten Abläufe: anmelden, einloggen, das Hauptfeature, Zahlungen, alles, was die Änderung berührt.
4. Wenn etwas kaputtgeht, behebe es und veröffentliche erneut auf Staging.
5. Veröffentliche dieselbe Version in der Produktion.
6. Prüfe die Produktion kurz: dieselben Abläufe, nur knapp.

Schreib die wichtigsten Abläufe als kurzes Testskript auf. Was dazugehört, steht in wie du deine App vor dem Launch testest.

Schritt 7: Datenbankänderungen vorsichtig durchführen

Änderungen an der Datenbankstruktur, etwa eine neue Spalte oder das Umbenennen einer Tabelle, sind der Punkt, an dem sich Staging bezahlt macht.

• Führe jede strukturelle Änderung zuerst auf Staging aus.
• Prüfe, ob die bestehenden Daten erhalten geblieben sind, nicht nur, ob neue Funktionen funktionieren.
• Erstelle ein Backup der Produktion, bevor du dieselbe Änderung dort ausführst. Siehe wie du deine App-Datenbank sicherst.
• Bevorzuge Änderungen, die hinzufügen statt umbenennen oder löschen, damit die alte Version noch funktioniert, wenn du zurückrollst.

Beispiel-Prompts

Erkläre, was mit den bestehenden Daten passieren würde, wenn wir diese Datenbankänderung in der Produktion ausführen. Wird etwas gelöscht oder umbenannt?

Lass alle umgebungsspezifischen Einstellungen, also API-URLs, Schlüssel, E-Mail-Absender und die eigene URL der Seite, aus Umgebungsvariablen mit denselben Namen in Staging und Produktion kommen. Liste sie auf.

Schreib eine kurze Checkliste der Abläufe, die ich vor jeder Veröffentlichung auf Staging testen sollte, basierend darauf, was diese App tut.

Häufige Fehler

• Gemeinsame Datenbank. Der schädlichste Fehler. Staging bekommt immer seine eigene.
• Live-Schlüssel in Staging. Echte Abbuchungen, echte E-Mails an echte Kunden.
• Staging driftet von der Produktion ab. Andere Versionen oder Einstellungen führen dazu, dass Staging keine Probleme mehr findet.
• Eine öffentliche, indexierte Staging-Seite, die in den Suchergebnissen neben deiner echten erscheint.
• Staging für „kleine“ Änderungen überspringen. Auch kleine Änderungen können Dinge kaputt machen.
• Im falschen Tab testen. Ein sichtbares Banner verhindert das.

Checkliste

• Staging läuft mit demselben Code, Stack und denselben Diensten wie die Produktion.
• Staging hat eine eigene Datenbank mit Test- oder verfremdeten Daten.
• Zahlungen, E-Mail und kostenpflichtige APIs nutzen in Staging Testschlüssel.
• Variablennamen stimmen überein; nur die Werte unterscheiden sich.
• Staging ist hinter einem Login oder Passwort und nicht indexiert.
• Ein Banner zeigt an, dass du auf Staging bist.
• Jede Veröffentlichung geht zuerst auf Staging, mit einer schriftlichen Liste der zu prüfenden Abläufe.
• Datenbankänderungen laufen zuerst auf Staging, mit einem Backup der Produktion vor der Veröffentlichung.

Staging auf Mythex

Mythex Publish gibt dir eine Live-URL pro App. Einen separaten Staging-Schalter gibt es nicht. In der Praxis hast du zwei Optionen:

• Vorschau als Prüfung vor der Veröffentlichung. Jedes Projekt läuft in einem privaten Cloud-Workspace mit einer Live-Vorschau. Unter /test klickt der Agent wie ein Nutzer durch sie, und ein Share-Link lässt einen Kunden oder Teamkollegen die Vorschau prüfen, ohne dass du veröffentlichst. Siehe Vorschau und Code. Für viele Solo-Projekte reicht das.
• Ein zweites Projekt als Staging. Im Pro-Tarif exportierst du das Projekt, importierst es in ein neues Projekt, gibst diesem eine eigene Datenbank und eigene Test-Schlüssel als Geheimnisse und veröffentlichst es unter einem eigenen Slug. Du veröffentlichst zuerst dorthin, bevor du das Produktionsprojekt veröffentlichst.

Frag in beiden Fällen den Agenten, welche Datenbank die Vorschau und die veröffentlichte App verwenden, bevor du etwas Destruktives testest. Und nutze Checkpoints, um eine fehlerhafte Änderung zurückzurollen. Wie du eine App insgesamt live bringst, erklärt wie du einen KI-Prototyp in die Produktion bringst.

Fragen