Привет! Если ты когда-нибудь деплоил сайт или пилил сервис, то наверняка слышал про dev/test/prod окружения. Но вот как их грамотно разрулить на хостинге — вопрос, который часто вызывает ступор даже у опытных вебмастеров и системных админов. Давай разберёмся, зачем это вообще нужно, как всё настроить по уму и какие грабли поджидают на пути.

Зачем нужны разные окружения: dev, test, prod?

Сценарий простой: ты пишешь код, тестируешь, выкатываешь. Но если всё делать на одном сервере, то:

• Клиенты видят твои баги и эксперименты (а это фейл).
• Тестовая база портит продовые данные.
• Ломается что-то важное — и всё, минус репутация.

Поэтому нормальные пацаны (и девчата) всегда делают три (или хотя бы два) окружения:

• Development (dev) — тут творишь без оглядки, всё ломается, фича-бренчится, тестится локально или на сервере для команды.
• Testing/Staging (test) — максимально близко к продакшену, но не для реальных пользователей. Можно давать тестерам, SEO-шникам, заказчику.
• Production (prod) — боевой сервер, всё строго, только проверенный код и реальные данные.

Как это реализовать на хостинге: схемы и подходы

Вариант 1. Три отдельных сервера (идеал, но дорого)

• Каждое окружение — на своём VPS/VDS или выделенном сервере.
• Плюсы: максимальная изоляция, безопасность, можно настраивать всё по отдельности.
• Минусы: дорого, не всегда оправдано для небольших проектов.

Вариант 2. Один сервер, разные папки/поддомены (реально и удобно)

• Один VPS/shared-хостинг, но три сайта: dev.site.ru, test.site.ru, site.ru.
• В каждом — своя папка, база данных, конфиги.
• Плюсы: экономия, быстрое развертывание, удобно для малых/средних проектов.
• Минусы: риск случайно залить dev-код на prod, возможны конфликты зависимостей.

Вариант 3. Docker-контейнеры (современно и гибко)

• На одном сервере крутятся изолированные контейнеры под каждое окружение.
• Удобно держать разные версии PHP, Node, базы и т.д.
• Плюсы: изоляция, масштабируемость, DevOps-стайл.
• Минусы: надо уметь с Docker, не везде поддерживается на shared-хостинге.

Вариант 4. Git-ветки + автоматический деплой

• Связываешь ветки репозитория с разными папками/окружениями на сервере.
• Например:
  
main/master — прод
develop — тест
feature/* — дев

• Плюсы: удобно для командной работы, легко откатывать изменения.
• Минусы: требует CI/CD-систему (например, GitHub Actions, Buddy или GitLab CI).

Практика: как настроить dev/test/prod окружения на хостинге

1. Организация структуры на сервере

/home/youruser/
├── dev.site.ru/
├── test.site.ru/
└── site.ru/

Для каждого окружения — отдельная папка, отдельный .env или config.php. В идеале — разные базы данных и доступы.

2. Настройка поддоменов

• В панели управления хостингом (ISPmanager, cPanel, DirectAdmin и т.д.) добавляешь поддомены dev.site.ru и test.site.ru.
• Указываешь путь к соответствующей папке.
• В DNS прописываешь A-записи (или CNAME, если нужно).

3. Разделение конфигов и секретов

Никогда не используй одну базу для всех окружений! Для каждого — своя база, свои пользователи и пароли. Идеально — хранить секреты в .env (Laravel, Symfony, Node.js), или в отдельных файлах вне веб-директории.

DB_HOST=localhost
DB_NAME=site_dev
DB_USER=dev_user
DB_PASS=********

4. Автоматизация деплоя

Ручками заливать файлы — прошлый век. Используй Git и авто-деплой:

# Пример деплоя через git hook
cd /home/youruser/dev.site.ru
git pull origin develop
composer install
php artisan migrate

Или подключи Buddy, GitHub Actions Deploy to FTP, DeployBot.

5. Ограничь доступ к dev/test

• Закрой dev и test окружения по IP или basic-авторизацией.
• В .htaccess для Apache:
  
AuthType Basic
AuthName "Restricted"
AuthUserFile /home/youruser/.htpasswd
Require valid-user

• Для Nginx — через auth_basic или ограничение по IP:
  
location / {
allow 192.168.1.0/24;
deny all;
}

• Иначе поисковики могут проиндексировать твой dev-сайт или тестовые дубли!

Плюсы и минусы разных подходов (кейсы из жизни)

Позитивный кейс (реальный опыт)

У клиента был интернет-магазин на OpenCart. Внедрили dev/test/prod на одном VPS с разными поддоменами и базами. В результате:

• Баги ловились на тесте, а не на проде.
• SEO-шник спокойно тестировал микроразметку на staging, не боясь сломать основной сайт.
• Внедрение новых фич стало быстрее — не надо было делать ночные выкладки.

Негативный кейс (грабли новичков)

Владелец сайта держал dev и prod на одной базе (экономил место). Однажды тестировщик случайно удалил полтаблицы — и на боевом сайте пропали товары. Итог — потеря продаж, куча ругани.

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

• Ошибка: Использовать одну и ту же базу для всех окружений.
• Ошибка: Держать dev/test открытыми для всех (дубли в поиске, утечка данных, санкции от Яндекса/Google).
• Миф: “Маленькому сайту не нужно dev/test”. На самом деле, даже для лендинга полезно иметь тестовую площадку.
• Ошибка: Не делать бэкапы dev/test окружений. Иногда там тоже важные данные (например, тестовые заказы).
• Миф: “На shared-хостинге нельзя сделать dev/test/prod”. Можно! Просто через поддомены и папки.

Советы по выбору хостинга для dev/test/prod

• Ищи тарифы с поддержкой неограниченных сайтов/поддоменов.
• Проверь, можно ли создавать несколько баз данных.
• Обрати внимание на возможность подключения по SSH, поддержки Git, Composer, Docker (если нужно).
• Хорошо, если у хостера есть staging-функция (например, Beget Staging).
• Проверь, не запрещает ли хостер держать тестовые сайты (редко, но бывает в ToS).

Похожие решения и альтернативы

• Локальная разработка (Laragon, XAMPP, Docker Desktop): удобно, но обязательно нужен отдельный сервер для теста перед продом.
• Сервисы для staging: Netlify, Vercel (для фронта), Heroku (для бэка). Подходят для pet-проектов или MVP.
• CI/CD платформы: GitHub Actions, GitLab, CircleCI — для автоматизации деплоя.

Заключение: как правильно организовать dev/test/prod на хостинге?

Подытожим: грамотная организация dev/test/prod окружений — это не понты, а реальная защита от багов, фейлов и потери репутации. Даже если у тебя небольшой сайт, выдели поддомены, разнеси базы, настрой доступы и автоматизируй деплой. Это сэкономит тебе кучу времени и нервов.

Для новичков и небольших проектов хватит обычного shared-хостинга с поддержкой поддоменов и нескольких баз. Для сложных — бери VPS/VDS и строй инфраструктуру на Docker, с CI/CD.

Не забывай про безопасность: dev и test должны быть закрыты от внешнего мира и поисковиков. И всегда делай бэкапы.

Если хочешь примеры настроек под твой стек — пиши в комменты (или гугли официальные доки, например Laravel .env, Docker Compose, PHP-FPM configs).

Удачных деплоев и минимум багов! 🚀

---

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

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