Preview Environments

Code review по скриншотам

Стандартный процесс code review в большинстве команд выглядит так: разработчик открывает pull request, ревьюер читает diff, пытается мысленно представить, как эти изменения будут работать, оставляет комментарии, и через пару итераций PR мёрджится. Проблема в том, что чтение diff — это анализ кода в вакууме: ревьюер видит строки, но не видит результат. Для бэкенда это ещё терпимо — можно проверить логику по коду. Но для фронтенда, изменений в API, миграций базы данных или интеграций между сервисами — чтение diff не даёт полной картины.

Некоторые команды пытаются решить проблему скриншотами: разработчик делает скриншот того, как выглядит новый UI, и прикладывает к PR. Но скриншот не интерактивен — на нём не видно, как работает анимация, что происходит при ресайзе окна, как ведёт себя форма при невалидном вводе. Другие команды просят ревьюера чекаутить ветку и запускать проект локально, но на это уходит время, конфигурация окружения может отличаться, и половина ревьюеров честно признается, что пропускает этот шаг.

Что такое preview environments

Preview environment (он же ephemeral environment, deploy preview, review app) — это полноценное изолированное окружение приложения, которое автоматически создаётся для каждого pull request. Когда разработчик пушит изменения в ветку и открывает PR, CI/CD-пайплайн разворачивает приложение с этими изменениями на отдельном URL — например, pr-142.preview.yourapp.dev — и ссылка появляется прямо в PR.

Preview environments также ускоряют онбординг: новый разработчик может увидеть результат своего первого PR в работающем окружении, а не только в diff. Жизненный цикл preview environment привязан к PR: окружение создаётся при открытии PR, обновляется при каждом пуше в ветку, и уничтожается при мёрдже или закрытии PR. Это эфемерная инфраструктура — она не стоит денег, когда не используется, и не требует ручного управления.

Как это меняет процесс ревью

Ревьюер открывает PR, видит ссылку на preview, кликает — и перед ним работающее приложение с изменениями автора. Для фронтенда это означает, что ревьюер может проверить UI на разных разрешениях, протестировать пользовательские сценарии, найти баги, которые невидимы в diff. Для бэкенда — вы можете отправить реальный запрос к API и посмотреть ответ, проверить, что миграция отработала корректно, убедиться, что новый endpoint возвращает правильный формат.

Product-менеджеры и дизайнеры получают доступ к изменениям ещё до мёрджа — они могут дать фидбек по UX, словить несоответствие макету, предложить правки, пока код ещё свежий в голове разработчика. QA-инженеры могут начинать тестирование параллельно с code review, а не ждать деплоя в staging. Это сдвигает обнаружение багов влево по pipeline и сокращает цикл обратной связи с дней до часов.

Инструменты

Инструменты для preview environments делятся на три категории в зависимости от типа приложения и инфраструктуры.

Для фронтенда и статических сайтов самый простой путь — Vercel и Netlify. Обе платформы дают preview deployments из коробки: подключаете Git-репозиторий, и каждый PR получает preview URL без настройки CI/CD. Vercel особенно хорош для Next.js, Netlify — для static-first приложений. Cloudflare Pages предлагает аналогичную функциональность для приложений на Workers.

Для Kubernetes-based инфраструктуры основной инструмент — Argo CD с Pull Request Generator из ApplicationSet controller. При появлении нового PR Argo CD создаёт Application, разворачивает код из ветки PR в отдельный namespace, а при закрытии PR — автоматически удаляет Application и чистит ресурсы. Этот подход требует больше настройки, но даёт полный контроль над инфраструктурой и работает для любых приложений, не ограничиваясь фронтендом.

Специализированные платформы — Bunnyshell, Okteto, Qovery, Northflank — предоставляют preview environments как сервис. Okteto, например, разворачивает per-branch окружения с namespace isolation в Kubernetes, включая базы данных и очереди. Bunnyshell поддерживает Docker Compose и Kubernetes и создаёт полную копию окружения для каждого PR. Эти инструменты снижают порог входа, но добавляют зависимость от внешнего сервиса.

Базы данных и состояние

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

Три подхода к решению. Первый — разделяемый staging-бэкенд: preview environment фронтенда подключается к общему staging API. Это работает для UI-изменений, но не помогает при изменениях в бэкенде или базе данных. Второй — snapshot базы данных: при создании preview environment CI копирует структуру и тестовые данные из seed-файла или снапшота. Neon (serverless Postgres) позволяет создавать ветки базы данных за секунды — каждый PR получает свою копию БД с данными из main. Третий — полная изоляция через контейнеры: каждый preview environment включает все зависимости в Docker Compose или Kubernetes pod, что даёт максимальную независимость, но увеличивает стоимость и время создания окружения.

Trade-offs

Стоимость инфраструктуры. Каждый preview environment — это вычислительные ресурсы. При активной разработке с десятками открытых PR счёт за инфраструктуру может вырасти. Mitigation: автоматическое выключение окружений, которые не использовались более часа, использование spot-инстансов, лимит на количество одновременных preview environments.

Время создания. Если разворачивание preview environment занимает 20 минут, разработчики будут ждать и терять контекст. Цель — уложиться в 2–5 минут для фронтенда и 5–10 минут для full-stack окружений. Кэширование Docker-образов, pre-built базовые образы и параллелизация шагов пайплайна помогают уложиться в эти рамки.

Безопасность данных. Preview environments не должны содержать production-данные — используйте синтетические данные или анонимизированные снапшоты. Доступ к preview URL стоит ограничить аутентификацией, чтобы случайный человек с ссылкой не видел вашу внутреннюю разработку.

С чего начать

Если у вас фронтенд на современном фреймворке — Vercel или Netlify дадут preview environments за десять минут настройки. Если у вас Kubernetes — начните с Argo CD ApplicationSet и Pull Request Generator. В обоих случаях первый эффект вы увидите сразу: ревьюеры начнут находить баги, которые раньше доживали до staging, а product-менеджеры перестанут спрашивать «можно посмотреть на это до релиза?» — ответ будет ссылкой в PR.