01
ERP тестується «в бою»
Вебхуки, резерви, маршрути, ануляції та повернення перевіряються на живих замовленнях, які мають поїхати клієнтам.
Оновлення Pro · Staging
Спочатку — на копії. Потім — у бою.
Staging — робоча копія вашого магазину на окремому домені. Нову вітрину, інтеграцію з обліковою системою, реліз платформи чи власний код перевіряєте тут, поки бойовий сайт спокійно приймає замовлення.
3–5
днів на розгортання
Pro
входить у пакет оновлень
0
тестових замовлень у prod
Два незалежні контури
prod працює Prod
{shop}.ua
Клієнти купують
- живі замовлення
- бойова ERP
- реальні оплати
Staging
staging.{shop}.ua
Команда перевіряє
- пробні замовлення
- тестова ERP
- новий код
У prod переходить лише перевірене. До вашого підтвердження бойовий контур не змінюється.
Звернення в підтримку
Знайомі ситуації?
Ці сценарії повторювались у реальній роботі магазинів. Спільне в них одне: не було місця, де зміни можна безпечно спробувати заздалегідь.
02
Оновлення зачепило власні доробки
Новий реліз конфліктує з кодом магазину. Про зниклу функцію команда дізнається вже під час роботи, а не під час перевірки.
03
Розробка власних інтеграцій через API сайту
Зовнішній розробник перевіряє API-запити, вебхуки й створення замовлень на копії — без потрапляння тестових даних у реальну роботу магазину.
04
Нова вітрина ризикує SEO
Змінився URL, мовний префікс чи мікророзмітка — куплені посилання ведуть у нікуди, а пошуковий трафік реагує після запуску.
Що це
Другий магазин, якого нікому не видно
Піднімаємо копію сайту й бази на staging-піддомені. Вона виглядає та поводиться як ваш магазин, але її дані відокремлені від бойової бази, а вхід закритий паролем.
Ваші дані, а не демо
Товари, замовлення, користувачі й налаштування з копії вашої бази — сценарії відтворюються на знайомих даних.
Окремо від продажів
Зміни на staging не змінюють бойову базу. Тут можна створювати пробні замовлення, перебудовувати процес і повертатися назад.
Закрито від сторонніх
HTTP-авторизація не пускає покупців і пошукових роботів. Доступи отримує лише ваша команда та залучені підрядники.
Оновлюється разом із платформою
Релізи спершу можна побачити на копії, пройти свої критичні сценарії й лише тоді погодити зміни на prod.
Staging ізолює сайт і його дані. Щоб ізолювати весь бізнес-процес, зовнішні системи також мають працювати в тестовому режимі — насамперед ваша облікова система.
Процес
Чотири кроки замість одного ризикованого
Зміна проходить однаковий передбачуваний цикл — від копії до бойового сайту. Контрольний момент між ними — ваше підтвердження.
-
Розгортаємо копію
Піднімаємо staging-піддомен із копією бази та видаємо доступи до сайту й адмінки. Свіжий зріз даних оновлюємо за запитом.
-
Викочуємо зміни туди
Нова функція, фікс, реліз платформи або версія вітрини спочатку зʼявляється на staging. Prod у цей момент не змінюється.
-
Ви перевіряєте
Менеджери та інтегратори проходять свої сценарії: замовлення, обмін, доставку, оплату, повернення, SEO й роботу кастомного коду.
-
Переносимо перевірене
Після вашого «все гаразд» плануємо prod. Якщо результат не підходить — не переносимо або допрацьовуємо на копії.
Невеликий реліз може пройти цикл за один вечір. Велика міграція живе на staging стільки, скільки потрібно команді для перевірки.
Сценарії
Коли staging справді окупається
Не кожній зміні потрібен окремий контур. Але в цих сценаріях ціна помилки вища за ціну перевірки.
Перехід на нову версію
Команда й SEO-підрядник сканують сайт, звіряють URL, мовні версії, robots.txt і мікророзмітку до перемикання домену.
Інтеграція з обліком
Окремі вебхуки, ключі та пробні замовлення для статусів, резервів, маршрутів, ануляцій, ПРРО й повернень.
Власні доопрацювання
Розробник бачить конфлікти з новою версією платформи до prod і переносить свій код у зручний для команди момент.
Навчання менеджерів
Команда вчиться на новому процесі та збирає зауваження без ризику випадково змінити реальне замовлення.
Робота підрядників
Інтегратор, SEO-агенція чи зовнішній розробник отримує копію для пробних запитів замість доступу до живого контуру.
З практики
Знайшли до того, як побачили покупці
Знеособлені приклади з робочих звернень. Тут важливі не назви магазинів, а наслідки, яких вдалося уникнути.
34 838
викликів тестового вебхука
Помилковий цикл знайшли на staging. На бойовому сайті це був би інцидент; на копії — сигнал переробити логіку.
1 вечір
на повернення старої версії
Після запуску нова вітрина потребувала доробок. Бойовий домен повернули на перевірену версію, нову лишили на staging.
SEO URL
перевірили на відповідність
До запуску помітили зміну URL, яка знецінила б зовнішні посилання. Маршрути виправили до перемикання.
аванс
без подвійної оплати
Сценарій «аванс → ануляція → повторне узгодження» прогнали в кількох варіантах до ввімкнення на реальних замовленнях.
Кейси знеособлено; числові значення та послідовність подій збережено.
Комплектація
Що ви отримуєте технічно
Не просто ще один домен, а керований тестовий контур із доступами, даними та правилами перенесення змін.
Окремий staging-піддомен із копією сайту й бази даних
Актуалізація копії бойової бази за запитом
Окрема адмінка з повними правами
HTTP-авторизація від покупців і пошукових роботів
Доступи в налаштуваннях сайту, у вкладці «Інформація»
Окремі API-ключі та URL вебхуків для інтеграцій
Релізи платформи на staging так само, як на prod
Вибір: зберегти або скинути ERP-звʼязки під час оновлення бази
Можливість відтворювати prod-сценарії на копії замовлень
План перевірки й перенесення змін після вашого підтвердження
Staging працює поверх керованої інфраструктури
Ми контролюємо розгортання, доступи та оновлення тестового контуру. Якщо сайт зараз на власному хостингу, спочатку плануємо перехід на керований сервер.
Дві ролі
Одна копія — дві мови цінності
Власнику важлива керованість ризику. Інтегратору — ізольовані дані, ключі та можливість повторити складний сценарій.
Бізнес
Власнику магазину
- Бачите зміни раніше за покупців
- Самі погоджуєте дату переходу
- Навчаєте менеджерів на копії
- Маєте сценарій повернення
- Не ставите продажі на паузу заради тесту
Технічний контур
Інтегратору або розробнику
- Окремі вебхуки й API-ключі
- Відтворення інцидентів на копії замовлення
- Ручний повторний запуск вебхуків
- Перевірка сумісності кастомного коду
- Тестові API-замовлення поза prod
Маєте власного розробника? Подивіться, як у Sol.parts влаштовані технічний стек і шар кастомізацій.
Інженерна чесність
Чого staging не робить
Staging знижує ризик, але не перетворює складну зміну на магію. Ці межі краще знати до підключення, а не після.
Не дзеркало в реальному часі
Дані відповідають моменту останньої актуалізації, а не змінюються синхронно з prod.
Фото не дублюються
Зображення товарів віддаються з бойового сайту; окрема робота з ними на копії не передбачена.
Зовнішні сервіси можуть відрізнятися
Перевізники, повідомлення й перевірки контрагентів можуть бути вимкнені або працювати з іншими ключами.
Тестова ERP потрібна окремо
Для повної ізоляції обміну потрібна тестова база вашої облікової системи, синхронізована з копією сайту.
Власний код переносить ваш розробник
Ми оновлюємо еталонну платформу на staging, але не переносимо автоматично сторонні доробки на prod.
Лише на керованому сервері
Staging не розгортається на власному хостингу клієнта — інфраструктуру маємо контролювати ми.
Не замінює фінальну перевірку
Копія суттєво знижує ризик, але після перемикання критичні сценарії все одно перевіряються на prod.
ЧаПи
Часті питання
Ні. Staging використовує окрему копію бази. Зміни даних і налаштувань на копії не змінюють бойовий магазин. Для повної ізоляції зовнішніх інтеграцій використовуються окремі API-ключі, вебхуки й тестова база облікової системи.
Це зріз бойової бази на момент розгортання або останньої актуалізації. Оновлюємо його за вашим запитом; за досвідом, копіювання займає близько 40 хвилин. Перед актуалізацією погоджуємо, чи зберігати звʼязки з обліковою системою.
Ні. Staging закритий HTTP-авторизацією. Доступ мають лише люди, яким ви передали логін і пароль.
Каталог і крос-номери містяться в копії бази. Великий масив фотографій окремо не дублюється: зображення підтягуються з бойового сайту, тому каталог виглядає повним, але працювати з фото на staging не можна.
Так, це один із головних сценаріїв. Staging має окремі URL вебхуків та API-ключі. Щоб ізолювати весь цикл, потрібна також тестова база вашої ERP: тоді пробні замовлення, статуси й повернення не потрапляють у бойовий облік.
Ми оновлюємо staging, не чіпаючи prod. Ваш розробник бачить конфлікти заздалегідь, перевіряє сумісність і переносить свої зміни на бойовий сайт, коли вони готові. Автоматичне перенесення стороннього коду до послуги не входить.
Так, план повернення погоджується до перемикання. На практиці ми вже повертали бойовий домен на попередню версію того самого дня, а доробки нової продовжували на staging.
Ви. Ми викочуємо зміни на staging і чекаємо підтвердження після перевірки ваших сценаріїв. Якщо результат не влаштовує, зміни не переходять на бойовий сайт.
Зазвичай 3–5 днів після підключення пакета «Оновлення Pro». Якщо магазин ще не на керованому сервері, окремо плануємо міграцію.
Ні. Демо показує можливості платформи на умовних даних. Staging — робоча копія саме вашого магазину з вашими товарами, замовленнями й налаштуваннями.
Наступний крок
Наступне оновлення можна зустріти спокійно
Розкажіть, що плануєте: міграцію вітрини, інтеграцію з обліковою системою чи власні доопрацювання. Підкажемо, чи потрібен вам staging і як виглядатиме процес.