Що таке staging і production і чому не можна одразу деплоїти в прод

Уявіть, що ти хірург. І замість того, щоб тренуватися на симуляторі або манекені, ти відкриваєш першого пацієнта, кажучи «а там уже побачимо». Звучить як жах? Так працюють розробники, які деплоять зміни напряму в production.

Production (прод) — це сервер або середовище, яке використовують реальні користувачі. Тут кожен баг, кожна помилка, кожен завислий запит — це вже не твоя приватна проблема, а проблема людини перед екраном.

Staging — це копія production, максимально схожа на справжнє середовище, але без реальних користувачів. Тут ти перевіряєш зміни до того, як вони потраплять у прод.

Проста модель середовищ:

1. Development (dev) — твій локальний комп’ютер. Тут ти пишеш код, ламаєш все, що можна, і лагодиш. Це нормально.
2. Staging — тестовий сервер, де код живе в умовах, близьких до реальних. Тут шукають помилки, які на dev не помітив.
3. Production — останній сервер, яким користуються люди. Тільки перевірене, тільки стабільне.

Чому одного сервера не досить

Якщо у тебе тільки один сервер — і там розробка, і там реальні користувачі — ось що станеться:

• ти зламав щось під час тестування — користувачі не можуть працювати;
• хтось перезавантажив сервер — і розробник втратив свій прогрес;
• конфіги відрізняються, і той код, що працював локально, на сервері падає.

У маленьких проєктах це здається терпимим. Але варто зрости більше однієї людини — і починається хаос.

Як staging має працювати

Головне правило staging: він має бути максимально схожий на production. Якщо на продакшені Docker, PostgreSQL і Node.js — то й на staging має бути те саме, а не якийсь інший стек. Інакше ти перевіряєш одне, а запускаєш інше.

Що має збігатися:

• операційна система і її версія;
• версії мов і фреймворків;
• база даних і її конфігурація;
• nginx / reverse proxy / порти;
• змінні оточення (крім реальних секретів).

Що НЕ має збігатися:

• реальні дані користувачів (на staging — фейкові або анонімізовані);
• реальні платіжні дані й токени;
• email-розсилки (на staging або відключені, або йдуть на тестові адреси).

Практичний приклад: два контейнери, два середовища

Найпростіший спосіб мати dev і staging на одному сервері — Docker:

# docker-compose.staging.yml
services:
  staging-web:
    build: .
    ports:
      - "18081:3000"
    environment:
      - NODE_ENV=staging
      - DB_HOST=staging-db
  staging-db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: staging_password
    volumes:
      - staging-data:/var/lib/postgresql/data

volumes:
  staging-data:

# docker-compose.prod.yml
services:
  prod-web:
    build: .
    ports:
      - "18082:3000"
    environment:
      - NODE_ENV=production
      - DB_HOST=prod-db
  prod-db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: real_secure_password
    volumes:
      - prod-data:/var/lib/postgresql/data

volumes:
  prod-data:

Один сервер, два середовища, два порти. На staging перевіряєш, на production викочуєш.

Чеклист перед деплоєм у production

Не треба 50 пунктів. Треба щоб реально перевіряли:

1. Код зібрався без помилок? — npm run build, docker build або аналог.
2. Smoke test пройшов? — сторінка відкривається, основна логіка працює.
3. База даних мігрувала? — якщо були зміни в схемі БД, переконайся, що міграція пройшла.
4. Змінні оточення правильні? — правильні посилання на БД, правильні ключі.
5. Rollback-план готовий? — якщо щось піде не так як повернутися до старої версії.

Rollback: коли щось пішло не так

Які б тести ти не робив, іноді прод все одно ламається. Тому важливо заздалегідь знати, як повернутися.

З Docker це просто: якщо нова версія контейнера працює неправильно, ти зупиняєш новий і запускаєш попередній образ:

# Якщо щось пішло не так
docker compose down
docker compose up -d --detach-keys="ctrl-p,ctrl-q"  # зі старою версією образу

Якщо ти зберігаєш теги образів (myapp:v1.2.3, myapp:v1.2.4), то rollback — це просто команда з іншим тегом.

Типові помилки

1. Staging і production занадто різні

Найчастіша помилка: на staging все працює, а на production — ні. Тому що staging був на Ubuntu 22, а production на 20. Або Node.js 20 на staging і 18 на production. Різниця в будь-якій дрібниці може зламати все.

2. Статистичні дані на staging

Коли на staging копіюють реальні дані користувачів, це ризик для приватності і безпеки. Якщо хтось отримає доступ до staging, він отримає реальні імена, телефони, паролі. Використовуй фейкові або анонімізовані дані.

3. Немає rollback-плану

«Ми просто відролбачимо» звучить погано, коли ніхто не знає, як це зробити. Rollback має бути продуманий до того, як станеться проблема. І ідеально, якщо він автоматизований.

4. Ігнорувати моніторинг після деплою

Деплой не закінчується, коли код потрапив на сервер. Перші 15-30 хвилин — найкритичніший час. Помилки, витік пам’яті, повільні запити — все це проявляється саме зараз. Дивись логи, метрики і не відходь від клавіатури одразу після деплою.

5. Думати, що «маленька зміна не може зламати»

Найбільші інциденти зазвичай починаються з «дрібної правки». Змінив одну лінію конфігурації — і все впало. Перевіряй все однаково уважно, незалежно від розміру змін.

Висновок / план дії

Staging — це не марна трата часу. Це страховка від катастрофи в production. Навіть якщо у тебе маленький проєкт і один користувач, звичка перевіряти зміни на staging рано чи пізно врятує тебе від дуже неприємної ситуації.

Що зробити найближчим часом:

1. Оціни, чи є у тебе взагалі різні середовища. Якщо тільки один сервер — це перша і найголовніша проблема.
2. Підніми staging хоча б на тому самому сервері, але на іншому порті чи піддомені.
3. Напиши короткий чеклист перед деплоєм у прод і дотримуйся його.
4. Переконайся, що вміш зробити rollback — і що це займає хвилини, не години.
5. Додай моніторинг: після кожного деплою дивись логи й метрики щонайменше 15 хвилин.

Якщо ти робиш щось, що використовують інші люди — staging не необов’язковий. Він обов’язковий. Точка.