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

Превью-окружения: как проверять ветку, не ломая продакшн

Есть один сценарий, который повторяется в каждой команде. Разработчик доделал фичу, надо показать её заказчику. Вариантов ровно два: выкатить на боевой сайт и надеяться, либо слать скриншоты и объяснять словами, что там на самом деле происходит при клике.

Оба плохие. Первый — потому что боевой сайт перестаёт быть боевым, он становится стендом. Второй — потому что заказчик по скриншотам не поймёт ничего и всё равно попросит «дать посмотреть».

Превью-окружения решают именно это.

Что это такое

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

Выглядит это так: у проекта myapp с боевым доменом myapp.ru появляется адрес вида myapp-git-feature-checkout.preview.relaxdev.ru, где живёт ветка feature/checkout. Обычная ссылка, обычный HTTPS. Её можно отправить кому угодно, доступ в панель для этого не нужен.

Чем это отличается от staging

Staging обычно один. Он общий, за него дерутся, на нём всегда лежит чья-то недоделанная ветка, и «а можно я на пять минут задеплою» — это отдельный жанр переписки в рабочем чате.

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

Второе отличие: staging надо поддерживать. Кто-то должен следить, чтобы он не разошёлся с продакшном по версиям, переменным и конфигурации. Превью собирается тем же билдером и из тех же настроек, что и боевой деплой, поэтому расходиться ему особо негде.

Главная ловушка: общая база данных

Тут начинается самое интересное, и это та часть, которую в статьях про превью обычно проговаривают вскользь.

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

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

Поэтому в RelaxDev режим базы для превью переключается явно, и мы советуем режим «своя база, только схема». В нём для превью создаётся отдельная база со структурой продакшна, но без единой записи. Приложение при старте накатывает миграции и сиды само — так, как оно это делает на чистой машине разработчика. Боевые данные при этом физически недостижимы.

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

Когда превью удаляется, его база удаляется вместе с ним. Отдельно прибираться не нужно.

Переменные окружения

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

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

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

Отдельная деталь, которая экономит нервы: если в продакшн добавилась переменная, которой нет в превью, панель это показывает и предлагает дописать её одной кнопкой. Иначе списки расходятся незаметно, и превью падает на пустом process.env через две недели после того, как кто-то добавил ключ.

Уборка

Забытые стенды — отдельная беда. Их создают, смотрят один раз и не удаляют, а они продолжают занимать память и диск.

Поэтому превью живёт 72 часа. Отсчёт обновляется при каждой пересборке: пока над веткой работают, окружение не денется никуда. Как только работа остановилась — контейнер, образ и база удаляются автоматически. Удалить раньше можно кнопкой.

Ещё пара мелочей, которые оказались полезными

Старая версия отдельным превью. В истории деплоев у каждой записи есть кнопка, поднимающая этот коммит как превью. Это удобнее отката: сначала смотрите старую версию на отдельном адресе, сравниваете, потом решаете, возвращаться ли. Продакшн всё это время работает.

Слияние из панели. Проверили ветку — сливаете её в продакшн, не переходя в интерфейс Git-провайдера. Перед слиянием видно, сколько коммитов впереди и сколько файлов затронуто. Дальше срабатывает обычный автодеплой.

**Закрыто от поиска.** Все превью-адреса отдаются с noindex. Дублей вашего сайта в выдаче не появится — иначе поисковик рано или поздно найдёт стенд и начнёт показывать его вместо основного домена.

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

Чего превью не умеют

Telegram-ботов превью не поднимают, и это осознанно: два экземпляра бота с одним токеном начинают драться за получение обновлений, и работающий бот ломается. Для ботов нужен отдельный токен на каждую среду — пока это делается руками.

Слияние веток из панели работает для GitHub. Сами превью создаются из GitHub, GitLab, GitVerse и GitFlic одинаково, а вот для слияния у остальных провайдеров пока используется их собственный интерфейс.

Как попробовать

Откройте вкладку «Окружения» в любом проекте, развёрнутом из Git, выберите ветку и нажмите «Создать». Через одну-три минуты адрес будет готов.

Превью доступны на всех тарифах, включая бесплатный.

Подробности в документации, вопросы и пожелания — на форуме.