
Bevor er zu Upsun kam, hat Andrew Kester den größten Verkauf des Jahres eines Kunden vermasselt.
Er war einer von zwei oder drei Webentwicklern bei einer Kreativagentur, die sich mit Branding, Logos, Print und Websites beschäftigte. Eine Design-Boutique stand kurz vor ihrer jährlichen Trunk-Show, und die Rabatte sowie die features sollten bis zur Enthüllung am Dienstagmittag geheim bleiben. Der Kunde bat um eine Vorschau. Die Vorschau gelangte in die Produktivumgebung. Genau solche Pannen sprechen für Vorschauumgebungen mit Produktionsdaten und erklären, warum die Mechanismen des Klonens von Umgebungen wichtiger sind, als es auf den ersten Blick scheint.
„Die Startseite ihrer Website war die große Enthüllung, und sie war etwa zwei Tage zu früh online“, sagt Kester, der mittlerweile als Senior Cloud Support Engineer bei Upsun arbeitet. „Wir hatten die falsche Umgebung veröffentlicht, oder ich weiß nicht mehr genau, was passiert ist, aber irgendwo sind Datenbanken durcheinandergekommen. Es war ein Chaos.“
Andrew erzählt die Geschichte in der neuesten Folge von „Product Highlights“. Seitdem hat er Jahre auf der anderen Seite verbracht – in einem Support-Team, das rund um die Uhr, jeden Tag im Jahr im Einsatz ist und aus Ingenieuren in Nordamerika, Südamerika, Europa, Japan und Australien besteht.
Die Tickets reichen von Produktfragen bis hin zu Websites, die gerade von Angreifern unter Beschuss stehen. Er hat gesehen, was in großem Maßstab alles schiefgehen kann – was seine Lieblingsfunktion der Plattform zu einer vielsagenden Wahl macht: den Button, der eine Umgebung klont.
Das Muster, das Andrew beschreibt, wird jedem bekannt vorkommen, der schon einmal Websites für Kunden erstellt hat. Ein Kunde möchte eine neue Seite, eine neue Funktion, einen neuen Gutschein. Er möchte das Ergebnis sehen, bevor es live geht. Nichts im Stack war dafür ausgelegt, ihm das zu ermöglichen.
„Eine der größten Herausforderungen, auf die wir immer wieder stießen, war, dass wir einen Kunden hatten, der eine neue Website, eine neue Funktion, eine neue Seite, einen neuen Gutschein – was auch immer – wollte, und dass wir ihm das zeigen konnten, ohne seine Produktivumgebung zu beeinträchtigen“, sagt er.
Auch improvisierte die Agentur. Man kopierte die Umgebung von Hand und hoffte, dass die Kopie gut genug war. Oder man schickte das neue Programm hinter einer Passwortprüfung in die Produktivumgebung und hoffte, dass die Prüfung hielt. Andrews Einschätzung dieses zweiten Ansatzes ist schonungslos: Wenn alles perfekt lief und der Kunde das richtige Passwort hatte, wurde der versteckte Teil der Seite angezeigt, „aber das war nie wirklich zuverlässig.“
Beide Ansätze scheitern aus demselben Grund. Eine von Hand kopierte Umgebung ist eine Vermutung über die Produktionsumgebung, und ein Feature-Flag in der Produktivumgebung ist immer noch Produktionsumgebung. Keiner von beiden bietet dir einen Spielraum, in dem Fehler keine Folgen haben.
Auf Upsun Cloud™ ist eine neue Umgebung eher eine Branch-Operation als ein Neuaufbau. Pushe einen Branch, führe „upsun branch“ aus oder eröffne einen Pull-Request, und standardmäßig erbt die neue Umgebung die Daten und Dienste ihres übergeordneten Branches, einschließlich Datenbanken, Netzwerkspeicher, queues und Routing-Konfiguration.
Wenn du das Programm ohne die Daten haben möchtest, führe den Push mit „environment.clone_parent_on_create=False“ durch.
Upsun führt die Geschwindigkeit des Kopiervorgangs auf „Copy-on-Write“-Snapshots zurück – genau das macht das Klonen zu einer Routineaufgabe statt zu etwas, das man extra planen muss.
Andrews Zusammenfassung der Entwicklererfahrung umfasst drei Sätze.
„Du klickst auf eine Schaltfläche. Wir klonen deine Dienste. Wir klonen die Daten.“
Der Datenteil ist das, was dies von den Vorschau-Links unterscheidet, die die meisten Teams bisher genutzt haben. Eine statische Frontend-Vorschau sagt nur sehr wenig über eine Website mit Content-Management aus. Wie Andrew betont, enthalten Anwendungen wie WordPress oder die von seiner Agentur betriebenen ExpressionEngine-Seiten eine Datenbank voller Initialisierungszustände. Konfiguration, Inhaltstypen, Beziehungen – die gesamte Struktur einer echten Installation. Eine leere Datenbank ist keine kleinere Version davon. Es ist eine andere Anwendung.
Source-Integrationen erweitern dieses Verhalten auf die Code-Reviews. Wenn die GitHub- oder GitLab-Integration verbunden ist, ist „build-pull-requests“ standardmäßig aktiviert, sodass beim Erstellen eines Pull-Requests eine Live-Umgebung erstellt wird, die dem Ziel-Branch untergeordnet ist. Außerdem ist „pull-requests-clone-parent-data“ standardmäßig aktiviert, sodass diese Umgebung bereits mit den Daten des übergeordneten Branches bereitgestellt wird.
Entwürfe von Pull-Requests werden einbezogen, sofern du sie nicht deaktivierst. Reviewer erhalten eine URL statt eines Checkouts – das ist der Unterschied zwischen der Programmierung und der Prüfung der Änderung. Dadurch entfällt auch die queue für einen gemeinsam genutzten Staging-Server – ein Problem, das eine eigene Diskussion wert ist.
Die Übereinstimmung mit der Produktivumgebung ist nur die Hälfte des Nutzens. Die andere Hälfte besteht darin, dass nichts, was du im Klon tust, zurückgelangen kann.
„Alle Änderungen beim Programmieren, alle Datenbankänderungen sind isoliert, es besteht also kein Risiko“, sagt Andrew. „Wenn ich etwas ändere, werde ich es nicht versehentlich zurück in die Produktivumgebung pushen.“
Upsun stellt dies als Eigenschaft der Plattform dar und nicht als eine Praxis, die Teams aufrechterhalten müssen: Umgebungen sind standardmäßig vollständig isoliert, und nichts wandert zwischen ihnen hin und her, es sei denn, du gibst den Befehl dazu. Mit „Sync“ holst du Code oder Daten vom übergeordneten Server herunter. Mit „Merge“ schiebst du Code nach oben. Beides sind Befehle, die du bewusst ausführst – und genau darum geht es.
Diese Garantie verändert, was ein Entwickler bereit ist, auszuprobieren. Andrew bringt das alte Sprichwort auf den Punkt und korrigiert es dann. „Move fast and break things“ funktioniert nicht, wenn der einzige Ort, an dem man etwas ändern kann, die Produktivumgebung ist, denn Vorsicht wächst mit den Konsequenzen, und am Ende geht man bei jedem Deployment äußerst vorsichtig vor. Gib demselben Entwickler eine Wegwerfkopie, und die Rechnung kehrt sich um.
„Wenn du die gesamte Datenbank kaputt machst und sie zurücksetzt – wen interessiert das schon? Erstelle einfach eine neue. Kopiere sie einfach wieder rein. Das ist ein einziger Befehl.“
Eine destruktive Migration, deren Ablauf du erst einmal beobachten möchtest, bevor du ihr vertraust, ist kostengünstig, wenn der Schadensradius auf einen Branch beschränkt ist.
Die Wirtschaftlichkeit einer Einweg-Produktionskopie hat sich erneut verändert, denn Entwickler sind nicht mehr die Einzigen, die danach fragen.
Greg Qualls, Director of Product Marketing bei Upsun, sagt, dass Kunden zunehmend einen Agenten wollen, der „anhand echter Produktionsdaten testet, ohne mit der Produktivumgebung zu interagieren“.
Beide Anforderungen müssen gleichzeitig erfüllt sein. Ein Agent, der in einer leeren Sandbox arbeitet, verfügt über Hardware-Isolation, aber keinen Kontext. Er kann einen Abfrageplan nicht zuverlässig validieren, nicht bestätigen, dass eine Migration abgeschlossen ist, und nicht feststellen, dass eine Änderung bei genau jenem Inhaltstyp fehlschlägt, der nur im echten Datensatz existiert. Upsun hat genau diesen Punkt als Argument für zustandsbehaftete Sandboxen angeführt: Kurzlebige Sandboxen isolieren zwar die Rechenleistung, verfügen aber in der Regel nicht über die produktionsnahen Daten, die ein Agent benötigt, um seine eigene Arbeit zu überprüfen.
Isolation ist bei einem Agenten wichtiger als bei einer Person, da die Fehlermodi weniger vorhersehbar sind. Ein irrtümlich ausgeführter zerstörerischer Befehl oder eine außer Kontrolle geratene Schleife ist in einer Vorschauumgebung ein ganz anderes Ereignis als in der Produktivumgebung. Einem Agenten einen Branch anstelle von Produktionszugangsdaten zu übergeben, ist der von Upsun befürwortete „Propose-and-Test“-Workflow – und er funktioniert, weil der Branch real genug ist, um etwas zu beweisen, und gleichzeitig so entbehrlich, dass es keine Rolle spielt.
Zwei Details solltest du wissen, bevor du einem Kunden eine Vorschau-URL weitergibst.
Suchmaschinen werden für dich gehandhabt. Nicht-Produktionsumgebungen ohne eigene Domain sind immer vor Suchmaschinen verborgen, und dieses Verhalten lässt sich nicht ändern. Vorschauumgebungen mit einer eigenen Domain sind standardmäßig verborgen, und du kannst sie auf Wunsch sichtbar machen.
Der Zugriff durch Menschen wird nicht automatisch geregelt. Eine Vorschau-Umgebung ist für jeden mit der URL erreichbar, bis du die HTTP-Zugriffskontrolle konfigurierst. Diese bietet dir entweder Benutzername-Passwort-Paare oder eine IP-Zulassungs-/Sperrliste in CIDR-Notation, die du in der Upsun-Konsole oder über upsun environment:http-access einrichten kannst.
Untergeordnete Umgebungen erben die Einstellungen der übergeordneten Umgebung, allerdings muss eine bereits vorhandene Umgebung neu bereitgestellt werden, damit eine Änderung übernommen wird – richte die Einstellungen also in der übergeordneten Umgebung ein, bevor du mit dem Teilen von Links beginnst. Für Teams, die sensible Datens ätze klonen, sind Deployment-Hooks der richtige Ort, um Daten im Rahmen des Klonvorgangs zu bereinigen oder zu anonymisieren.
Andrews „Trunk-Show“-Vorfall war ein Workflow-Fehler, kein Berechtigungsfehler. Die Lösung lag nie in einem besseren Passwort. Es ging darum, einen Ort zu schaffen, an dem unveröffentlichte Arbeiten abgelegt werden konnten, die zwar noch nicht in der Produktivumgebung waren, aber produktionsähnlich genug aussahen, um sie einem Kunden zu zeigen.
Dieser Ort ist jetzt eine Schaltfläche. Erfahre mehr über sofortige Entwicklungsumgebungen auf Upsun Cloud oder lies die Dokumentation zu den Umgebungen, um zu sehen, wie Verzweigungen, Synchronisierungen und Zusammenführungen zusammenpassen.