Staging - это полная копия сайта, которая живёт на отдельном адресе и закрыта от посторонних. На ней разработчик вносит изменения, проверяет их, показывает заказчику, и только после одобрения то же самое переносится на боевую версию. Звучит как лишний шаг, но именно он отделяет спокойные обновления от ситуаций, когда после невинной правки перестаёт работать корзина.
Почему нельзя править сразу на живом сайте
На работающем сайте в любой момент есть посетители. Пока вы меняете шаблон, кто-то оформляет заказ, кто-то заполняет форму. Ошибка в коде, которую вы заметите через десять минут, эти десять минут будет видеть каждый. В худшем случае вы правите файл, что-то идёт не так, и сайт отдаёт белый экран целиком.
Есть и вторая причина - согласование. Заказчик хочет посмотреть новый блок до того, как его увидят клиенты. На staging можно показать вариант, обсудить, переделать три раза и выкатить только финал. Без тестовой версии каждая итерация проходит на глазах у аудитории.
Как устроен процесс с тремя средами
В зрелой разработке сред обычно три. Локальная - на компьютере разработчика, там пишется код. Staging - копия на сервере, там проверяют и согласуют. Продакшн - то, что видят пользователи. Изменение движется строго в одну сторону: локально, потом staging, потом продакшн. Обратно с продакшна на staging регулярно копируют базу данных, чтобы тестовая версия работала на свежем контенте.
- Новый функционал собирается и тестируется на staging, а не сразу в бою
- Обновления движка и плагинов сначала прогоняются на копии - так видно, что именно сломалось
- Крупные правки контента можно подготовить заранее и опубликовать одним переносом
- Если на продакшне возникла проблема, staging помогает воспроизвести её в безопасной обстановке
Что важно настроить на staging
Тестовая версия должна быть закрыта от индексации и от случайных посетителей - хотя бы паролем на уровне сервера. Иначе Google найдёт копию сайта и начнёт путать её с оригиналом, а это уже проблема для позиций. Платёжные системы на staging переключают в тестовый режим, отправку писем клиентам отключают или перенаправляют на адрес разработчика. Не хватало только, чтобы тестовый заказ ушёл реальному покупателю.
Ещё важно, чтобы staging был именно копией, а не похожим сайтом. Та же версия движка, те же плагины, те же настройки сервера. Если тестовая среда отличается от боевой, проверка на ней ничего не гарантирует: на копии работает, в бою падает. Раз в месяц полезно заново копировать продакшн на staging целиком - и файлы, и базу - чтобы среды не разъезжались со временем.
Отдельно решите, кто и как переносит изменения со staging на боевую версию. В идеале это не ручное копирование файлов по одному, а понятная процедура: у простых сайтов - через панель хостинга или плагин, у более сложных - через систему контроля версий, когда одобренные правки выкатываются одной командой. Ручной перенос почти всегда рано или поздно приводит к тому, что на бой попадает не тот файл или забывается изменение в базе данных.
Полезно вести короткий журнал: что и когда выкатили на продакшн. Одна строка на каждое обновление с датой и сутью правки. Когда через две недели на сайте что-то сломается, этот журнал за минуту подскажет, какое из последних изменений виновато, вместо того чтобы гадать и перебирать всё подряд.
Нужен ли staging маленькому сайту
Сайту-визитке на пять страниц отдельная тестовая среда - перебор. Там достаточно резервной копии перед любой правкой. Но как только на сайте появляются заказы, интеграции, регулярные обновления контента и несколько человек, которые вносят изменения, staging перестаёт быть роскошью. Один предотвращённый сбой на боевой версии окупает его настройку с запасом.