Vorschau-Deployment

Wenn ein Team an einer Website oder einer App arbeitet, gibt es die eine Fassung, die alle Besucher im Internet sehen. Änderungen daran wären riskant, wenn man sie direkt dort ausprobiert. Deshalb wird bei einem Vorschau-Deployment eine zweite, vollständig lauffähige Fassung der Website auf einem Server gestartet. Sie enthält genau eine geplante Änderung und ist über eine eigene, meist kryptische Internetadresse erreichbar. Jeder, der diese Adresse kennt, kann darin klicken und testen wie in der echten Seite. Ist die Änderung geprüft und übernommen, wird die Vorschau-Fassung meist wieder gelöscht.

Fehler finden, bevor Kunden sie finden

Der größte Nutzen ist banal, aber entscheidend: Man sieht die Änderung, statt sie sich vorzustellen. Früher haben Entwickler einander Beschreibungen und Bildschirmfotos geschickt. Ob ein Bezahlvorgang wirklich funktioniert oder ein Menü auf dem Handy zerfällt, merkt man erst beim Ausprobieren. Ein Vorschau-Deployment macht dieses Ausprobieren zum Normalfall, nicht zur Ausnahme.

Wichtig ist auch, wer damit arbeiten kann. Für eine Vorschau braucht man keine Programmierkenntnisse, sondern nur einen Link. Also können Designer, Redakteure, Produktverantwortliche oder eine Rechtsabteilung selbst nachschauen. Bei Firmen mit hohen Anforderungen an Genauigkeit, etwa im Finanzbereich, ist das ein echter Vorteil. Ein falscher Zinssatz auf einer Produktseite fällt eher auf, wenn ihn jemand aus der Fachabteilung im Browser sieht.

Ein Nebeneffekt ist Geschwindigkeit. Weil das Prüfen wenig Aufwand macht, traut sich ein Team viele kleine Änderungen statt weniger großer. Kleine Änderungen sind leichter zu verstehen und im Fehlerfall leichter zurückzunehmen.

Vom Änderungsvorschlag zur eigenen Adresse

Der Ablauf beginnt in der Versionsverwaltung. Das ist ein Programm, das jede Änderung am Programmcode mit Datum und Autor speichert, meist ist es die Software Git. Änderungen entstehen dort in einem abgetrennten Zweig, einem sogenannten Branch. Reicht ein Entwickler diesen Zweig zur Prüfung ein, entsteht ein Änderungsvorschlag, den man Pull Request nennt.

Dieser Vorschlag löst automatisch die nächsten Schritte aus. Ein Dienst holt den Code, baut daraus die fertige Website und startet sie auf einem eigenen Server. Am Ende hängt in dem Änderungsvorschlag ein Link, oft in der Form pr-482.projekt.example.com. Der ganze Vorgang dauert typischerweise ein bis fünf Minuten. Anbieter wie Vercel, Netlify oder GitLab haben diese Funktion eingebaut.

Eine Vorschau ist allerdings nie ganz identisch mit der echten Seite. Häufig greift sie auf eine Testdatenbank mit erfundenen Daten zu, damit niemand echte Kundendaten verändert. Auch Bezahldienste laufen im Testmodus. Man muss also wissen, was die Vorschau nicht abdeckt: echte Datenmengen, echte Zugriffszahlen, echte Suchmaschinen. Wer das verwechselt, hält eine Seite für getestet, die es nur halb ist.

Wo Vorschau-Links auftauchen

Am häufigsten begegnet man Vorschau-Deployments in Werkzeugen für Softwareteams, etwa auf GitHub oder GitLab. Dort steht unter jedem Änderungsvorschlag ein Kommentar mit dem Vorschaulink. In Firmen ist es üblich, dass eine Änderung erst freigegeben wird, wenn mindestens eine Person die Vorschau geöffnet hat.

Auch außerhalb der Programmierung gibt es das Prinzip. Redaktionssysteme zeigen einen Artikel im fertigen Layout, bevor er erscheint. Bei Werkzeugen zum Erstellen von Websites ohne Code heißt der Knopf oft einfach Vorschau. Der Gedanke ist derselbe: erst ansehen, dann veröffentlichen.

In Nachrichten über Technologiefirmen tauchen Vorschau-Deployments meist im Zusammenhang mit Entwicklerplattformen auf. Sie sind ein Verkaufsargument von Hosting-Anbietern und ein Kostenfaktor, weil jede Vorschau Rechenzeit verbraucht. Und sie sind gelegentlich ein Sicherheitsthema: Vorschau-Adressen sind selten geheim, aber oft nicht durch ein Passwort geschützt. Schon mehrfach wurden über solche Links unfertige Produkte oder interne Daten öffentlich sichtbar.