Зачем сайту тестовая копия и как она спасает от простоя

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

Чем опасны правки прямо на рабочем сайте

Есть привычка, которая рано или поздно дорого обходится почти каждому владельцу сайта: править боевой сайт напрямую. Поменять код «по-быстрому», обновить плагин в один клик, переключить шаблон посмотреть, как выглядит. Пока всё работает, кажется, что так и надо. Это ходьба по канату — без страховки и над работающим бизнесом.

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

Что такое staging простыми словами

Staging, или тестовая копия, — это полный двойник вашего сайта на техническом поддомене вроде dev.vashsajt.ru. Тот же код, та же структура, копия базы данных. Разница одна: его видите только вы и разработчики. Любую правку сначала делают там, смотрят на результат, и только потом переносят на боевой сайт.

Рабочий сайт разработчики называют «боевым» или «продакшеном», тестовую копию — «стейджингом» или «тестовой площадкой». В крупных проектах бывает ещё третья среда — локальная копия на компьютере программиста, где пишется код. Для большинства сайтов малого бизнеса достаточно двух: рабочий сайт и одна тестовая копия.

Копия закрыта от индексации и от посторонних глаз — обычно паролем. Поисковики её не находят, дублей в выдаче не возникает, конкуренты не подглядывают за будущим редизайном.

Что проверяют на тестовой копии

• Обновления CMS и плагинов — самый частый источник внезапных поломок, тот самый случай с корзиной.
• Смену версии PHP. Старый код может не заработать на новой версии — зачем и как её менять, мы объясняли в статье про обновление PHP на хостинге.
• Доработки: новые разделы, изменения в формах, правки кода. Сначала на копии, на бою — уже проверенное.
• Новый дизайн целиком. Клиент кликает по копии и утверждает результат до того, как его увидят покупатели. При редизайне сайта без тестовой площадки не обойтись.
• Интеграции с 1С, CRM и оплатой — здесь ошибка на бою стоит дороже всего.
• Массовые изменения: импорт цен, смену адресов страниц, перенос раздела.

Есть и побочный бонус: тестовая копия — это ещё одна свежая копия сайта. Не замена бэкапам, но лишняя точка восстановления в хозяйстве не помешает.

Тестовая копия и резервная копия: в чём разница

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

Одно другого не заменяет: перед переносом изменений на рабочий сайт всё равно делают свежий бэкап. Как организовать хранение копий, описано в статье про резервное копирование сайта.

Нужна ли тестовая копия вашему сайту

Как сделать тестовую копию сайта: пошагово

На многих хостингах и в популярных CMS есть готовые инструменты, которые создают копию почти автоматически. Если таких нет, разработчик делает это вручную — порядок действий один и тот же.

1. Создайте поддомен для копии, например dev или test. Что такое поддомен и как он заводится, рассказано в статье про поддомены.
2. Скопируйте файлы сайта в папку поддомена.
3. Создайте отдельную базу данных и загрузите в неё копию рабочей. Общая база у копии и рабочего сайта — грубая ошибка: тесты будут менять реальные данные.
4. Поправьте настройки копии: подключение к новой базе и адрес сайта, чтобы ссылки вели на поддомен, а не на рабочий домен.
5. Закройте копию паролем на уровне сервера. Надёжный пароль можно собрать в генераторе паролей.
6. Запретите индексацию: пароль уже не пускает роботов, а запрет в robots.txt и мета-тег noindex служат дополнительной страховкой.
7. Установите SSL-сертификат на поддомен, чтобы копия работала по HTTPS, как и основной сайт.
8. Отключите всё, что общается с внешним миром: письма клиентам, оплату, обмены. Подробности — в следующем разделе.
9. Пометьте копию визуально — например, яркой полосой «Тестовая версия» в шапке. Так никто не перепутает вкладки и не начнёт править не тот сайт.
10. Пройдите основные сценарии: главная, каталог, форма, корзина, вход в админку. Если всё работает — площадка готова.

Что обязательно отключить на копии

Копия сайта — это копия всех его привычек. Если их не отключить, тестовая площадка начнёт рассылать письма настоящим клиентам и отправлять тестовые заказы в учётную систему.

Отдельно подумайте о данных клиентов. В копии базы лежат те же имена, телефоны и заказы, что и на рабочем сайте, поэтому доступ к тестовой площадке должен быть ограничен так же строго. В крупных проектах данные на копии обезличивают — заменяют настоящие контакты вымышленными.

Как переносить изменения на рабочий сайт

Главное правило: код едет с копии на рабочий сайт, а данные — в обратную сторону. Перезаписать рабочую базу данных базой с копии значит потерять все заказы и заявки, которые пришли за время тестов.

1. Проверьте изменение на копии по списку сценариев: не только то, что меняли, но и оформление заказа, формы, поиск.
2. Выберите время с минимальной посещаемостью — для большинства сайтов это ночь или раннее утро.
3. Сделайте свежую резервную копию рабочего сайта: файлов и базы.
4. Перенесите изменения в коде. Удобнее всего — через систему контроля версий, которая хранит историю правок и позволяет откатиться одной командой. Для простых сайтов подойдёт и аккуратная синхронизация файлов.
5. Изменения в настройках и структуре базы повторите на рабочем сайте по заранее записанному списку.
6. Проверьте рабочий сайт теми же сценариями и отправьте тестовую заявку или заказ.
7. Убедитесь, что вместе с файлами на рабочий сайт не переехали настройки копии — в первую очередь запрет индексации.
8. Перед следующими работами обновите копию свежими данными с рабочего сайта, чтобы она не устаревала.

Сколько стоит тестовая копия

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

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

Почему тогда тестовая копия есть далеко не у всех? Потому что о ней вспоминают после первой аварии, а не до. Да, так бывает почти со всей инфраструктурой. Обычно копию заводят в рамках сопровождения — что ещё в него входит, описано в статье про техподдержку сайта.

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

• Копия открыта всему интернету. Поисковики находят её и индексируют как дубль, а посетители попадают на тестовый сайт и оформляют заказы, которые никто не увидит.
• Закрыли только в robots.txt. Этот файл — просьба к роботам, а не замок. Надёжно закрывает только пароль.
• Запрет индексации уехал на рабочий сайт. Вместе с файлами копии переносят её robots.txt — и сайт постепенно выпадает из поиска.
• Копия шлёт письма клиентам. Рассылку или уведомления о заказах забыли отключить.
• Общая база данных. Тестовые правки меняют реальные товары и заказы.
• Копия устарела. Её сделали год назад, и проверка на ней ничего не гарантирует: на рабочем сайте уже другие версии и данные.
• Разное окружение. На копии одна версия PHP и настроек сервера, на рабочем сайте другая — то, что работало в тесте, ломается после выкладки.
• Проверили только то, что меняли. Обновили модуль доставки, а сломалась оплата — без прохода по основным сценариям этого не увидеть.

Чек-лист тестовой копии

• Копия работает на отдельном поддомене со своей базой данных.
• Доступ закрыт паролем, индексация запрещена.
• Письма, СМС, оплата и обмены с внешними системами отключены или переведены в тестовый режим.
• Счётчики аналитики на копии не собирают статистику.
• Версия PHP и настройки сервера совпадают с рабочим сайтом.
• Копия помечена визуально, чтобы её не путали с рабочим сайтом.
• Есть список сценариев для проверки после каждого изменения.
• Перед выкладкой делается бэкап рабочего сайта.
• После выкладки проверяется, что рабочий сайт открыт для индексации.
• Копия обновляется свежими данными перед новыми работами.

Коротко

Тестовая копия — закрытый двойник сайта, на котором проверяют обновления, доработки и интеграции до выкладки. Она почти ничего не стоит, но требует аккуратности: отдельная база, пароль, отключённые письма и оплата, перенос кода в одну сторону, а данных — в другую. Магазину и сайту с ежедневными заявками она нужна обязательно.

У нас в CasperLab тестовая копия — стандарт для всех проектов на поддержке: правки и обновления сначала едут на staging, потом на бой. Если ваш сайт до сих пор живёт без страховки — напишите нам или оцените задачу в калькуляторе: настроим копию и посчитаем поддержку под ваш проект.