Как организовать staging-окружение на VPS — мой опыт и советы

Если честно, я пришла к идее настроить staging не сразу. Сначала всё тестировала “в проде” (да-да, тот самый “жареный способ”), а потом — когда один неудачный деплой положил сайт клиента на целые сутки — поняла, что так больше нельзя. И вот с тех пор staging стал для меня обязательной частью всех проектов, даже самых простых.

Что вообще такое staging?

Если по-простому, staging — это промежуточная среда между разработкой (dev) и продакшеном (prod), в которой вы можете протестировать всё “почти как в бою”, но без риска всё сломать.

Условно это выглядит так:

КопироватьDev → Staging → Prod

В staging-среде код уже собран, база подключена, интерфейс работает, но всё это развернуто отдельно от “боевого” сайта. Это как генеральная репетиция перед премьерой. Всё видно, всё можно пощупать, но пока что без зрителей.

---

Зачем он вообще нужен?

На своём опыте могу сказать: staging-окружение спасало мне и нервы, и репутацию.

Вот несколько примеров:

• Один раз staging помог поймать баг, который возникал только при включённом кешировании — в проде он бы улетел в лицо пользователю.
• В другой раз staging оказался идеальной песочницей для дизайнеров, которым нужно было “поиграться” с CSS без страха сломать основной сайт.
• И наконец, staging помогает выстроить понятный, безопасный workflow с деплоями — особенно если ты работаешь в команде или для клиентов.

---

Что понадобится для staging-среды?

• VPS (желательно отдельный от production, но можно и на том же, если ресурсов хватает);
• Docker (не обязателен, но сильно упрощает работу);
• Git + CI/CD (например, GitHub Actions, GitLab CI или даже простой shell-скрипт);
• Умение грамотно разруливать окружения:
  Копировать.env
  , конфиги, переменные и т.д.;
• Немного времени и дисциплины — но оно того стоит!

---

Настройка staging с нуля: мой реальный сценарий

Структура директорий и подход

Я люблю держать staging и production в изоляции. Если это один VPS, создаю две папки:

Копировать/var/www/project-prod
/var/www/project-staging

Каждая из них — это отдельный сайт с собственным

-конфигом, отдельной базой, переменными окружения и логами. Никогда не свожу всё в одну кучу — иначе staging теряет смысл.

Если проект большой, staging разворачиваю на отдельном VPS, особенно если клиенту важно “видеть” результат.

---

Отдельная база данных

Сразу заводите отдельную базу:

Копироватьproject_staging_db

И обязательно подключайте к ней staging-окружение. Иногда полезно клонировать базу с продакшена для полноценных тестов. В этом случае:

Копироватьmysqldump -u root -p project_prod_db > dump.sql
mysql -u root -p project_staging_db < dump.sql

Только не забудьте после этого удалить e-mail пользователей и токены, если это живой проект!

---

Конфигурация nginx для staging

Вот минимальный

-конфиг, который я использую:

Копироватьserver {
    listen 80;
    server_name staging.example.com;

    root /var/www/project-staging/public;

    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
    }

    access_log /var/log/nginx/staging.access.log;
    error_log /var/log/nginx/staging.error.log;
}

Если вы используете SSL — подключите Let’s Encrypt. Но я иногда просто делаю локальный сертификат, если staging только для себя.

---

Не забудьте про защиту

Обязательно закройте staging от случайных посетителей. Я использую HTTP Basic Auth:

Копироватьsudo apt install apache2-utils
htpasswd -c /etc/nginx/.htpasswd user

И добавьте в

:

Копироватьauth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;

Также в

:

КопироватьUser-agent: *
Disallow: /

И даже добавляю

в шаблона, на всякий случай.

---

CI/CD: как деплоить в staging автоматически

Я использую GitHub Actions. Вот простой

:

Копироватьname: Deploy to Staging

on:
  push:
    branches:
      - develop

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v0.1.2
        with:
          host: ${{ secrets.STAGING_HOST }}
          username: ${{ secrets.STAGING_USER }}
          key: ${{ secrets.STAGING_SSH_KEY }}
          script: |
            cd /var/www/project-staging
            git pull origin develop
            php artisan migrate --force

На каждый

в у меня обновляется staging. Главное — не путайте его с или ветками!

---

Как отличать staging от продакшена?

Это важно! Не делайте staging копией продакшена “в лицо”.

Вот мои приёмы:

• Ставлю баннер “Вы в тестовой версии” сверху;
• Меняю цвет кнопки логина или заголовка;
• Подменяю e-mail на
  Копировать@staging.local
  ;
• В футере указываю дату билда.

Бывали случаи, когда клиенты путали staging и писали “а где мои заказы?” — с тех пор делаю максимально явно.

---

Что НЕ стоит делать в staging

• Не подключайте боевые API-ключи. Особенно платёжки — один тест, и вы улетите в минус.
• Не пересекайте логику с production. Никаких общих cron-задач или очередей.
• Не открывайте staging всему миру. Он для вас или команды, не для поисковиков.

---

На своём опыте скажу: staging — это не прихоть, а необходимость, если вы хотите разрабатывать “по-взрослому”. Пусть даже вы работаете один, staging помогает:

• протестировать фичи до релиза;
• собирать UI без страха всё сломать;
• показать результат клиенту.

И пусть кажется, что “это всё лишнее”, но один фейл в проде — и вы точно пересмотрите взгляды.

---