Cloudflare gab jedem Git-Branch seine eigene isolierte produktionsähnliche Umgebung

Cloudflare Workers hatte bereits Version-URLs für bestimmte hochgeladene Versionen, aber diese konnten nur auf Produktionsressourcen verweisen und schufen keine isolierte Umgebung pro Änderung. Das sichere Testen einer größeren Änderung bedeutete daher, den gemeinsamen Staging-Zustand zu riskieren oder pro Umgebung einen separaten Worker aufzusetzen. Da agentengestützte Entwicklung immer mehr und immer größere Änderungen durch die Pipeline schickte, musste mehr getestet werden, bevor zusammengeführt wurde, ohne die Agenten auszubremsen.

Worker Previews erweitern das Branch-Modell über den Code hinaus: Der Aufruf von npx wrangler preview auf einem beliebigen Branch erzeugt eine isolierte Umgebung mit eigener URL und Konfiguration, die eine Basiskonfiguration erbt, die pro Branch überschrieben werden kann. Das schwierigere Problem war der Zustand. Durable Objects verwenden ein Singleton-Modell, bei dem eine Instanz ihren Speicher besitzt; ein Preview, der den Namespace der Produktion teilt, könnte daher durch eine fehlgeschlagene Migration den Live-Traffic verändern. Die Lösung erzeugt pro Preview einen frischen Durable-Object-Namespace, der über ctx.exports aufgelöst wird, sodass identischer Code in der Produktion und in einem Preview unterschiedliche Namespaces erreicht.

Cloudflare hat das Feature selbst auf CloudflareOS eingesetzt, seiner eigenen Open-Source-Plattform, die Agenten über berechtigungsbeschränkte „Gatekeepers“ mit Diensten wie Google, GitHub und Slack arbeiten lässt. Fehler in Gatekeepers, OAuth-Callbacks, Genehmigungsabläufe und schlecht zusammenspielender Berechtigungszustand treten erst zutage, wenn das gesamte System zusammen läuft. Deshalb setzt das Team für jede zu prüfende Änderung einen isolierten Preview von CloudflareOS ein und führt den vollständigen Workflow vor dem Zusammenführen aus.

Git-Branching vom Code auf Umgebung und Zustand ausdehnen

Das automatische Bereitstellen eines neuen Durable-Object-Namespace und einer Container-Anwendung pro Preview schließt den Fehlermodus, in dem ein Preview stillschweigend den Speicher verändern könnte, der den Produktions-Traffic bedient.

Eine wiederverwendbare Basiskonfiguration zu definieren, die Previews erben und pro Branch überschreiben können, vermeidet es, Secrets und Bindings für jeden Branch von Grund auf neu zu konfigurieren, wie es separate Umgebungen erforderten.

Das Dogfooding auf den Gatekeepers von CloudflareOS zielte auf den Fall ab, in dem isolierte Komponententests einen Fehler nicht erkennen können, da der Fehler erst auftritt, wenn OAuth, Berechtigungen und Genehmigungsabläufe zusammen laufen.

Die Observability pro Preview zu begrenzen, ermöglicht es, einen Fehler anhand der eigenen Traces und Logs des jeweiligen Branch zu diagnostizieren, statt dass er mit dem Produktions-Traffic oder anderen laufenden Änderungen vermischt wird.

Wenn „funktioniert im Staging, bricht in der Produktion“ immer wieder auftritt, sollte jede Umgebung so günstig und isoliert bereitstellbar sein wie ein Code-Branch, einschließlich der zustandsbehafteten Teile, die die meisten Tools gemeinsam genutzt lassen.

Cloudflare nennt zum Start verbleibende Lücken: Eine aus einem Preview aufgerufene Service-Binding ruft weiterhin die Produktionsbereitstellung des gebundenen Workers auf statt eines passenden Previews; Previews können Nachrichten an Queues senden, aber noch nicht konsumieren; und langlebige Previews für dauerhafte Staging- oder QA-Umgebungen werden noch anhand von Feedback aus der privaten Beta abgesteckt. Worker Previews sind jetzt auf der gesamten Workers-Plattform verfügbar, wobei die älteren Version-URLs als separater, engerer Mechanismus zum Verweisen auf bestimmte hochgeladene Versionen erhalten bleiben.