Как настроить staging-среду для приложения

Чтобы настроить staging-среду, разверните вторую копию приложения по собственному закрытому адресу, дайте ей отдельную базу данных и тестовые API-ключи и сделайте ее настройки максимально похожими на продакшен. Затем выпускайте все значимые изменения сначала на staging, проходите важные сценарии и публикуйте в продакшен, только когда staging работает как надо.

Если вы впервые слышите об этом, сначала прочитайте что такое staging-среда. Это руководство — о практической настройке для тех, кто строит приложения с помощью ИИ-инструментов, а не о работе команды DevOps.

Dev, staging и продакшен

Большинству небольших приложений нужны три среды, даже если первая — это просто предпросмотр в конструкторе:

Смысл staging в том, что он ведет себя как продакшен: тот же код, тот же стек, похожие настройки. Но ошибка там никому не вредит.

Шаг 1. Решите, что staging должен повторять

Staging полезен, только если проблемы проявляются там раньше, чем в продакшене. Сделайте одинаковыми:

• Код, и выпускайте его одинаковым способом.
• Стек и версии: фреймворк, среду выполнения, тип базы данных.
• Тип настроек: одни и те же имена переменных окружения, но с тестовыми значениями.
• Сервисы: если в продакшене есть веб-приложение и API, в staging должны быть оба.

Размер и данные могут отличаться. Машина меньшей мощности подойдет.

Шаг 2. Создайте копию

Самый простой способ: второе развертывание того же проекта по другому адресу, например staging.yourapp.com или yourapp-staging.example.com.

Как это сделать, зависит от хостинга:

• Хостинги со встроенными превью или staging-развертываниями могут создать их автоматически для ветки Git.
• Хостинги без такой функции: создайте второе приложение или проект из того же кода и разверните его отдельно.
• Код в Git: держите ветку staging или main, которая разворачивается на staging, а в продакшен выпускайте из релиза. См. как использовать Git с приложением, созданным ИИ.

Шаг 3. Дайте staging собственную базу данных

Этот шаг вас защищает. Если staging и продакшен используют одну базу, тест, который удаляет записи, удалит настоящие записи.

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

Напиши скрипт наполнения, который заполняет пустую базу реалистичными тестовыми данными: 20 клиентов, 50 заказов в разных статусах и двух администраторов. Используй явно вымышленные имена и адреса на example.com.

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

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

Шаг 4. Используйте тестовые ключи и отдельные настройки

Все, что обращается к внешним сервисам, в staging должно использовать тестовые данные для входа:

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

Имена переменных должны совпадать в обеих средах, меняются только значения. Тогда код не должен знать, где он запущен. Подробнее см. как беречь API-ключи.

Шаг 5. Держите staging закрытым

Staging не должен быть публичным:

• Закройте его логином, паролем или списком разрешенных адресов команды.
• Запретите поисковикам индексировать его тегом noindex или заголовком X-Robots-Tag.
• Не ставьте на него ссылок с публичного сайта.
• Сделайте его визуально отличным: яркий баннер «STAGING» не даст перепутать вкладки с тестами.

Добавь яркий желтый баннер вверху каждой страницы с текстом «STAGING — только тестовые данные», если переменная окружения APP_ENV равна «staging». В этом случае также добавь мета-тег noindex.

Шаг 6. Установите порядок выпуска

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

1. Внесите изменение в разработке и проверьте его в превью.
2. Выпустите его на staging.
3. Пройдите ключевые сценарии: регистрация, вход, основная функция, платежи, всё, что затронуло изменение.
4. Если что-то сломалось, исправьте и снова выпустите на staging.
5. Опубликуйте ту же версию в продакшен.
6. Быстро проверьте продакшен: те же сценарии, но коротко.

Запишите ключевые сценарии в короткий тестовый список. Что включить, см. в как протестировать приложение перед запуском.

Шаг 7. Аккуратно меняйте структуру базы

Изменения структуры базы данных — добавление колонки, переименование таблицы — как раз то, ради чего нужен staging.

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

Примеры промптов

Объясни, что произойдет с существующими данными, если выполнить это изменение базы на продакшене. Что-нибудь удаляется или переименовывается?

Сделай так, чтобы все настройки, зависящие от среды (адреса API, ключи, отправитель писем, собственный адрес сайта), брались из переменных окружения с одинаковыми именами в staging и продакшене. Перечисли их.

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

Частые ошибки

• Общая база данных. Самая разрушительная ошибка. У staging всегда должна быть своя база.
• Боевые ключи в staging. Реальные списания и реальные письма реальным клиентам.
• Staging расходится с продакшеном. Разные версии или настройки означают, что staging перестает ловить проблемы.
• Публичный и индексируемый staging, который попадает в результаты поиска рядом с настоящим сайтом.
• Пропуск staging для «мелких» изменений. Мелкие изменения тоже ломают вещи.
• Тестирование не в той вкладке. Заметный баннер решает эту проблему.

Чек-лист

• Staging работает на том же коде, стеке и сервисах, что и продакшен.
• У staging своя база с тестовыми или обезличенными данными.
• Платежи, почта и платные API в staging используют тестовые ключи.
• Имена переменных совпадают в средах; меняются только значения.
• Staging закрыт логином или паролем и не индексируется.
• Баннер показывает, что вы находитесь на staging.
• Каждый релиз сначала идет на staging, с письменным списком сценариев для проверки.
• Изменения базы сначала применяются на staging, а перед выпуском делается резервная копия продакшена.

Staging на Mythex

Publish в Mythex дает одно живое адрес на приложение; отдельного переключателя staging нет. На практике есть два варианта:

• Превью как предрелизная проверка. Каждый проект работает в закрытом облачном рабочем пространстве с живым превью. Команда /test позволяет агенту пройти по нему как пользователь, а ссылка Share дает клиенту или коллеге посмотреть превью без публикации. См. Превью и код. Для многих одиночных проектов этого достаточно.
• Второй проект как staging. На тарифе Pro экспортируйте проект и импортируйте его в новый проект, дайте ему собственную базу и секреты с тестовыми ключами и опубликуйте его под отдельным адресом. Выпускайте релиз туда до того, как публиковать основной проект.

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

Вопросы