Нет ничего хуже, чем тестировать изменения, которые отлично работают на стейджинге, но ведут себя иначе в продакшне. Именно поэтому мы хотели предоставить вам среду, максимально приближенную к продакшну, чтобы вы могли проводить боевое тестирование изменений и быть уверенными в их точном соответствии ожиданиям.

Агенты помогают нам писать больше строк кода, чем когда-либо прежде, а более масштабные изменения требуют тщательного тестирования перед релизом. В идеале такое тестирование не должно замедлять агентов, а наоборот — давать им инструменты для охвата большей части жизненного цикла разработки.

Именно поэтому сегодня мы запускаем Worker Previews. Каждая ветка Git получает среду, подобную продакшну, со своим собственным кодом, конфигурацией, URL-адресом, средствами наблюдаемости и состоянием.

Таким образом, теперь для каждого изменения в вашей кодовой базе вы можете:

Развернуть изолированный Preview с помощью npx wrangler preview, используя собственные переменные, секреты и привязки, отдельно от конфигурации и трафика продакшна.

Поделиться стабильным URL-адресом Preview для ветки, чтобы каждый пуш обновлял один и тот же запущенный Preview, куда можно отправлять запросы, взаимодействовать с интерфейсом и тестировать ответы во время выполнения.

Изолировать Durable Objects и Container для каждой ветки, сохраняя изменения состояния, сеансы, память, миграции и параллельные тесты в рамках этого Preview.

Просматривать логи, ошибки, метрики и трейсы для этого Preview, чтобы убедиться в работоспособности изменений, перехватывать сбои, отправлять исправления и проверять их до того, как они попадут в продакшн.

Начинать с заданной конфигурации Preview, чтобы каждый Preview создавался на основе определенного вами набора переменных, секретов, привязок и настроек — точно так же, как ветка кода создается на основе main. Мы называем это базовой конфигурацией.

Переопределять конфигурацию Preview при необходимости (например, направляя ее на собственную базу данных или тестовый ключ API для миграций) без изменения продакшна, базовой конфигурации или настроек других Preview.

Обслуживать URL-адреса Preview в собственном домене, чтобы провайдеры аутентификации, куки, совместное использование ресурсов между источниками (CORS) и перенаправления OAuth работали так же, как и в продакшне.

Результатом является цикл обратной связи перед продакшном для каждой ветки. Отправляйте изменения в ветку, тестируйте поведение и оценивайте производительность перед слиянием с продакшном.

Это делает возможным Жизненный цикл разработки с участием агентов (ADLC), при котором каждое изменение является атомарным, независимо развертываемым, наблюдаемым и проверяемым. Это дает агентам и людям данные, необходимые для самосовершенствования: обнаружение сбоев, отправку исправлений и проверку следующего развертывания до его попадания в продакшн.

Каждая ветка Git получает собственную среду

Когда вы начинаете работу над новой функцией, первое, что вы делаете — ответвляетесь от main. Вы получаете собственную копию кода и вносите изменения, не затрагивая ничего в продакшне.

Worker Previews переносят эту модель за пределы кода. Каждая ветка получает изолированную среду и URL-адрес. Вы можете запускать сотни Preview одновременно — каждое из них работает независимо, не влияя на другие Preview или продакшн.

Продакшн и каждый Preview имеют собственную конфигурацию, обслуживаемую по собственному URL-адресу.

Когда вы запускаете npx wrangler preview, ветка получает собственную копию определенной вами конфигурации Preview, работающую по собственному URL-адресу — и все это в рамках одного Worker.

В панели управления это работает так же, как переключение веток. Нажмите на путь навигации рядом с именем вашего Worker (по умолчанию это Production), чтобы увидеть все ваши Preview:

Панель управления объединяет все среды в едином представлении. Продакшн соседствует с любым необходимым количеством Preview, поэтому разработчики могут работать над независимыми изменениями, не конфликтуя из-за общего сайта стейджинга. В отличие от сред Wrangler, где каждая среда требует развертывания и управления отдельным Worker, Previews сохраняют эту изоляцию в рамках одного представления панели управления.

Каждый Preview работает как реальная версия вашего Worker. Некоторые изменения могут быть проверены только во время выполнения: конечная точка API должна обработать реальный запрос и вернуть правильный ответ. Более субъективные изменения, такие как обновление интерфейса, новый шаг онбординга или другое состояние ошибки, необходимо прочувствовать в контексте до того, как они попадут в продакшн.

Каждый Preview имеет собственное изолированное и постоянное состояние благодаря Durable Objects и Containers

Чтобы изоляция распространялась на все ваше приложение, ресурсы с состоянием требуют особого подхода. Причина в том, что Durable Objects работают по модели синглтона. За конкретный ID объекта отвечает один экземпляр, и этот экземпляр владеет своим хранилищем.

Если бы Preview разделял то же пространство имен DO с продакшном, вы бы не просто читали устаревшие данные — вы могли бы модифицировать тот же экземпляр, который обслуживает реальный трафик в режиме реального времени (что довольно опасно!).

Именно поэтому каждый раз, когда вы запускаете npx wrangler preview, Cloudflare автоматически создает новое пространство имен Durable Object и приложение Container для этого Preview, чтобы неудачная миграция или неверное изменение схемы оставались локализованными исключительно в пределах этой ветки.

Все, что вам нужно сделать — экспортировать класс, добавить его миграцию и получить к нему доступ через ctx.exports:

В продакшне ctx.exports.Counter ссылается на пространство имен продакшна, в то время как в Preview он ссылается на пространство имен этого Preview.

Теперь в вашем распоряжении целая песочница для экспериментов. Возьмем, к примеру, песочницы (Sandboxes), где миллисекунды улучшения времени запуска могут иметь решающее значение для пользовательского опыта. Если вы пытаетесь улучшить производительность «холодного» старта, вы можете одновременно запускать разные конфигурации по веткам, сравнивать их производительность в «холодном» и «горячем» состояниях бок о бок и быстрее находить оптимальную настройку.

Тестируйте, наблюдайте и проверяйте каждый Preview (или поручите это своему агенту)

Теперь, когда каждая ветка работает по собственному URL-адресу в изолированной среде с собственным состоянием, вы можете войти в цикл обратной связи и начать боевое тестирование каждого изменения до его попадания в продакшн.

Вы можете направлять трафик на URL-адрес Preview привычным способом — из терминала, с помощью тестов из CI, агента или переходя по ссылкам самостоятельно. Как только трафик начинает поступать, все инструменты Workers Observability, к которым вы привыкли, становятся доступны для каждого отдельного Preview.

По мере поступления каждого запроса в Preview, инструмент Workers Observability отслеживает его полный жизненный цикл в виде «водопада», включая вызовы fetch, операции привязки и вызовы обработчиков. Поэтому, когда что-то идет не так, вы можете точно проследить, что произошло, не просеивая трафик продакшна или сигналы от других изменений.

Наблюдаемость для Preview выглядит точно так же, как вы привыкли видеть для продакшн-воркеров. Выберите свой Preview в навигационной цепочке и откройте вкладку Observability, чтобы просмотреть его события, ошибки и трейсы:

Чтобы предоставить вашим агентам еще больше контроля, вы можете заставить их открыть URL-адрес Preview в безголовом браузере (headless browser), шаг за шагом пройти процесс входа в систему, сделать снимок экрана или записать всю сессию в виде воспроизводимых событий DOM с помощью Browser Run.

Ниже приведен пример, где агент открывает Preview, фиксирует отрисованное содержимое и связывает неудачный запрос с событиями Workers Observability из того же запуска.

Рецензент может наблюдать за сеансом в реальном времени с помощью Live View или вмешаться с помощью механизма Human in the Loop, когда автоматизации требуется экспертная оценка.

Если что-то не удаётся, вы видите это с обеих сторон: что отрисовано и что произошло во время выполнения.

Это даёт агенту достаточно доказательств, чтобы поддерживать цикл предпроизводства автономно: развернуть, открыть URL с помощью Playwright MCP, пройти по ссылкам, запросить трассировки через сервер Workers Observability MCP, исправить, развернуть заново и проверить. Каждый цикл остаётся ограниченным веткой.

Настройте базовую конфигурацию для Предпросмотров один раз, затем переопределяйте по мере необходимости.

Точно так же, как вы не будете перенастраивать свой код с нуля каждый раз, когда создаёте ветку, вам не нужно перенастраивать окружение каждый раз.

Вы задаёте базовую конфигурацию для Предпросмотров один раз, в блоке previews в файле конфигурации Wrangler.

В панели управления под Worker → Settings вы видите это встроенным как Production и Previews Base. После установки базы запустите npx wrangler preview из любой ветки, чтобы создать Предпросмотр. Если ваш Worker подключён к Git через Workers Builds, это происходит автоматически при push.

Вы можете переопределить любое значение только для одного Предпросмотра — без влияния на производство, базу или другие Предпросмотры.

Предпросмотр URL на вашем собственном пользовательском домене, защищённый Cloudflare Access

Чтобы сделать всю настройку ещё ближе к производству, ваши URL Предпросмотра могут обслуживаться с вашего собственного пользовательского домена. Если ваше приложение работает на example.com, Предпросмотр для ветки входа может работать по адресу feature-login.previews.example.com.

Если вы хотите оставить эти URL приватными, вы можете защитить Предпросмотры с помощью Cloudflare Access и потребовать от посетителей сначала войти в систему.

Тестирование всей системы до производства

Мы уже используем Worker Previews внутри Cloudflare, в основном для создания и тестирования CloudflareOS, нашей открытой платформы для безопасного подключения агентов к системам компании.

CloudflareOS позволяет агентам работать с такими сервисами, как Google, GitHub и Slack через Gatekeepers, которые контролируют, к чему эти агенты могут получить доступ и что они могут изменить. Это делает изменения Gatekeeper особенно чувствительными, потому что ошибка может раскрыть данные или позволить действие, которое никогда не должно было быть разрешено.

Некоторые из этих ошибок появляются только тогда, когда OAuth‑обратные вызовы, разрешения, потоки утверждения и состояние приложения работают вместе. Поскольку тестирование каждого компонента отдельно не покажет, как будет вести себя полная система, мы разворачиваем изолированный Предпросмотр CloudflareOS и его Gatekeepers для каждого изменения, находящегося на рассмотрении. Затем мы запускаем полный рабочий процесс, исправляем то, что не проходит, и снова тестируем, прежде чем сливать.

Мы видим, как клиенты используют Предпросмотры по той же основной причине: некоторые проблемы проявляются только тогда, когда изменение действительно работает.

"В Supermemory мы активно используем Cloudflare, и Worker Previews — это именно тот тип улучшения опыта разработчика, который мы хотели увидеть. Для HTTP‑потоков мы можем предварительно просматривать изменения Workers до того, как они попадут в производство, включая маршруты, поддерживаемые Durable Objects, и выявлять проблемы раньше, не замедляя выпуск." — Dhravya Shah, основатель Supermemory"Предпросмотры потрясающие для Inspect [кодировочный агент Ramp]. Я использовал их, чтобы просмотреть и протестировать PR Inspect на своём телефоне, что делает просмотр и тестирование PR с Inspect на телефонах отзывчивыми…с Inspect." — Dylan Garcia, старший инженер Ramp

"В Supermemory мы активно используем Cloudflare, и Worker Previews — это именно тот тип улучшения опыта разработчика, который мы хотели увидеть. Для HTTP‑потоков мы можем предварительно просматривать изменения Workers до того, как они попадут в производство, включая маршруты, поддерживаемые Durable Objects, и выявлять проблемы раньше, не замедляя выпуск." — Dhravya Shah, основатель Supermemory

"Предпросмотры потрясающие для Inspect [кодировочный агент Ramp]. Я использовал их, чтобы просмотреть и протестировать PR Inspect на своём телефоне, что делает просмотр и тестирование PR с Inspect на телефонах отзывчивыми…с Inspect." — Dylan Garcia, старший инженер Ramp

Что дальше?

Вы можете думать: Разве Workers не имели URL‑предпросмотров? Это правда, у нас были. Теперь мы называем их URL‑версий, потому что они указывают на конкретные загруженные версии Workers. В отличие от Worker Previews, они не создают изолированную среду для каждой ветки и могут указывать только на ресурсы производства. Чтобы узнать больше и сравнить различные рабочие процессы, ознакомьтесь с нашей документацией.

Worker Previews — это значительное улучшение по сравнению с тем, что мы предлагали раньше, но ещё многое предстоит. Вот над чем мы работаем дальше:

Предпросмотр многопользовательских приложений. Сегодня привязка сервиса от Предпросмотра всё ещё вызывает развертывание продакшн‑версии привязанного Workers. Мы работаем над тем, чтобы весь путь запроса оставался внутри соответствующих Предпросмотров.

Запуск потребителей очередей и рабочих процессов внутри каждого Предпросмотра. Сегодня Предпросмотры могут отправлять сообщения в очереди, но не могут их потреблять, а изоляция выполнения Workflow требует отдельной конфигурации. Мы хотим, чтобы весь асинхронный поток автоматически ограничивался веткой.

Поддержка долгоживущих Предпросмотров для стенда и QA. Мы слышали от команд в приватном бета‑тестировании, что не каждая ветка коротка — некоторые поддерживают стенд, QA или окружения для каждого разработчика, которые сохраняются между спринтами. Мы хотим поддерживать их полностью, и хотим услышать, как вы их используете, чтобы сделать всё правильно.

Worker Previews доступны сейчас. Начните с документации, и если у вас есть запрос на функцию или возникнут проблемы, откройте issue на GitHub или присоединитесь к сообществу Cloudflare Developers на Discord.

Благодарности: Этот проект стал возможным благодаря усилиям по дизайну и реализации Грега Бримбл, Патрика О’Доннелла, Мэтта Приса, Корины Алперс, Макса Петерсона, Цины Сафари, Джоша Уиллера, Томаса Анккорна, Мэтта Ротенберга и Брендона Стриттмейтера, с руководством Брендона Ирвина-Броке и Дэна Картера.