ДОРОЖНАЯ КАРТА
Этап 2: запуск нового сайта, личного кабинета и админки InGame
0. Подготовка к реализации
- Описаны логика бронирований и заказов, подарочных карт и промокодов, роли и права, ключевые сценарии админки и состав основных сущностей данных.
- Зафиксировано, что переносится напрямую, что требует изменения, а что не входит в согласованный объём; определены риски, спорные места и зависимости от интеграций.
- Создан репозиторий исходного кода с доступом заказчика и подготовлена стартовая документация по системе, средам и передаче работ.
- ТЗ, архитектурная схема, дорожная карта и критерии реализации согласованы до начала производственной реализации; уточнения продолжаются по мере появления обратной связи.
1. Общая последовательность
| Этап | Что делаем | Контрольная точка |
|---|---|---|
| 0. Уточнения и рабочий цикл | Сверяем текущий WordPress-контур, ежедневную логику бронирований/заказов, статусы, роли, уведомления и интеграции. Выделяем рабочий объём v1, фиксируем архитектуру, модель данных, состав миграции, границы и риски. Уточнения не прекращаются после этапа 0: каждый новый вопрос, изменение или обратная связь фиксируются, оцениваются и проходят цикл согласования, доработки и повторной проверки. | Есть единый список решений, рисков и открытых вопросов с ответственным и статусом; согласованы ТЗ, архитектура, границы v1 и предварительные критерии приёмки. |
| 1. Основа | Готовим репозиторий с доступом заказчика, test/prod-контуры, резервные копии, мониторинг, место на диске, модель данных, карту и пробный план миграции, стартовую техническую документацию. | Среда и репозиторий готовы; данные и риски миграции инвентаризированы; у команды есть единая точка для кода и документации. |
| 2. Доступ и контроль | Делаем персональные учётные записи, роли, серверную проверку прав, аудит и безопасную работу с клиентскими аккаунтами. | Каждый сотрудник работает под своим логином; действия можно отследить. |
| 3. Операционное ядро | Реализуем календарь, один заказ с несколькими бронями, лаунжи, правила услуг, оплаты, кассу, сертификаты, промокоды, отчёт смены. В админке появляются дашборд текущего дня, заказы и бронирования, клиенты и история, карточки квестов, расписание, тарифы, роли и базовые настройки. | Система не допускает конфликтующие брони; касса и аудит проверены на реальных сценариях; ключевые разделы админки позволяют команде вести рабочий день. |
| 4. Сайт и ЛК | Реализуем публичный сайт и ЛК на et/ru/en в согласованном объёме: каталог, гостевую бронь, регистрацию, управление заказом, контент, SEO, переводы и сервисные сообщения. Бизнес-логика сайта соответствует согласованным сценариям бронирования и заказа. | Клиент проходит весь путь: выбор, заказ, оплата, письмо, вход в ЛК; согласованный функционал сайта работает на утверждённом технологическом стеке. |
| 5. Интеграции | Подключаем Montonio, amoCRM, Telegram и email через очередь надёжной доставки; настраиваем email-шаблоны и автоматические сервисные сообщения, связанные с заказами и бронями. Для каждой интеграции проводим сквозную проверку: штатная операция, повторная доставка, недоступность внешнего сервиса, восстановление из outbox и сверка журнала событий. | Подтверждён полный контур интеграций: amoCRM получает корректный контекст клиента и заказа; Montonio корректно обрабатывает оплату, отказ, повторный webhook и возврат; уведомления не дублируются и не теряются. amoCRM остаётся каналом коммуникации, а не источником данных. |
| 6. Полное техническое тестирование | После реализации всего объёма проводим подробный цикл: unit- и интеграционные тесты, тесты БД и миграции, API/контрактные и негативные сценарии, проверку ролей и безопасности, typecheck/lint/build. Сквозные сценарии сайта, ЛК и админки проверяем через Playwright: браузерный UI, API-вызовы, оплаты, webhooks, многобронирование, отмены, уведомления и ошибки интеграций. Команда отдельно проходит сценарии руками через интерфейсы. | Все P0/P1-сценарии имеют результаты тестов; критических дефектов нет; для найденных ошибок создана задача, исправление и регрессионный тест. |
| 7. Внутренняя демо-проверка | Разворачиваем стабильную тестовую версию только для внутренней команды, не выводя её в production. Команда в течение одной недели работает по чек-листам в ролях клиента, оператора, смены и владельца: создаёт и меняет реальные сценарии, проверяет отчёты, платежи, коммуникации и удобство интерфейсов. | Внутренний тестовый период завершён; обратная связь и баги собраны в единый реестр с приоритетом, ожидаемым/фактическим результатом и ответственным. |
| 8. Доработки по обратной связи | После каждого фидбэка выполняем цикл: разбор и приоритизация → исправление → добавление или обновление автотеста → регрессионная проверка → повторная внутренняя демонстрация при существенных изменениях. Цикл повторяется до закрытия критичных замечаний. | P0 и P1 либо закрыты, либо явно согласованы владельцем как допустимый остаточный риск; повторная проверка не выявила регрессий. |
| 9. Контролируемый production-запуск | Только после готовности переносим финальную дельту, переключаем домен и включаем мониторинг. До запуска настраиваем средства быстрого реагирования: переключение на предыдущую версию, feature flags для рискованных функций, оперативное отключение интеграций/уведомлений, резервные копии, журнал действий и пошаговый план отката. | Новый контур принимает заказы под усиленным мониторингом; ответственные и канал связи на запуск назначены; откат проверен и выполним. |
| 10. Поддержка после запуска | После production-запуска отслеживаем ошибки, платежи, доставки уведомлений, производительность и обратную связь. Новые замечания попадают в приоритизированный backlog и проходят тот же цикл: уточнение → доработка → автоматические и интерфейсные тесты → выпуск. | Первые дни запуска завершены без критических инцидентов; регулярный цикл поддержки и улучшений запущен. |
2. Что проверяем на контрольных точках
| Точка | Минимальная проверка |
|---|---|
| После основы | Репозиторий доступен заказчику; восстанавливается резервная копия; тестовый контур изолирован; архив WordPress сохранён; есть отчёт по объёму данных и медиа, карта миграции и стартовая документация. |
| После доступа | Владелец создаёт роль; сотрудник без финансовых прав не видит деньги; скидка и кассовая правка имеют автора и причину. |
| После ядра | Два параллельных пользователя не могут забронировать один ресурс; в заказе работают несколько квестов и отдельный лаунж; касса показывает дельту; дашборд, заказы, клиенты, расписание, тарифы и базовые настройки доступны по ролям. |
| После сайта и ЛК | Работают et/ru/en, гостевой заказ, регистрация по email, история клиента, правила услуг, редактирование контента и заказов. |
| После интеграций | По отдельному чек-листу проверены amoCRM, Montonio, Telegram и email: параметры и авторизация, подписи webhooks, соответствие статусов и сумм, создание/изменение/отмена заказа, успешная и отклонённая оплата, повторная доставка, тайм-аут, восстановление из outbox и журнал событий. amoCRM получает одну сделку на один заказ с корректным контекстом клиента; платёж не создаёт дубль и не меняет сумму без аудита. |
| После технического тестирования | Пройдены unit-, интеграционные, API-, БД- и E2E-тесты; Playwright покрывает критические пользовательские сценарии в UI и API; критические дефекты закрыты. |
| После внутренней демо-проверки | Команда отработала неделю на тестовом контуре; все замечания зарегистрированы, приоритизированы, исправлены или явно согласованы; выполнена регрессия. |
| Перед production-запуском | Пробная миграция сверена, старые URL имеют 301-карту, все критерии приёмки ТЗ пройдены, есть ответственные за запуск и откат, резервные копии, мониторинг, feature flags и возможность оперативно отключить рискованные интеграции. |
| После production-запуска | Контроль заказов, оплат, интеграций, уведомлений и ошибок ведётся в усиленном режиме; действует быстрый канал обратной связи и очередь исправлений. |
3. Условия запуска
- Весь согласованный функционал реализован и прошёл технический тестовый цикл: unit-, интеграционные, API-, БД-, миграционные и E2E-проверки, typecheck/lint/build, негативные сценарии и проверку прав доступа.
- Playwright покрывает критические пользовательские пути сайта, ЛК и админки: UI, API, многобронирование, оплаты, webhooks, отмены, уведомления и недоступность внешних систем.
- Команда вручную прошла критические сценарии через интерфейсы, а результаты, логи и найденные дефекты зафиксированы.
- Внутренняя демо-проверка на тестовом контуре длилась не менее одной недели. Все P0/P1-замечания закрыты либо явно согласованы владельцем; после исправлений проведена регрессия.
- Миграция имеет отчёт сверки и согласованный список исключений; данные не потеряны молча.
- Montonio, amoCRM, Telegram и email работают в продовых настройках с журналом ошибок и повторной отправкой.
- У каждого сотрудника есть персональный доступ и короткая инструкция по смене, деньгам и ошибкам.
- Настроены резервные копии, мониторинг, контакты ответственных, переключение на предыдущую версию, feature flags, оперативное отключение рискованных интеграций и понятный сценарий отката домена/заказов.
- После production-запуска действует усиленная поддержка: мониторинг заказов, оплат, уведомлений и ошибок, быстрый разбор обратной связи и цикл доработок с повторным тестированием.
4. Состав тестового цикла
| Уровень | Как проверяем | Результат перед следующим уровнем |
|---|---|---|
| Код и сборка | Typecheck, lint, сборка и unit-тесты бизнес-правил: цены, скидки, доступность, отмены, возвраты, статусы и права. | Сборка воспроизводима; проверки проходят; новые правила не выпускаются без теста на основную и ошибочную ветку. |
| Сервер и БД | Интеграционные тесты сервисов и серверных маршрутов, миграций, ограничений БД, транзакций и аудита. Отдельно проверяем параллельное бронирование одного ресурса, целостность заказа и невозможность доступа в обход роли. | Нет конфликтующих броней, дубликатов оплат и неаудируемых финансовых действий; миграции накатываются и проверяются на тестовой копии данных. |
| API и внешние сервисы | Контрактные и негативные API-тесты, авторизация, webhooks, повторная доставка, тайм-ауты и ошибки. Для Montonio проверяем оплату, отказ, возврат, подпись webhook, повтор webhook и сверку суммы/статуса; для amoCRM — контакт, одну сделку на заказ, передачу состава заказа и изменение статуса; для Telegram и email — шаблон, адресата, повтор и доставку. Для всех интеграций проверяем частичный сбой и восстановление из outbox. | Интеграция не создаёт дубли, её сбой не портит внутренние данные, а повторная попытка и журнал событий работают. |
| Сквозные UI/E2E | Playwright запускает реальные сценарии в браузере: сайт, ЛК и админка; UI-действия и API-проверки результата. Покрываются выбор слота, многобронирование, оплата, вход, отмена, уведомления, роли, касса и отчёты. | Все P0/P1-пути проходят без ручных обходов; результат в интерфейсе совпадает с данными API и БД. |
| Ручная проверка | Команда проходит сценарии руками через интерфейсы в ролях клиента, оператора, смены и владельца. Проверяются понятность форм, тексты ошибок, таблицы, фильтры, действия в нестандартных ситуациях и соответствие ТЗ. | Каждое найденное отклонение имеет карточку с приоритетом, шагами воспроизведения, ожидаемым и фактическим результатом. |
| Регрессия | После каждого исправления добавляется или корректируется автоматическая проверка; повторно запускаются затронутые unit/API/E2E-тесты и критические ручные сценарии. | Исправление не вернуло старую ошибку и не сломало смежный функционал; результаты приложены к задаче. |
5. Цикл фидбэка и доработок
- Любой вопрос, замечание с внутренней демо-проверки или инцидент из production регистрируется с источником, приоритетом, ответственным и критерием готовности.
- Команда сначала уточняет правило и влияние на деньги, брони, данные и интеграции; затем согласует решение и реализует изменение.
- Для изменения добавляются или обновляются автотесты, выполняется регрессия и, при существенном влиянии на сценарии, повторяется внутренняя демонстрация.
- В production выпускаются только изменения с понятным планом отката и мониторингом. Наблюдения после выпуска возвращаются в этот же цикл улучшений.
6. Артефакты и результаты
| Когда | Что должно быть подготовлено |
|---|---|
| До производственной реализации | Согласованные ТЗ и архитектурная схема; описание рабочего объёма v1; схема основных данных; состав и предварительная оценка миграции; перечень интеграций; ограничения, спорные места и технические риски; дорожная карта и критерии приёмки. |
| Во время реализации | Репозиторий исходного кода с доступом заказчика; актуальная документация по развёртыванию и передаче; реализованные сценарии сайта, ЛК и админки; настройки интеграций, уведомлений, ролей и аудита. |
| Перед внутренней демо-проверкой | Отчёты автоматических и ручных тестов, перечень известных ограничений, тестовые данные и чек-листы для ролей клиента, оператора, смены и владельца. |
| Перед и после production-запуска | Реестр обратной связи и исправлений, журнал регрессии, отчёт сверки миграции, runbook запуска и отката, настройки мониторинга, резервного копирования и оперативного отключения рискованных функций. |