Нет ничего хуже, чем тестировать изменение, которое отлично работает на этапе staging, и видеть, как оно ведет себя совершенно иначе в продакшене. Именно поэтому мы хотели предоставить вам среду, максимально приближенную к продакшену, чтобы вы могли провести стресс-тестирование своих изменений и убедиться, что они работают именно так, как вы ожидаете.
Агенты помогают нам писать больше строк кода, чем когда-либо прежде, а более крупные изменения требуют тщательного тестирования перед релизом. В идеале такое тестирование должно проводиться так, чтобы не замедлять работу агентов, но при этом предоставлять им инструменты для охвата большей части жизненного цикла разработки.
Именно поэтому сегодня мы запускаем Worker Previews. Каждая ветка Git получает среду, аналогичную продакшену, со своим собственным кодом, конфигурацией, URL, средствами наблюдаемости и состоянием.
Теперь для каждого изменения в вашей кодовой базе вы можете:
- Развернуть изолированный Превью с помощью npx wrangler preview, используя собственные переменные, секреты и биндинги, отдельно от конфигурации и трафика продакшена.
- Изолировать Durable Objects и Containers для каждой ветки, сохраняя изменения состояния, сессии, память, миграции и параллельные тесты в рамках этого Превью.
- Просматривать логи, ошибки, метрики и трассировки для этого Превью, чтобы убедиться в работоспособности изменения, перехватывать сбои, вносить исправления и проверять их до того, как они попадут в продакшен.
- Начинать с заданной вами конфигурации Превью, чтобы каждый Превью запускался с копией определенных вами переменных, секретов, биндингов и настроек — точно так же, как ветка кода создается из main. Мы называем это базовой конфигурацией.
- Переопределять конфигурацию Превью при необходимости, например, указывая ее на собственную базу данных или тестовый ключ API для миграций — без изменения продакшена, базы или конфигурации других Превью.
- Обслуживать URL Превью на собственном домене, чтобы провайдеры аутентификации, файлы cookie, общий доступ к ресурсам разных источников (CORS) и перенаправления OAuth работали так же, как в продакшене.
Результатом является цикл обратной связи до этапа продакшена для каждой ветки. Отправьте изменения в ветку, протестируйте поведение, проверьте производительность — перед слиянием в продакшен.
Это открывает возможности для Жизненного цикла разработки агентов (ADLC), где каждое изменение является атомарным, независимо развертываемым, наблюдаемым и дорабатываемым. Это дает агентам и людям необходимую доказательную базу для самосовершенствования: обнаружить сбой, отправить исправление и проверить следующий деплой до того, как он попадет в продакшен.
Каждая ветка Git получает собственную среду
Когда вы начинаете работу над новой функцией, первое, что вы делаете — создаете ветку от main. Вы получаете собственную копию кода и вносите изменения, не затрагивая ничего в продакшене.
Worker Previews переносят эту модель за пределы кода. Каждая ветка получает собственную изолированную среду и URL. Вы можете запускать сотни Превью одновременно — каждое работает независимо, не влияя на другие Превью или продакшен.
Продакшен и каждый Превью имеют собственную конфигурацию, доступную по собственному URL.
Когда вы запускаете npx wrangler preview, ветка получает собственную копию определенной вами конфигурации Превью, работающую по собственному URL — и все это в рамках одного Worker.
В панели управления это работает как переключение веток. Нажмите на путь навигации рядом с именем вашего Worker (по умолчанию это Production), чтобы увидеть все ваши Превью:
Панель управления объединяет все среды в едином представлении. Продакшен соседствует со сколь угодно большим количеством Превью, поэтому разработчики могут работать над отдельными изменениями, не конфликтуя из-за общей среды staging. В отличие от сред Wrangler, где каждая среда требует деплоя и управления отдельным Worker, Превью сохраняют эту изоляцию в рамках одного представления панели управления.
Каждый Превью работает как реальная версия вашего Worker. Некоторые изменения можно проверить только во время выполнения: конечная точка API должна обработать реальный запрос и вернуть правильный ответ. Более субъективные изменения, такие как обновление пользовательского интерфейса, новый шаг онбординга или другое состояние ошибки, необходимо прочувствовать в контексте до того, как они попадут в продакшен.
Каждый Превью имеет свое изолированное и постоянное состояние благодаря Durable Objects и Containers
Чтобы изоляция распространялась на все приложение, ресурсы с состоянием требуют особого подхода. Причина в том, что Durable Objects работают по модели синглтона. За определенный идентификатор объекта отвечает единственный экземпляр, и этот экземпляр владеет своим хранилищем.
Если бы Превью разделяло то же пространство имен DO с продакшеном, вы бы не просто читали устаревшие данные — вы могли бы в реальном времени изменять тот же экземпляр, который обслуживает живой трафик (звучит пугающе!).
Именно поэтому каждый раз, когда вы запускаете npx wrangler preview, Cloudflare автоматически создает новое пространство имен Durable Object и приложение Container для этого Превью — так что неудачная миграция или неудачное изменение схемы остаются изолированными в рамках только этой конкретной ветки.
Все, что вам нужно сделать, это экспортировать класс, добавить его миграцию и получить к нему доступ через ctx.exports:
В продакшене ctx.exports.Counter разрешается в пространство имен продакшена, в то время как в Превью оно разрешается в пространство имен этого Превью.
Теперь у вас есть целая песочница для экспериментов. Возьмем, к примеру, Песочницы (Sandboxes), где миллисекунды улучшения времени запуска могут иметь решающее значение для пользовательского опыта. Если вы пытаетесь улучшить производительность холодного старта, вы можете одновременно запускать различные конфигурации в разных ветках, сравнивать их производительность при холодном и теплом старте бок о бок и быстрее находить лучшую настройку.
Тестируйте, наблюдайте и дорабатывайте каждый Превью (или поручите это своему агенту)
Теперь, когда каждая ветка работает по собственному URL в изолированной среде с собственным состоянием, вы можете войти в цикл обратной связи и начать стресс-тестирование каждого изменения до его попадания в продакшен.
Вы можете отправлять трафик на URL Превью привычным способом — из терминала, с помощью CI-пробы, от агента или кликая по нему самостоятельно. Как только трафик начинает поступать, все привычные инструменты Workers Observability становятся доступны для каждого отдельного Превью.
По мере того как каждый запрос попадает в Превью, Workers Observability отслеживает его полный жизненный цикл в виде «водопада», включая fetch-вызовы, операции с биндингами и вызовы обработчиков. Поэтому, когда что-то идет не так, вы можете точно проследить последовательность событий, не разбираясь в трафике продакшена или сигналах от других изменений.
Система наблюдаемости для Превью выглядит так же, как вы привыкли видеть для продакшен-воркеров. Выберите ваш Превью в пути навигации и откройте вкладку Observability, чтобы просмотреть его события, ошибки и трассировки:
Чтобы дать вашим агентам еще больше контроля, вы можете заставить их открыть URL Превью в браузере без графического интерфейса (headless), пошагово пройти процесс входа и сделать снимок экрана или записать всю сессию в виде воспроизводимых событий DOM с помощью Browser Run.
Ниже приведен пример, где агент открывает Превью, фиксирует отрендеренное изображение и связывает сбойный запрос с событиями Workers Observability из того же запуска.
Рецензент может наблюдать за сессией в реальном времени с помощью Live View или вмешаться с помощью Human in the Loop, когда автоматике требуется экспертная оценка.
Если что-то идет не так, вы видите это с двух сторон: что было отрисовано и что произошло во время выполнения.
Это дает агенту достаточно данных для автономной работы цикла предпроизводственной подготовки: развертывание, открытие URL-адреса с помощью Playwright MCP, переход по ссылкам, запрос трассировок через Workers Observability MCP server, исправление, повторное развертывание и проверка. Каждая итерация остается в рамках ветки.
Настройте базовую конфигурацию для Previews один раз, а затем переопределяйте ее по мере необходимости
Точно так же, как вы не перенастраиваете свой код с нуля при каждом создании ветки, вам не придется перенастраивать и свое окружение.
Вы устанавливаете базовую конфигурацию для Previews один раз в блоке previews в вашем файле конфигурации Wrangler.
В панели управления в разделе Worker → Settings вы увидите это в виде Production и Previews Base. После установки базы выполните команду npx wrangler preview из любой ветки, чтобы создать Preview. Если ваш Worker подключен к Git через Workers Builds, это происходит автоматически при пуше.
Вы можете переопределить любую настройку только для одного Preview — не затрагивая продакшн, базу или другие Previews.
URL-адреса Preview на вашем собственном домене, защищенные с помощью Cloudflare Access
Чтобы сделать всю настройку еще ближе к продакшну, ваши URL-адреса Preview могут обслуживаться на вашем собственном пользовательском домене. Если ваше приложение работает на example.com, Preview для ветки login может работать на feature-login.previews.example.com.
Если вы хотите сохранить эти URL-адреса приватными, вы можете защитить свои Previews с помощью Cloudflare Access и требовать от посетителей предварительного входа в систему.
Тестирование всей системы перед выпуском в продакшн
Мы уже используем Worker Previews внутри Cloudflare в рамках «dogfooding», в частности для создания и тестирования CloudflareOS, нашей платформы с открытым исходным кодом для безопасного подключения агентов к корпоративным системам.
CloudflareOS позволяет агентам работать с такими сервисами, как Google, GitHub и Slack через , которые контролируют, к чему эти агенты могут иметь доступ и что могут изменять. Это делает изменения в Gatekeeper особенно чувствительными, поскольку ошибка может привести к раскрытию данных или разрешить действие, которое никогда не должно было быть разрешено.
Некоторые из этих ошибок проявляются только тогда, когда обратные вызовы OAuth, разрешения, процессы утверждения и состояние приложения работают вместе. Поскольку тестирование каждого компонента в отдельности не может показать нам, как будет вести себя вся система, мы развертываем изолированный Preview CloudflareOS и его Gatekeepers для каждого изменения, находящегося на рассмотрении. Затем мы запускаем полный рабочий процесс, исправляем ошибки и тестируем снова перед слиянием.
Мы видим, что клиенты используют Previews по той же причине: некоторые проблемы проявляются только тогда, когда изменения запущены в реальности.
"В Supermemory мы активно используем Cloudflare, и Worker Previews — это именно то улучшение опыта разработчиков, которое мы хотели видеть. Для HTTP-потоков мы можем просматривать изменения Worker до того, как они попадут в продакшн, включая маршруты, поддерживаемые Durable Objects, и выявлять проблемы раньше, не замедляя процесс выпуска." — Дравья Шах, основатель Supermemory"Previews — это потрясающе для Inspect [агент кодинга Ramp]. Я использовал его для проверки и тестирования PR в Inspect на своем телефоне, что делает проверку и тестирование PR с помощью Inspect на телефонах адаптивными... с помощью Inspect." — Дилан Гарсия, старший штатный инженер Ramp
"В Supermemory мы активно используем Cloudflare, и Worker Previews — это именно то улучшение опыта разработчиков, которое мы хотели видеть. Для HTTP-потоков мы можем просматривать изменения Worker до того, как они попадут в продакшн, включая маршруты, поддерживаемые Durable Objects, и выявлять проблемы раньше, не замедляя процесс выпуска." — Дравья Шах, основатель Supermemory
"Previews — это потрясающе для Inspect [агент кодинга Ramp]. Я использовал его для проверки и тестирования PR в Inspect на своем телефоне, что делает проверку и тестирование PR с помощью Inspect на телефонах адаптивными... с помощью Inspect." — Дилан Гарсия, старший штатный инженер Ramp
Что дальше?
Вы можете подумать: разве у Workers уже не было URL-адресов предварительного просмотра? Это правда, были. Теперь мы называем их Version URLs, потому что они указывают на конкретные загруженные версии Worker. В отличие от Worker Previews, они не создают изолированную среду для каждой ветки и могут указывать только на ресурсы продакшна. Чтобы узнать больше и сравнить различные рабочие процессы, ознакомьтесь с нашей документацией.
Worker Previews — это значительное улучшение по сравнению с тем, что мы предлагали раньше, но это еще не все. Вот над чем мы работаем дальше:
- Предварительный просмотр приложений с несколькими Worker. Сегодня service binding из Preview по-прежнему вызывает продакшн-развертывание привязанного Worker. Мы работаем над тем, чтобы весь путь запроса оставался внутри соответствующих Previews.
- Запуск потребителей Queue и Workflows внутри каждого Preview. Сегодня Previews могут отправлять сообщения в Queues, но не могут их потреблять, а изоляция выполнений Workflow требует отдельной настройки. Мы хотим, чтобы весь асинхронный поток автоматически ограничивался рамками ветки.
- Поддержка долгоживущих Previews для стейджинга и QA. Мы слышали от команд, участвовавших в закрытом бета-тестировании, что не каждая ветка является кратковременной — некоторые поддерживают среды стейджинга, QA или среды для отдельных разработчиков, которые сохраняются на протяжении нескольких спринтов. Мы хотим поддерживать их сквозным образом и хотим услышать, как вы их используете, чтобы сделать все правильно.
Worker Previews уже доступны. Начните работу с docs, и если у вас есть запрос на новую функцию или вы столкнулись с проблемой, создайте тикет на GitHub или присоединяйтесь к сообществу Cloudflare Developers в Discord.
Благодарности: Этот проект стал возможен благодаря усилиям по проектированию и реализации Грега Бримбла, Патрика О’Доннелла, Мэтта Прайса, Коринн Алперс, Макса Петерсона, Сины Саффари, Джоша Уиллера, Томаса Анккорна, Мэтта Ротенберга и Брэндона Стриттматтера под руководством Брендана Ирвин-Брока и Дэна Картера.
