Cloudflare dio a cada rama de Git su propio entorno aislado similar al de producción

Cloudflare Workers ya contaba con URL de versión para versiones específicas subidas, pero solo podían apuntar a recursos de producción y no creaban un entorno aislado por cambio, de modo que probar un cambio grande de forma segura implicaba arriesgar el estado compartido de staging o levantar un Worker separado por entorno. A medida que el desarrollo asistido por agentes empujaba más y mayores cambios por el pipeline, era necesario realizar más pruebas antes de la fusión, sin ralentizar a los agentes.

Worker Previews extiende el modelo de ramas más allá del código: ejecutar npx wrangler preview en cualquier rama crea un entorno aislado con su propia URL y configuración, que hereda una configuración base que puede sobrescribirse por rama. El problema más difícil era el estado. Los Durable Objects usan un modelo singleton en el que una instancia es dueña de su almacenamiento, por lo que una Preview que compartiera el espacio de nombres de producción podría permitir que una migración fallida modificara el tráfico en vivo. La solución crea un espacio de nombres de Durable Object nuevo por cada Preview, resuelto mediante ctx.exports para que el mismo código llegue a espacios de nombres distintos en producción frente a una Preview.

Cloudflare probó la función internamente (dogfooding) en CloudflareOS, su propia plataforma de código abierto que permite a los agentes trabajar con servicios como Google, GitHub y Slack a través de 'Gatekeepers' con permisos delimitados. Los errores de Gatekeeper, las devoluciones de llamada de OAuth, los flujos de aprobación y el estado de permisos que interactúa mal solo salen a la luz cuando el sistema completo se ejecuta en conjunto, por lo que el equipo despliega una Preview aislada de CloudflareOS para cada cambio en revisión, ejecutando el flujo de trabajo completo antes de fusionar.

Extender la ramificación de git del código al entorno y al estado

Aprovisionar automáticamente un nuevo espacio de nombres de Durable Object y una aplicación de Container por cada Preview cierra el modo de fallo en el que una Preview podía modificar silenciosamente el almacenamiento que atiende el tráfico de producción.

Definir una configuración base reutilizable que las Previews heredan, con sobrescrituras por rama, evita reconfigurar secretos y bindings desde cero para cada rama, como requerían los entornos separados.

El dogfooding en los Gatekeepers de CloudflareOS apuntó al caso en el que las pruebas aisladas de componentes no pueden detectar un error, ya que el error solo aparece cuando OAuth, los permisos y los flujos de aprobación se ejecutan juntos.

Delimitar la observabilidad por Preview permite diagnosticar un fallo a partir de las trazas y los registros de esa propia rama, en lugar de mezclarlo con el tráfico de producción u otros cambios en curso.

Cuando 'funciona en staging, falla en producción' se repite, haga que cada entorno sea tan barato y aislado de aprovisionar como una rama de código, incluidas las partes con estado que la mayoría de las herramientas deja compartidas.

Cloudflare enumera las brechas restantes al momento del lanzamiento: un binding de servicio invocado desde una Preview sigue llamando al despliegue de producción del Worker vinculado en lugar de a una Preview correspondiente, las Previews pueden enviar mensajes a Queues pero aún no consumirlos, y las Previews de larga duración para entornos persistentes de staging o QA todavía se están definiendo en función de los comentarios de la beta privada. Worker Previews está disponible ahora en toda la plataforma de Workers, y las antiguas URL de versión se mantienen como un mecanismo separado y más limitado para apuntar a versiones específicas subidas.