Preview-Environments erklärt: eine frische Kopie deiner App für jeden Pull Request

Ein Preview-Environment ist eine kurzlebige Kopie deiner Anwendung, gebaut aus einem Pull Request oder Branch und unter einer eigenen URL erreichbar. Reviewer öffnen einen Link und testen die Änderung im Browser, statt einen Diff zu lesen. Ist die Arbeit fertig, verschwindet die Umgebung.

Dieser Guide erklärt, wofür Preview-Environments gut sind, was sie knifflig macht und wie sie auf Nodion funktionieren.

Was ist ein Preview-Environment?

Denk an eine temporäre Staging-Umgebung für eine Änderung. Jeder Pull Request, oder ein Branch, den du wählst, bekommt:

• einen eigenen Build des Codes auf diesem Branch,
• eine eigene laufende App mit eigener URL,
• eigene Kopien der Dienste, von denen sie abhängt, meist mindestens eine frische Datenbank,
• eine begrenzte Lebensdauer.

Der Unterschied zu einem klassischen gemeinsamen Staging-Server: niemand wartet, bis Staging frei ist, und ein halbfertiges Feature kann den Test eines anderen nicht kaputtmachen. Dieselbe Idee heißt auch Review Apps, Deploy Previews oder Ephemeral Environments.

Warum Teams sie nutzen

• Laufende Software reviewen, nicht nur Code. Ein kaputtes Layout, ein verwirrender Flow oder eine langsame Seite fällt im Browser auf und im Diff leicht unter.
• QA pro Änderung. Tester prüfen eine Änderung isoliert vor dem Merge, jeder gefundene Bug gehört also genau einem Pull Request.
• Stakeholder ohne Dev-Setup. Designer, Product Manager oder ein Kunde öffnen einen Link. Kein lokales Checkout, kein Screensharing.
• Migrationen testen. Eine Schema-Migration muss gegen eine echte Datenbank laufen, bevor das Preview funktioniert. Eine Migration, die nur auf einem Laptop klappt, scheitert hier, nicht in Production.
• Parallele Arbeit. Fünf offene Pull Requests heißen fünf Previews statt einer Schlange vor einem Staging-Server.

Was sie schwer macht

Die App zu bauen ist der einfache Teil. Die schwierigen Teile liegen darumherum.

Datenbanken

Eine App ohne Daten ist schwer zu reviewen, die meisten Previews brauchen also eine Datenbank. Es gibt drei übliche Varianten: eine leere Datenbank, eine leere Datenbank plus Seed-Daten oder eine Kopie von Production. Production zu kopieren ist verlockend, legt aber echte Kundendaten, inklusive personenbezogener Daten, in viele kurzlebige Umgebungen, die mehr Leute öffnen können. Es wird außerdem langsam, sobald die Datenbank groß ist. Für die meisten Teams ist eine leere Datenbank mit einem Seed-Skript für realistische Demo-Daten der sicherere Default.

Secrets

Ein Preview führt Code aus, der noch nicht reviewt ist. Production-Credentials gehören dort nicht hin. Gib Previews Test- oder Sandbox-Keys für Payment-Provider, E-Mail und Third-Party-APIs, damit ein Bug in einem Branch keine echte Karte belasten oder echte Kunden mailen kann.

URLs und Callbacks

Jedes Preview hat einen anderen Hostnamen. OAuth-Redirect-URLs, Webhook-Endpoints, CORS-Regeln und Cookies, die an deine Production-Domain gebunden sind, können brechen. Apps, die ihre eigene Base-URL aus der Konfiguration lesen statt die Production-Domain fest einzubauen, haben hier deutlich weniger Probleme.

Kosten und Aufräumen

Jedes offene Preview betreibt eine App plus eine frische Datenbank für jede Datenbank, die an die Parent-App gehängt ist. Zehn offene Pull Requests können zehn Extra-Umgebungen heißen, und ein vergessenes Preview läuft, bis es jemand schließt. Aufräumen muss passieren, ohne dass jemand dran denkt, deshalb sollten Previews von selbst auslaufen.

Wie Preview-Environments auf Nodion funktionieren

Auf Nodion gehören Previews zu jeder Anwendung, die aus einem Git-Repository deployt:

• Einschalten in den Settings der App.
• Ein Preview pro Pull Request oder Branch. Jedes Preview ist eine ephemere App mit eigener URL.
• Per Hand oder automatisch. Lege ein Preview per Hand an oder lass Nodion eines automatisch für Pull Requests anlegen.
• Eine frische Datenbank. Für jede an die App gehängte Datenbank bekommt ein Preview eine eigene leere Datenbank, nie einen Klon deiner Production-Daten. Volumes, Buckets und E-Mail-Zonen werden nicht kopiert.
• Die Settings der App kommen mit. Ein Preview startet mit einer Kopie der Umgebungsvariablen der App, Secrets inklusive. Die Variablen angehängter Datenbanken zeigen auf die frischen Preview-Datenbanken; alles andere, inklusive Keys und URLs anderer Dienste, wird so kopiert, prüfe das also. Nodion setzt NODION_PREVIEW=1, NODION_PR_NUMBER, NODION_BRANCH und NODION_PARENT_APP.
• Previews laufen aus nach einer Anzahl Tage ohne Deploy (7 als Default, in den Settings der App gesetzt). Bis dahin kannst du jedes vom Tab Previews der App neu deployen oder schließen.
• Nur Git-Apps. Apps, die aus einem vorgebauten Image deployt werden, haben keine Previews.

Die frische Datenbank ist eine bewusste Entscheidung: angehängte Preview-Datenbanken starten leer und halten keine Production-Daten. Prüfe auch die kopierten Keys und URLs, damit Preview-Code darüber nicht Production-Systeme erreicht. Die Kehrseite: deine App muss von einer leeren Datenbank starten, und das lohnt sich sowieso.

Zum Start verbinde dein Repository unter Git-Integrationen, lege die App daraus an und schalte Previews in ihren Settings ein. Die Details stehen in den Applications-Docs.

Ein typischer Review-Loop

1. Ein Entwickler öffnet einen Pull Request. Mit automatischen Previews startet eines mit eigener URL und einer leeren Datenbank.
2. Der Entwickler postet den Preview-Link im Pull Request. Reviewer, QA und der Product Owner testen die Änderung im Browser.
3. Feedback wird zu neuen Commits. Deploye das Preview vom Tab Previews neu, damit die Reviewer den neuesten Code sehen.
4. Ist die Änderung approved und gemergt, schließe das Preview oder lass es von selbst auslaufen.

Niemand musste um einen Staging-Slot bitten, und Nodion hat die angehängte Datenbank durch eine frische ersetzt. Prüfe alle anderen kopierten Keys und URLs, bevor Preview-Code läuft, weil sie weiter dorthin zeigen, wohin die Settings der App zeigen.

Mach deine App preview-ready

• Migrationen automatisch ausführen, wenn die App deployt oder startet, damit eine frische Datenbank das aktuelle Schema ohne Handarbeit bekommt.
• Ein Seed-Skript ergänzen, das einen Test-Login und etwas Demo-Inhalt anlegt. Reviewer sollten beim ersten Klick etwas Nützliches sehen.
• Die Base-URL aus einer Umgebungsvariable lesen statt deine Production-Domain fest einzubauen.
• Seiteneffekte auf Testmodus umschalten, wenn NODION_PREVIEW gesetzt ist: Payments, E-Mails und alles, was in andere Systeme schreibt. Previews erben die Secrets der App, ohne diesen Check nutzt ein Preview also deine Production-Keys.
• Pull Requests klein halten. Ein Preview für eine fokussierte Änderung ist viel leichter zu reviewen als eines für eine Woche Arbeit.

Wann du sie weglassen kannst

Für ein Solo-Projekt mit ein paar Änderungen pro Woche reichen lokales Setup plus Production oft. Previews lohnen sich, sobald mehr als eine Person Änderungen reviewt, testet oder freigibt, oder wenn Datenbankmigrationen zu deiner normalen Arbeit gehören.

Previews gehören zu jeder Git-App auf Nodion, neben Prozessen, Logs, Metriken und Auto-Deploy. Den vollen Überblick findest du unter Applications.