A Cloudflare deu a cada branch do Git seu próprio ambiente isolado semelhante ao de produção

O Cloudflare Workers já tinha URLs de Versão para versões específicas enviadas, mas elas só podiam apontar para recursos de produção e não criavam um ambiente isolado por mudança, então testar uma mudança maior com segurança significava arriscar o estado compartilhado de staging ou levantar um Worker separado por ambiente. À medida que o desenvolvimento assistido por agentes empurrava mais e maiores mudanças pelo pipeline, mais testes precisavam acontecer antes do merge, sem desacelerar os agentes.

O Worker Previews estende o modelo de branch além do código: executar npx wrangler preview em qualquer branch cria um ambiente isolado com sua própria URL e configuração, herdando uma configuração base que pode ser sobrescrita por branch. O problema mais difícil era o estado. Os Durable Objects usam um modelo singleton em que uma instância é dona de seu armazenamento, então um Preview que compartilhasse o namespace de produção poderia permitir que uma migração com falha modificasse o tráfego ao vivo. A correção cria um namespace de Durable Object novo por Preview, resolvido por meio de ctx.exports para que o mesmo código alcance namespaces diferentes em produção versus em um Preview.

A Cloudflare usou o recurso internamente no CloudflareOS, sua própria plataforma de código aberto que permite a agentes trabalhar com serviços como Google, GitHub e Slack por meio de "Gatekeepers" com escopo de permissão. Bugs de Gatekeeper, callbacks de OAuth, fluxos de aprovação e estado de permissão interagindo mal só aparecem quando o sistema completo roda junto, então a equipe implanta um Preview isolado do CloudflareOS para cada mudança em revisão, executando o fluxo de trabalho completo antes do merge.

Estender a ramificação do git do código para o ambiente e o estado

Provisionar automaticamente um novo namespace de Durable Object e uma aplicação Container por Preview fecha o modo de falha em que um Preview poderia alterar silenciosamente o armazenamento que atende o tráfego de produção.

Definir uma configuração base reutilizável que os Previews herdam, com sobrescritas por branch, evita reconfigurar segredos e bindings do zero para cada branch, como os ambientes separados exigiam.

O uso interno nos Gatekeepers do CloudflareOS mirou o caso em que testes isolados de componentes não conseguem capturar um bug, já que o bug só aparece quando OAuth, permissões e fluxos de aprovação rodam juntos.

Delimitar a observabilidade por Preview permite diagnosticar uma falha a partir dos traces e logs daquele próprio branch, em vez de misturá-la ao tráfego de produção ou a outras mudanças em andamento.

Quando "funciona no staging, quebra em produção" continua se repetindo, torne cada ambiente tão barato e isolado de provisionar quanto um branch de código, incluindo as partes com estado que a maioria das ferramentas deixa compartilhadas.

A Cloudflare lista lacunas remanescentes no lançamento: um service binding chamado a partir de um Preview ainda chama a implantação de produção do Worker vinculado, em vez de um Preview correspondente; os Previews podem enviar mensagens para Queues, mas ainda não consumi-las; e Previews de longa duração para ambientes persistentes de staging ou QA ainda estão sendo definidos com base no feedback do beta privado. O Worker Previews está disponível agora em toda a plataforma Workers, com as URLs de Versão mais antigas mantidas como um mecanismo separado e mais restrito para apontar para versões específicas enviadas.