Deine Vorschau-Umgebung täuscht dich

Ein Kunde fragte mich einmal mitten in einer Demo: „Was ist Lorem ipsum?“

Das war der Moment. Die Vorschau-URL war geladen. Alle Seiten wurden gerendert. Die Zusammenführung war sauber, der Build war grün, die Tests waren bestanden. Und ein Kunde, dem ich gerade etwas verkaufen wollte, las auf einem geteilten Bildschirm laut den Platzhaltertext vor.

Ich habe viel über diesen Moment nachgedacht. Nicht wegen der Peinlichkeit, obwohl ich sie verdient hatte. Sondern wegen dessen, was er mir darüber verriet, was eine Vorschauumgebung eigentlich ist – und das ist nicht das, was die meisten von uns denken.

Das Vorschau-Problem, bei dem es nicht um Programmieren geht

Die meisten Gespräche über Preview-Umgebungen enden bei der Frage „Funktioniert der Build?“. Jede Frontend-orientierte Plattform der letzten fünf Jahre hat das sauber gelöst. Einen Branch pushen, eine URL erhalten, die URL teilen, zusammenführen oder auch nicht. Der Code-Pfad ist in Ordnung.

Der Datenpfad ist die Lüge.

Auf den Plattformen, die die meisten von uns nutzen, wird die Anwendung bei jedem Push verzweigt, die Datenbank jedoch nicht. Die Vorschau-URL verweist auf Staging-Daten, Dev-Seed-Daten oder ein Fixture, das ein Kollege in seiner ersten Woche geschrieben hat und das seitdem niemand mehr angerührt hat. Die UI-Ebene verhält sich korrekt und rendert, was auch immer gerade in der Tabelle steht. Der reviewer, der sich eine Vorschau ansieht, hat keine Möglichkeit zu wissen, ob die Funktion mit produktionsreifen Daten funktioniert, da die Vorschau noch nie produktionsreife Daten gesehen hat.

Das Ergebnis ist eine Art von Fehler, der die Überprüfung übersteht und erst vor einem Kunden auffällt. Der „Was ist Lorem Ipsum?“-Moment ist noch eine der harmloseren Varianten. Schlimmer sind Fälle, in denen Abfragen, die bei hundert Zeilen noch funktionierten, bei einer Million abstürzen, UI-Zustände, die erst existieren, wenn ein Nutzer drei Jahre Historie hat, und Integrationen, deren Anmeldedaten in der Staging-Umgebung gültig, in der Produktivumgebung aber falsch sind.

Warum die Diskrepanz strukturell und nicht zufällig ist

Eine Preview-Umgebung mit Fixture-Daten ist ein Musterhaus. Die Sofas sehen toll aus. Die Lichtschalter funktionieren alle. Niemand hat dort je gewohnt, was bedeutet, dass man nicht sagen kann, ob die Wasserleitungen halten, sobald eine Familie einzieht.

Was dir niemand sagt: Das ist kein Bug, den die Branche ignoriert. Es ist ein Problem, das Teams lieber umgangen als gelöst haben.

Du kannst eine verwaltete Datenbank einrichten, die Verzweigungen pro Vorschau unterstützt. Du kannst einen Fixture-Generator schreiben. Du kannst anonymisierte Produktions-Snapshots wöchentlich in die Staging-Umgebung kopieren. Viele Teams tun das, und bei den meisten funktioniert es – meistens.

Jedes davon ist eine Konfiguration, die außerhalb der Anwendung existiert. Jedes davon ist ein zweites System mit eigener Laufzeit, eigener Zugriffsberechtigung, eigenem Kostenmodell und eigener Art, aus dem Takt zu geraten. Jedes davon ist Zeit, in der sich dein Team auf die Infrastruktur statt auf features konzentriert. 

Die Frontend-First-Plattformen, die Git-Push-Vorschauen populär gemacht haben, haben diesen Workflow um den Code herum aufgebaut. Der Rest der Vorschau – die Dienste und die Daten – befindet sich in der jeweiligen Integration, die das Team eingerichtet hat, meist über einen Marktplatz oder eine GitHub-Action, die jemand im letzten Quartal hinzugefügt hat.

Ein reviewer, der sich mit einem Pull-Request befasst, muss eine Frage stellen, die eigentlich nicht zu seinen Aufgaben gehören sollte: Entspricht die Datenbank in dieser Vorschau dem tatsächlichen Zustand oder ist es das, was mir die Fixture geliefert hat?

Was eine Preview-Umgebung stattdessen bedeuten könnte

Ich betreibe eine Handvoll Nebenprojekte. Sie sind klein genug, dass jede Plattformentscheidung eine Ermessensentscheidung darüber ist, wofür mein zukünftiges Ich mir dankbar sein wird. Der einzige Punkt, an dem ich niemals Abstriche mache, ist die Vorschau-Parität. Jedes Mal, wenn ich das getan habe, wurde mein zukünftiges Ich zum Kunden, der auf Lorem ipsum in meiner eigenen Demo starrt – was eine demütigende Art ist, die eigenen Pull-Requests zu überprüfen.

Bei Upsun erhält jeder Git-Zweig einen Byte-für-Byte-Klon der Produktivumgebung. Anwendung, Dienste, Daten. Das dauert etwa eine Minute. Die Datenbanken, die in deiner Vorschau laufen, sind dieselben wie in der Produktivumgebung – mit denselben Zeilen, denselben Indizes, denselben Fremdschlüsseln, einfach allem. Wenn du nicht willst, dass reviewer Kundendaten sehen, definierst du in deiner `.upsun/config.yaml` einen Sanitization-Hook, der bei der Bereitstellung personenbezogene Daten entfernt, und die reviewer erhalten realistisch geformte, aber nicht sensible Daten.

Das ist keine Marktplatz-Integration, die du pro Projekt konfigurierst. So funktionieren Umgebungen.

Der Fachbegriff dafür lautet „Byte-für-Byte-Umgebungsklonung“. Nicht gerade der eingängigste Ausdruck. Was es tatsächlich bewirkt, ist, dass ein reviewer die Frage „Funktioniert das?“ beantworten kann, ohne raten zu müssen.

Was sich im Alltag ändert

Ich spreche jede Woche mit Kunden und programmiere für Nebenprojekte mit demselben Workflow. Zwei verschiedene Jobs, dasselbe Muster aus unterschiedlichen Blickwinkeln.

Aus Kundensicht ist die Vorschau nicht mehr der Ort, an dem sich Bugs bis zur Demo verstecken. Reviewer erkennen die Abfrage, die nicht skalierbar ist. Produktmanager klicken sich durch die Funktion und bemerken, dass die „Empty-State“-Sprache falsch ist, weil sie echte leere Zustände sehen. Vertriebsingenieure führen die Demo auf dem Klon durch und nichts sagt „lorem ipsum“.

Aus Sicht der Auslieferung bekommt der „Merge“-Button endlich seine eigentliche Bedeutung. Wenn ich einen Pull-Request für einen Klon der Produktionsumgebung genehmige, genehmige ich damit das Verhalten anhand der tatsächlichen Datenstruktur, auf die meine Nutzer treffen werden. Die Kategorie der Bugs vom Typ „Review bestanden, in der Produktivumgebung gescheitert“ wird kleiner. Nicht null. Kleiner, und in einer Kategorie, die man nachvollziehen kann.

Das ist eine kleine Änderung im Workflow und eine große Veränderung in deinem Vertrauen in deine eigene Pipeline.

Eine Frage und ein Geständnis

Ruf deine letzten drei Produktionsvorfälle auf. Wie viele davon waren in der Preview-Umgebung sichtbar, in der die Änderung geprüft wurde? Wenn die Antwort „keiner“ lautet und du dir sicher bist, erfüllt deine Preview-Umgebung ihren Zweck. Wenn die Antwort „Ich weiß es nicht“ lautet, ist wahrscheinlich der Datenpfad der Grund.

Der Kunde, der mich fragte, was „lorem ipsum“ sei, ist immer noch Kunde. Er war freundlich, so wie Menschen es normalerweise sind, wenn man sich gerade vor ihren Augen blamiert hat. Was er eigentlich fragte, war meiner Meinung nach: „Warum sehe ich etwas, das nicht echt ist?“ Das ist die richtige Frage, die man jeder Vorschauumgebung stellen sollte. Deine sollte sie beantworten können, ohne dass du die Augen zusammenkneifen musst.

Weiterführende Lektüre

• Upsun-Umgebungen und Klonen
• Produktionsklon in 45 Sekunden mit vollständigen Daten und Diensten