Что такое staging-среда? Тестируйте перед запуском

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

Почему staging важна, когда вы создаёте приложение с помощью AI

Создание с помощью AI делает изменения быстрыми. Можно добавить функцию, переписать страницу или поменять структуру данных за несколько минут. Такая скорость отлично работает, пока изменение, которое выглядело нормально, незаметно не сломает оплату или «небольшая очистка» не удалит колонку с данными клиентов.

Место, где можно проверить изменения до выхода в свет, помогает:

• Ловить поломки раньше клиентов. Проверяйте регистрацию, оплату и ключевые сценарии после каждого значительного изменения.
• Тестировать в реальных условиях. Staging должна вести себя как production — тот же стек, похожая конфигурация, — чтобы проблемы проявлялись там, а не позже.
• Защищать реальные данные. Изменения базы, импорт и массовое редактирование можно сначала отрепетировать на тестовых данных.
• Показывать работу в процессе. Клиент или коллега может проверить изменение, не делая его публичным.

Бытовая аналогия

Представьте генеральную репетицию в театре.

• Development — это репетиционный зал: актёры пробуют реплики, останавливаются, начинают заново, экспериментируют.
• Staging — это генеральная репетиция: полные костюмы, настоящая сцена, настоящий свет — всё так, как будет в премьерный вечер, только без платной публики.
• Production — это премьера. Ошибки случаются на глазах у всех.

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

Три распространённые среды

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

Пример: изменение правил отмены записи в приложении салона

У вас есть приложение для записи в салон с платящими клиентами. Вы хотите изменить правило: отменить запись можно за 24 часа, а не за 48, и возврат оформляется автоматически.

1. Создайте изменение в development. Попросите AI-конструктор внести правку. Он обновит логику отмены и вызов возврата средств у вашего платёжного провайдера.

2. Выпустите изменение в staging. Staging работает на том же коде, но подключена к тестовой базе с тестовыми записями и к ключам тестового режима платёжного провайдера.

3. Проверьте реальные сценарии. Вы и коллега:

• записываете тестового клиента на завтра и отменяете за 30 часов — должен произойти возврат;
• пробуете отменить за 10 часов — должен быть отказ с понятным сообщением;
• проверяете, что возврат появляется в тестовой панели платёжного провайдера;
• проверяете, что в письме с подтверждением написано 24 часа, а не 48.

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

5. Выпускаете в production. Только теперь изменение доходит до реальных клиентов — и ошибка с часовым поясом уже поймана.

Без staging шаг 4 произошёл бы с возвратом средств реальному клиенту.

Ключевые термины

Частые заблуждения

• «Staging может использовать базу production». Это самая опасная уловка. Тест, который удаляет или меняет записи, попадёт в настоящих клиентов. Дайте staging собственную базу.
• «Если работает в staging, в production точно не сломается». Staging снижает риск, но не устраняет его. Реальный трафик, реальные данные и внешние сервисы всё равно могут удивить. Держите способ откатиться.
• «Staging должна быть дорогой». Она может быть небольшой. Ей нужна та же конфигурация, что и у production, а не тот же размер.
• «Используйте боевые платёжные ключи в staging, чтобы было реалистичнее». Используйте тестовый режим провайдера. Реалистичность не означает реальные деньги.
• «Staging нужна только большим командам». Сама идея — сначала проверить в безопасном месте — полезна даже одному человеку. Степень формальности может расти вместе с ценой ошибки.
• «Staging должна быть публичной, чтобы люди могли её попробовать». Держите её закрытой или защищённой и запретите поисковикам её индексировать, чтобы её никто не принял за настоящее приложение.

Что попросить у AI-конструктора

• «Все настройки, зависящие от среды — базу данных, API-ключи, адрес сайта, — бери из переменных окружения.»
• «Добавь seed-скрипт, который заполняет непроизводственную базу реалистичными тестовыми данными.»
• «Используй тестовый режим платёжной системы, пока я не скажу, что мы запускаемся.»
• «Перед выпуском этого изменения перечисли сценарии, которые мне нужно проверить, и что должно происходить в каждом.»
• «Повлияет ли это изменение на существующие данные? Сначала покажи миграцию.»
• «Убедись, что непроизводственные копии сайта не индексируются поисковиками.»

Пошаговую настройку см. в статье как настроить staging-среду. Когда релизы становятся частыми, автоматизировать путь от кода до staging и production помогает CI/CD.

Тестирование перед релизом в Mythex

В Mythex нет отдельного переключателя «staging или production»: публикация даёт один живой публичный адрес, и об этом прямо написано в документации (приложения из нескольких сервисов). Зато есть чёткая граница между созданием и выходом в эфир:

• Preview запускает ваше приложение в приватной облачной песочнице, пока вы его создаёте. Изменения сначала появляются там, а не в живом приложении.
• Share создаёт ссылки на предпросмотр, чтобы клиент или коллега могли посмотреть работу в процессе без аккаунта Mythex и без публикации. Ссылка показывает песочницу в текущем состоянии, включая незавершённые изменения, и её можно удалить в любой момент.
• Publish сохраняет снимок проекта и разворачивает его. Пока вы не опубликуете снова, живое приложение остаётся прежним.
• Checkpoints сохраняются после каждого успешного хода агента, поэтому файлы проекта можно откатить, если изменение пошло не так.

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

Вопросы