Править форму или общий шаблон сразу на боевом сайте — значит проверять изменения на посетителях. Любая интеграция, фильтр каталога или письмо-триггер должны сначала пройти через тестовый контур. Расскажу, как мы организуем стенд и согласование, чтобы релизы не превращались в лотерею.
Что отделяем от продакшена
Стенд нужен для всего, что может сломать сценарий пользователя: формы заявок, авторизация, каталог, поисковые фильтры, общий шаблон, интеграции с CRM и почтовыми сервисами, права доступа.
Сразу оговорюсь про данные. На тестовый контур мы не копируем персональные данные и рабочие ключи — для проверки хватает обезличенного набора записей и тестовых учётных записей. Если для сценария нужна CRM, подключаем тестовый портал, а не боевой. Доступ выдаём по роли и сроку: редактору не нужен доступ к серверу, а внешнему подрядчику — постоянный доступ после завершения задачи.
Отдельный документ фиксирует отличия стенда от продакшена. Без него фраза «на стенде всё работает» ничего не доказывает: тестовый сервер может жить на другой версии PHP, с другим кэшем или без подключения к CRM. Тестировщик должен понимать границы проверки.
На проверку передают сборку, а не ссылку
Самая частая ошибка — скинуть заказчику ссылку на стенд, который меняется каждый день. Через несколько дней уже невозможно восстановить, что именно согласовали.
Правильный порядок такой:
- На проверку уходит конкретная сборка с номером версии.
- В задаче указаны состав изменений, известные ограничения и сценарии, которые должен подтвердить владелец процесса.
- Комментарии и решения пишутся в системе задач с привязкой к версии, а не в мессенджер.
Статус «согласовано в мессенджере» — это не статус. Запись в трекере с версией макета или требований позволяет через месяц ответить на вопрос, почему сайт выглядит именно так.
Очередь релизов и журнал решений
У регулярных доработок есть конфликт: две задачи меняют один шаблон, третья ждёт согласования от маркетинга, четвёртая зависит от готовности формы. Очередь релизов показывает зависимости, плановую дату и владельца решения.
У каждой задачи есть статус проверки и решение о переносе в продакшен. Недоделанную задачу не переносят незаметно вместе с готовыми — фиксируют причину: дефект, отсутствие данных, изменение требования или внешняя зависимость.
В журнале остаются ссылка на тестовый результат, согласованная версия требований и запись о переносе. Через неделю такой журнал позволяет восстановить состав конкретного релиза, расследовать проблему или отменить одну из доработок, не откатывая всё остальное.
Подготовка к выпуску
Перед релизом проверяем, что на стенде согласованная версия, а не промежуточная правка, и прогоняем короткий smoke-тест по ключевому маршруту. Фиксируем, кто подтвердил результат.
После переноса на продакшен проверяем тот же маршрут уже на боевом сайте. Если правка коснулась общего компонента — формы или меню, — список проверки расширяем на все места его использования. Это занимает заметно меньше времени, чем аварийное исправление, когда заявки перестали доходить в CRM в пятницу вечером.
Итог
Тестовая среда и журнал решений делают состав выпуска проверяемым. Перед переносом в продакшен команда должна знать четыре вещи: версию сборки, подтверждённые сценарии, известные ограничения и владельца решения. Если хотя бы одного пункта нет — релиз откладывается.
Top comments (0)