Разрабатывать сайт прямо на рабочем домене удобно ровно до первой серьезной ошибки. Неудачное обновление, эксперимент с кодом или изменение базы данных может превратить обычную задачу разработчика в аварию, которую уже видят посетители.
Поэтому между компьютером разработчика и рабочим сайтом полезно иметь еще одну среду. В ней можно собирать новые страницы, проверять обновления, экспериментировать с PHP, тестировать плагины и показывать результат заказчику, не затрагивая основной проект.
Такую площадку часто называют тестовым хостингом, тестовым сервером или staging. Термины немного различаются, но задача одна: получить отдельную версию сайта, на которой разрешено ошибаться.
Покупать для нее мощный сервер обычно не требуется. Небольшому сайту может хватить поддомена на существующем хостинге, отдельного дешевого тарифа или встроенной функции создания тестовой копии. Для разработки веб-приложения требования будут другими.
Главное не выбрать самый дешевый тестовый хостинг, а понять, насколько точно он должен повторять условия, в которых потом будет работать настоящий сайт.
Когда localhost достаточно, а когда нужен тестовый хостинг
Разработку удобно начинать локально. Сайт находится на компьютере разработчика и не доступен обычным пользователям из интернета.
Для этого устанавливают локальное серверное окружение или используют контейнеры и другие инструменты разработки. Можно запускать PHP, базу данных, веб-сервер и собирать проект практически так же, как на настоящем сервере.
У локальной разработки есть очевидное преимущество: интернет для большинства операций не нужен, изменения выполняются быстро, а эксперимент никак не затронет рабочий сайт.
Но у localhost есть принципиальное ограничение. Он локальный.
Если сайт делает один человек для себя, этого может быть достаточно почти до момента публикации. Если над проектом работает команда или результат нужно регулярно показывать заказчику, становится неудобно.
Можно отправлять скриншоты и записывать видео, но они не позволяют нормально проверить сайт. Заказчику хочется открыть его со своего телефона, пройти меню, отправить форму и посмотреть разные страницы.
В этот момент появляется тестовый хостинг.
Сайт уже работает на удаленном сервере и доступен через интернет, но еще не считается публичной рабочей версией.
Например, основной проект находится по адресу example.ru, а тестовая версия работает на dev.example.ru. Можно использовать и отдельный технический домен, который вообще не связан с будущим адресом сайта.
Такой вариант удобен не только во время первоначальной разработки.
Представим интернет-магазин, который уже принимает заказы. Нужно установить новую версию CMS и одновременно изменить оформление карточки товара.
Проводить оба эксперимента на рабочем сайте рискованно.
Сначала создается копия в тестовой среде. На ней устанавливаются обновления, проверяется каталог, корзина, оформление заказа, мобильная версия и другие важные функции. Если все работает, изменения переносятся на основной сайт.
Получается три логических этапа.
- Локальная среда удобна для ежедневной разработки на компьютере.
- Тестовый сервер нужен для проверки проекта в условиях, близких к настоящим, совместной работы и демонстрации.
- Рабочий сервер обслуживает реальных посетителей.
Не каждому проекту нужны все три. Для небольшой статической страницы отдельный staging может быть избыточным. Для интернет-магазина, сервиса или активно развиваемого корпоративного сайта разделение сред уже намного полезнее.
Каким должен быть хостинг для разработки и тестирования
Требования зависят от того, что именно вы собираетесь проверять.
Если дизайнеру нужно показать заказчику сверстанный HTML-сайт, подойдет практически любой простой хостинг. Для проекта на CMS уже понадобится PHP и база данных. Для приложения на Python или Node.js обычного виртуального тарифа может оказаться недостаточно.
Есть важное правило: чем ближе тестирование к окончательному запуску, тем сильнее тестовая среда должна напоминать рабочую.
Допустим, сайт разрабатывается на одной версии PHP, а после публикации будет работать на другой. Все выглядит нормально на тестах, но после переноса неожиданно появляются ошибки совместимости.
То же относится к базе данных, расширениям PHP, веб-серверу и другим компонентам.
Полного совпадения добиться нужно не всегда. Если разработчик меняет только CSS, различия серверов практически не имеют значения. Если проверяется обновление CMS или сложное приложение, окружение становится гораздо важнее.
Отдельная версия PHP
Для сайтов на PHP удобно, когда версию можно менять независимо от основного проекта.
Например, рабочий сайт пока использует старое окружение. На тестовой копии можно переключить PHP, обновить CMS и плагины, проверить ошибки и только после этого повторить изменение на основном сайте.
Так обновление превращается из эксперимента на посетителях в нормальную техническую процедуру.
База данных
Тестовый сайт должен использовать отдельную базу данных.
Подключать тестовую копию к рабочей базе опасно. Разработчик может удалить запись, изменить структуру таблицы или запустить операцию, которая затронет реальные данные.
Для проверки можно создать копию рабочей базы, предварительно подумав о конфиденциальной информации.
Особенно осторожно нужно обращаться с базами интернет-магазинов, личных кабинетов и сервисов, где хранятся персональные или другие чувствительные данные. Реальная пользовательская база не должна без необходимости разъезжаться по тестовым серверам и компьютерам разработчиков.
SSH, SFTP и Git
Для обычного владельца сайта SSH может быть необязательным. Разработчику он значительно полезнее.
Через командную строку можно работать с файлами, запускать служебные команды, использовать Composer и выполнять другие операции, если они разрешены тарифом.
SFTP удобен для безопасной передачи файлов.
Если проект хранится в Git, тестовый сервер можно связать с процессом разработки так, чтобы новые версии развертывались более предсказуемо. Необязательно сразу строить сложную автоматизацию. Даже простой порядок с репозиторием обычно надежнее, чем ситуация, когда неизвестно, какая копия файла сейчас лежит на сервере.
Резервные копии
Может показаться, что тестовому сайту резервное копирование не нужно. В конце концов, он тестовый.
Это верно только в том случае, если всю среду действительно можно быстро восстановить из исходного кода и других сохраненных данных.
На практике на тестовой площадке иногда неделями выполняется работа, меняется база, загружается контент и настраивается CMS. Потерять все это за день до демонстрации заказчику будет неприятно.
Поэтому резервные копии полезны и здесь. Просто требования к частоте хранения могут быть мягче, чем у рабочего проекта.
Возможность быстро создать и удалить сайт
Для разработчика особенно ценна не огромная квота диска, а удобство.
Создать поддомен, выпустить SSL, добавить базу, получить SFTP-доступ, развернуть проект и после окончания работы удалить его должно быть несложно.
Если каждое действие требует обращения в поддержку, тестовая площадка быстро начинает мешать разработке.
Как показать тестовый сайт заказчику и не открыть его всему интернету
Как только тестовая версия появляется на публичном сервере, возникает новая проблема: ее способны увидеть не только разработчики.
Адрес может случайно попасть в историю браузера, логи, аналитику, внешние ссылки или поисковые системы.
Особенно неприятна индексация.
Представим, что на dev.example.ru находится почти точная копия рабочего сайта. Поисковый робот обнаруживает ее и начинает добавлять страницы в индекс. В результате в поиске появляется техническая версия с тестовыми текстами или копиями существующих страниц.
Поэтому тестовый сайт нужно закрывать до начала работы, а не после того, как он уже обнаружен.
Одного robots.txt для надежного ограничения доступа недостаточно. Этот файл прежде всего дает инструкции поисковым роботам, но не является системой авторизации.
Если тестовую площадку не должен видеть посторонний человек, лучше защитить ее паролем на уровне веб-сервера или средствами хостинга.
Тогда при открытии адреса сначала потребуется авторизация.
Это удобно и для заказчика. Ему можно передать адрес тестового сайта и отдельные данные для входа. Он сможет самостоятельно посмотреть проект, а случайный посетитель внутрь не попадет.
Дополнительно для HTML-страниц можно использовать запрет индексации через meta robots или HTTP-заголовок X-Robots-Tag там, где это уместно.
Но защита паролем решает задачу фундаментальнее: поисковый робот вообще не получает содержимое закрытой страницы.
Не забудьте про HTTPS.
Тестовый статус сайта не означает, что пароли и данные нужно передавать по незашифрованному соединению. Бесплатного SSL-сертификата для такой площадки обычно достаточно.
Есть еще один момент, который легко пропустить: отправка сообщений.
Копия интернет-магазина может содержать настоящие адреса электронной почты клиентов. Если на ней начать тестировать заказы или уведомления, система способна отправить реальные письма.
То же относится к SMS, платежам, CRM, API и другим внешним интеграциям.
В хорошей тестовой среде такие подключения либо отключаются, либо переводятся в предусмотренный сервисом тестовый режим.
Нажатие кнопки Купить на staging не должно случайно создавать настоящий заказ, списывать деньги или отправлять клиенту уведомление.
Когда покупать отдельный тестовый хостинг
Самый простой вариант для небольшого проекта — использовать существующий хостинг.
Если тариф позволяет создать несколько сайтов и баз данных, можно добавить отдельный поддомен, разместить там копию и закрыть ее от посторонних.
Это дешево и удобно, но есть недостаток: тестовая и рабочая версии используют ресурсы одной учетной записи.
Тяжелая операция на тестовом сайте способна создать нагрузку и повлиять на production. Кроме того, уровень изоляции зависит от устройства конкретного хостинга.
Для небольшого корпоративного сайта такой вариант часто приемлем. Для важного коммерческого проекта лучше относиться к нему осторожнее.
Второй вариант — отдельный аккаунт виртуального хостинга.
Он удобен, когда нужно отделить разработку от рабочего проекта, но полноценный VPS не требуется. Можно выбрать похожее серверное окружение и спокойно экспериментировать, не расходуя ресурсы основного аккаунта.
Третий вариант — staging, который создает сам хостинг.
Некоторые панели и платформы умеют клонировать рабочий сайт в тестовую среду и затем помогают переносить изменения обратно. Для WordPress и других CMS это может заметно упростить работу.
Но перед использованием нужно понять, что именно копируется и как происходит обратная синхронизация.
Особенно осторожно следует переносить базы данных.
Пока разработчик неделю менял дизайн на тестовой копии интернет-магазина, на рабочем сайте появлялись новые заказы и пользователи. Если просто заменить production базой из staging, свежие данные можно потерять.
Поэтому кнопка перенести изменения не отменяет понимания того, какие именно данные меняются.
Для веб-приложений и сложных проектов тестовая среда часто создается на VPS или в облачной инфраструктуре. Здесь можно точнее воспроизвести production, использовать контейнеры, автоматическое развертывание и отдельные сервисы.
Но покупать VPS для тестирования обычного сайта на WordPress только ради профессионального вида нет необходимости.
Выбирайте самый простой вариант, который позволяет безопасно решить задачу.
Если вы делаете небольшой сайт самостоятельно, начинайте локально и переносите его на хостинг перед запуском. Если проект нужно показывать заказчику, создайте закрытую тестовую площадку. Если рабочий сайт постоянно развивается, имеет смысл держать staging постоянно. Если разрабатывается сложное приложение, тестовое окружение лучше проектировать вместе с основной инфраструктурой.
И обязательно определите момент, когда тестовая площадка перестает быть нужна.
После запуска в интернете остаются тысячи забытых поддоменов вида test, dev, old и staging. На них годами работают старые версии CMS, плагины и тестовые учетные записи.
Такая копия уже ничего не тестирует, но продолжает существовать и увеличивает поверхность атаки.
Если staging используется постоянно, его нужно обновлять и контролировать. Если он создавался только для разработки конкретной версии сайта, после завершения работы его лучше удалить.
Тестовый хостинг полезен не потому, что разработчику нужен еще один сервер. Его ценность в разделении среды, где можно экспериментировать, и среды, которой пользуются реальные люди.
На localhost удобно писать код. На закрытом тестовом сервере удобно проверять сайт и показывать его заказчику. На рабочем хостинге должна находиться уже проверенная версия.
Чем важнее сайт для бизнеса, тем полезнее это разделение. Оно не защищает от всех ошибок, но позволяет обнаружить значительную их часть до того, как ошибку увидят посетители.
