Обновить плагин, поменять тему, установить новую версию CMS или немного переделать сайт кажется простой задачей ровно до того момента, когда после нажатия кнопки перестает открываться главная страница. Еще неприятнее, если эксперимент проводится на интернет-магазине, куда в это время приходят покупатели и оформляют заказы.
Проверять серьезные изменения непосредственно на работающем сайте рискованно. Для этого существует тестовая копия. Ее часто называют staging-сайтом или тестовым окружением.
По сути это отдельный экземпляр вашего сайта, на котором можно экспериментировать без риска для посетителей. Если обновление прошло удачно, изменения переносятся на рабочую версию. Если все сломалось, ничего страшного не произошло: основной сайт продолжает работать.
При этом тестовая копия не является обычной резервной копией. Бэкап нужен прежде всего для восстановления после проблемы, а staging создается для работы и проверки изменений. Разберемся, где разместить такую копию, как не показать ее поисковикам и почему особенно осторожно нужно тестировать интернет-магазины и другие сайты с постоянно меняющимися данными.
Чем тестовая копия отличается от резервной
Представим работающий сайт компании. На нем есть страницы услуг, фотографии, форма заявки и административная панель. Владелец хочет полностью поменять дизайн.
Можно сделать резервную копию, установить новую тему прямо на основном сайте и надеяться, что все пройдет хорошо. Если возникнет проблема, придется восстанавливать прежнюю версию.
Это рабочая стратегия для небольших изменений, но для серьезной переделки она неудобна. Пока новый дизайн настраивается, посетители могут видеть промежуточный результат, ошибки верстки и неработающие элементы.
Гораздо удобнее создать копию.
Основной сайт продолжает работать по адресу:
site.ru
А тестовая версия размещается, например, здесь:
test.site.ru
или:
dev.site.ru
Внешне и технически это может быть почти тот же сайт. У него есть собственные файлы и, если используется CMS, отдельная база данных. Владелец меняет дизайн на тестовой версии, устанавливает плагины, редактирует шаблон и проверяет результат.
Посетители основного сайта этих экспериментов не замечают.
Когда новая версия готова, изменения переносятся на рабочий проект.
Резервная копия решает другую задачу. Она сохраняет состояние сайта на определенный момент. Если данные будут удалены, файлы повреждены или обновление окажется неудачным, из бэкапа можно восстановить прежнее состояние.
Поэтому staging не заменяет резервное копирование, а резервная копия не заменяет staging.
Более того, перед серьезными изменениями полезно использовать оба инструмента. Сначала создать актуальный бэкап рабочего сайта, затем развернуть тестовую копию и проводить эксперименты уже на ней.
Тестовое окружение особенно полезно перед обновлением CMS, темы или крупного плагина. Оно пригодится при переходе на другую версию PHP, серьезной переделке шаблона, изменении структуры страниц, установке нового модуля интернет-магазина или подключении сложной интеграции.
Для небольшой правки текста создавать отдельную копию каждый раз, конечно, нет необходимости.
Смысл staging появляется там, где ошибка способна нарушить работу сайта или где изменение невозможно нормально проверить за несколько секунд.
Есть и еще одно преимущество. На тестовой версии можно спокойно сравнивать варианты.
Например, дизайнер меняет карточку товара. Вместо того чтобы несколько раз переделывать ее на глазах покупателей, он работает на копии и показывает результат владельцу магазина. Только утвержденный вариант появляется на основном сайте.
Так тестовая среда становится не только защитой от технических ошибок, но и нормальным рабочим пространством.
Где разместить тестовую версию сайта
Самый понятный вариант для владельца обычного сайта это поддомен.
Например:
stage.site.ru
Сам по себе поддомен не создает копию. Сначала на хостинге для него выделяется отдельный каталог, затем туда копируются файлы сайта. Для динамического проекта обычно создается отдельная база данных и в конфигурации тестовой версии прописываются данные подключения к ней.
В результате основной и тестовый сайты существуют независимо.
Изменение файла на stage.site.ru не должно менять такой же файл на site.ru. Запись, добавленная в тестовую базу, не должна попадать в рабочую базу.
Именно изоляция делает staging безопасным.
Если две версии используют одни файлы или одну базу данных, эксперимент на тестовом адресе способен неожиданно изменить рабочий сайт.
У некоторых хостингов есть встроенная функция создания staging-копии. Она может называться клонированием, тестовой копией или иначе.
Это удобный вариант, потому что панель сама копирует необходимые данные и создает отдельное окружение. Иногда предусмотрена и обратная операция, когда проверенные изменения можно перенести на основной сайт.
Но перед использованием кнопки переноса стоит разобраться, что именно она заменяет.
Если речь идет о небольшом корпоративном сайте, полная замена тестовой версией может быть приемлема. С интернет-магазином ситуация сложнее.
Допустим, утром была создана тестовая копия магазина.
В течение дня на основном сайте покупатели оформили двадцать заказов, зарегистрировались новые пользователи и изменились остатки товаров. В это время разработчик работал со старой копией базы.
Вечером он закончил обновление и полностью заменил рабочую базу тестовой.
Все данные, появившиеся после утреннего копирования, могут быть потеряны.
Поэтому перенос staging в production нельзя воспринимать как безобидную кнопку Сделать основным.
Чем активнее меняются данные сайта, тем аккуратнее нужно переносить изменения.
Для дизайна или программного кода часто разумнее перенести измененные файлы, настройки или конкретные доработки, а не бездумно заменить всю рабочую базу старой тестовой копией.
Еще один вариант размещения staging это технический адрес, предоставленный хостингом.
Он бывает удобен во время переноса сайта на новую площадку. Основной домен пока указывает на старый сервер, а копия уже находится на новом. Владелец проверяет ее по временному адресу и только после успешного тестирования переключает домен.
Такой подход особенно полезен при миграции, потому что позволяет заранее проверить PHP, базу данных, формы, изображения и другие функции нового окружения.
Для сложных проектов staging может размещаться на отдельном сервере или VPS. Это дает больше свободы и позволяет приблизить тестовую среду к рабочей.
Однако небольшому сайту покупать отдельный сервер только ради тестовой копии обычно незачем. Если тариф позволяет создать дополнительный сайт, поддомен и базу данных, существующего виртуального хостинга часто достаточно.
Нужно только учитывать ресурсы.
Полная копия большого сайта занимает дополнительное место на диске и увеличивает количество файлов. Если тариф уже близок к лимиту, клонирование проекта способно привести к нехватке места или inode.
Кроме того, тестовый сайт тоже использует PHP, базу данных и процессорное время, когда с ним работают.
Поэтому перед созданием большой копии полезно посмотреть текущие ограничения тарифа.
Почему тестовый сайт нельзя просто оставить открытым
После создания staging возникает новая проблема: в интернете появляется еще одна версия сайта.
Если открыть test.site.ru может владелец, то при обычной публичной настройке его способен открыть и кто-то другой.
Для тестового окружения это нежелательно сразу по нескольким причинам.
На нем могут находиться незаконченные страницы, сломанная верстка, экспериментальные функции и копии реальных данных. Иногда разработчики используют тестовые учетные записи или оставляют служебную информацию, которую посетители видеть не должны.
Поэтому хороший staging лучше защищать авторизацией.
На виртуальном хостинге для каталога часто можно включить пароль через панель управления. В других случаях доступ ограничивают средствами веб-сервера, приложения или инфраструктуры.
После этого случайный посетитель не увидит тестовую копию без логина и пароля.
Это надежнее, чем просто надеяться, что никто не догадается о существовании адреса test.site.ru.
Отдельно нужно подумать о поисковых системах.
Если тестовая копия практически полностью повторяет основной сайт и доступна роботам, поисковик получает множество дублирующихся страниц на другом адресе.
Этого лучше не допускать.
Самый надежный вариант для внутреннего staging это ограничение доступа авторизацией. Если поисковый робот не может открыть страницы без учетных данных, он не сможет индексировать их содержимое.
Дополнительно в тестовой среде можно использовать запрет индексации. Но не стоит путать SEO-настройки с защитой данных. robots.txt и метатеги предназначены для управления поведением поисковых систем, а не для ограничения доступа посторонних людей.
Если тестовый сайт содержит что-либо конфиденциальное, нужна именно защита доступа.
Есть еще одна опасность, которую легко не заметить: внешние действия.
Представим, что вы скопировали настоящий интернет-магазин вместе с настройками. Тестовая версия может сохранить подключение к платежной системе, CRM, почте, SMS-сервису, службе доставки или API партнера.
Теперь разработчик нажимает на тестовую кнопку оформления заказа.
Если интеграции остались рабочими, в CRM может появиться настоящий заказ, менеджеру придет уведомление, клиенту уйдет письмо или внешний сервис получит реальные данные.
Поэтому перед активным тестированием нужно проверить не только внешний вид сайта, но и все его связи с внешним миром.
На staging желательно использовать тестовые режимы платежных систем и API, отдельные ключи там, где это возможно, или временно отключать интеграции, которые не нужны для проверки.
Особенно осторожно следует обращаться с почтой.
В копии базы интернет-магазина могут находиться адреса настоящих покупателей. Если тестовая система запустит автоматическую рассылку, люди неожиданно получат сообщения от экспериментальной версии магазина.
Похожая ситуация возможна с уведомлениями о заказах, восстановлением пароля и другими автоматическими письмами.
Перед тестированием стоит убедиться, что staging не отправляет сообщения реальным клиентам.
Если для разработки нужны пользовательские данные, желательно также подумать, действительно ли тестовой среде необходима полная копия персональной информации. Для серьезных проектов данные в тестовых системах нередко обезличивают.
Тестовая копия должна быть местом, где ошибаться безопасно. Если одно нажатие на ней способно списать деньги, отправить тысячу писем или изменить рабочую базу, изоляция настроена плохо.
Как безопасно проверить изменения и перенести их на основной сайт
Правильная работа со staging начинается еще до его создания.
Сначала сделайте актуальную резервную копию основного сайта. Это особенно важно, если копирование или дальнейшее развертывание выполняется вручную.
Затем создайте тестовое окружение и убедитесь, что оно действительно отделено от рабочего.
Проверьте базу данных. У staging должны быть свои параметры подключения. Убедитесь, что тестовая версия случайно не записывает информацию в рабочую базу.
После этого ограничьте доступ и закройте копию от индексации.
Проверьте почту, платежи, CRM, вебхуки, внешние API и другие интеграции. Все, что способно повлиять на реальных пользователей или рабочие данные, должно находиться под контролем.
Только теперь можно начинать эксперимент.
Предположим, задача состоит в обновлении CMS и нескольких плагинов.
Сначала обновите тестовую версию. Сам факт появления сообщения Обновление завершено еще ничего не гарантирует.
Откройте главную страницу и основные разделы. Проверьте мобильную версию. Авторизуйтесь в административной панели. Если есть формы, отправьте тестовую заявку.
Для интернет-магазина стоит пройти полный пользовательский сценарий: открыть каталог, воспользоваться поиском и фильтрами, положить товар в корзину, перейти к оформлению заказа и проверить тестовую оплату, если она предусмотрена.
Если на сайте есть личный кабинет, регистрация, загрузка файлов, комментарии или другие важные функции, их тоже нужно проверить.
После изменения версии PHP полезно посмотреть не только страницы сайта, но и журналы ошибок. Внешне проект может работать нормально, а устаревший плагин уже создавать предупреждения или ошибки в фоне.
Если проблема обнаружена на staging, это хороший результат.
Именно для этого копия и создавалась.
Можно спокойно искать причину, возвращать прежнюю версию компонента, менять код и повторять проверку. Основной сайт в это время продолжает обслуживать посетителей.
Когда тесты завершены, наступает самый ответственный этап: перенос изменений.
Способ зависит от того, что именно менялось.
Если обновлялся собственный код, можно перенести соответствующие файлы или развернуть проверенную версию из системы контроля версий.
Если менялись настройки CMS, иногда потребуется повторить их на основном сайте.
Если обновление затрагивает одновременно файлы и структуру базы данных, порядок действий лучше заранее уточнить в документации конкретной CMS или расширения.
Чем сложнее проект, тем опаснее универсальный совет просто скопировать staging поверх рабочего сайта.
Особенно это касается сайтов, где пользователи постоянно создают новые данные.
Интернет-магазин принимает заказы. Форум получает сообщения. Сервис хранит учетные записи и действия пользователей. Сайт записи принимает новые бронирования.
Пока вы работаете на тестовой копии, production продолжает жить.
Поэтому перед развертыванием нужно понимать, какие данные изменились на staging, какие появились на рабочем сайте и что именно будет заменено.
Для небольшого информационного сайта задача значительно проще. Если посетители ничего не записывают в базу, а новые материалы во время тестирования не публиковались, полная синхронизация обычно несет меньше риска.
После переноса обязательно проверьте уже рабочий сайт.
То, что все прекрасно работало на staging, не гарантирует абсолютно идентичный результат на основном адресе. Могут отличаться настройки домена, кеширование, пути, переменные окружения или внешние интеграции.
Проверьте HTTPS, основные страницы, формы, административную панель и критичные функции.
Если использовался кеш, его может потребоваться очистить.
Тестовую копию после завершения работы необязательно удалять. Если сайт регулярно развивается, staging удобно держать постоянно и обновлять перед очередными изменениями.
Но заброшенные копии тоже создают проблемы.
Старая CMS и плагины могут содержать уязвимости. Копия занимает место и файлы на хостинге. В ней могут оставаться старые данные. Поэтому ненужный staging лучше удалить, а постоянный поддерживать и защищать так же внимательно, как другие части инфраструктуры.
При выборе хостинга для активно развиваемого проекта стоит заранее посмотреть, насколько удобно создавать такие окружения. Возможность добавить поддомен, отдельную базу данных и дополнительный сайт уже позволяет организовать простую тестовую копию. Встроенный staging может сделать процесс еще удобнее.
Но сама кнопка создания копии не является гарантией безопасности.
Главное состоит в другом: рабочая и тестовая версии должны быть разделены, тестовый сайт не должен случайно попадать в поиск или взаимодействовать с реальными клиентами, а перенос изменений должен учитывать новые данные, появившиеся на production.
Тогда staging действительно выполняет свою задачу. Вместо эксперимента на живом сайте вы получаете безопасную площадку, где можно обновлять, переделывать и даже ломать проект, пока посетители продолжают пользоваться стабильной рабочей версией.
