Як налаштувати тестове середовище (staging) для вашого застосунку

Щоб налаштувати staging-середовище, розгорніть другу копію застосунку на власному приватному URL, дайте їй окрему базу даних і тестові API-ключі та зробіть так, щоб її налаштування якомога точніше відповідали продакшну. Потім випускайте кожну суттєву зміну спершу на staging, пройдіться найважливішими сценаріями і публікуйте в продакшн, лише коли staging виглядає правильно.

Якщо ця ідея для вас нова, що таке staging-середовище пояснює концепцію. Цей посібник — про практичне налаштування для людей, які створюють застосунки за допомогою інструментів ШІ, а не для команд DevOps.

Dev, staging і продакшн

Для більшості малих застосунків потрібні три місця, навіть якщо перше — це просто попередній перегляд у вашому конструкторі:

Суть staging у тому, що він поводиться як продакшн — той самий код, той самий стек, ті самі типи налаштувань, — але помилка там нікому не шкодить.

Крок 1: Вирішіть, з чим staging має збігатися

Staging корисний лише тоді, коли проблеми проявляються там раніше, ніж у продакшні. Має збігатися:

• Той самий код, який випускається тим самим способом.
• Той самий стек і версії — фреймворк, середовище виконання, тип бази даних.
• Той самий тип конфігурації — ті самі назви змінних середовища з тестовими значеннями.
• Ті самі сервіси — якщо в продакшні є веб-застосунок і API, то й у staging мають бути обидва.

З розміром і даними може бути інакше (менший сервер — це нормально).

Крок 2: Створіть копію

Найпростіший підхід: друге розгортання того самого проєкту за іншим URL, наприклад staging.yourapp.com або yourapp-staging.example.com.

Як це зробити, залежить від вашого хостингу:

• Хостинги з вбудованими попередніми або staging-розгортаннями можуть створити їх автоматично для гілки Git.
• Хостинги без цього: створіть другий застосунок або проєкт із того самого коду й розгорніть його окремо.
• Код у Git: тримайте гілку staging або main, яка розгортається на staging, а в продакшн розгортайте з релізу. Див. як використовувати Git із застосунком, створеним ШІ.

Крок 3: Дайте staging окрему базу даних

Цей крок вас захищає. Якщо staging і продакшн мають спільну базу даних, тест, який видаляє записи, видаляє справжні записи.

• Створіть окрему базу даних для staging.
• Наповніть її seed-даними — реалістичними вигаданими записами, які ШІ може згенерувати для вас.
• Якщо вам потрібна копія продакшн-даних, спершу приберіть або зашифруйте імена, електронні адреси та все персональне.

Напиши seed-скрипт, який наповнює порожню базу даних реалістичними тестовими даними: 20 клієнтів, 50 замовлень у різних станах і два адміністратори. Використовуй очевидно вигадані імена та адреси електронної пошти на example.com.

Перш ніж довіряти налаштуванню, перевірте, до якої бази даних підключається кожна копія. Запитайте прямо:

До якої бази даних підключений цей застосунок і звідки береться це налаштування? Покажи назву змінної, а не пароль.

Крок 4: Використовуйте тестові ключі та окремі налаштування

Усе, що взаємодіє із зовнішнім сервісом, у staging має використовувати тестові облікові дані:

• Платежі у тестовому режимі (наприклад, тестові ключі Stripe), щоб із жодної картки не списувалися справжні гроші.
• Електронні листи надсилаються в пісочницю або лише на вашу власну адресу, щоб клієнти ніколи не отримували тестових повідомлень.
• ШІ та інші платні API з окремим ключем і низьким лімітом витрат.
• Вебхуки, спрямовані на URL staging, а не продакшн.

Тримайте назви змінних однаковими в обох середовищах і змінюйте лише значення. Тоді код не мусить знати, де він запущений. Більше про це — у як зберігати API-ключі в безпеці.

Крок 5: Тримайте staging приватним

Staging не повинен бути публічним:

• Закрийте його логіном, паролем або списком дозволених електронних адрес команди.
• Не дозволяйте пошуковикам індексувати його мета-тегом noindex або заголовком X-Robots-Tag.
• Не посилайтеся на нього з вашого публічного сайту.
• Зробіть його помітно іншим — кольоровий банер «STAGING» не дасть тестувати не в тій вкладці.

Додай яскраво-жовтий банер угорі кожної сторінки з написом «STAGING — лише тестові дані», коли змінна середовища APP_ENV має значення "staging". У цьому випадку також додай мета-тег noindex.

Крок 6: Встановіть рутину випуску

Staging допомагає, лише якщо ви користуєтеся ним щоразу. Проста рутина:

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

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

Крок 7: Обережно змінюйте базу даних

Зміни структури бази даних — додавання стовпця, перейменування таблиці — саме там staging виправдовує себе.

• Спершу проганяйте кожну структурну зміну на staging.
• Перевіряйте, що наявні дані збереглися, а не лише те, що нові функції працюють.
• Зробіть резервну копію продакшну перед тим, як застосувати ту саму зміну там. Див. як зробити резервну копію бази даних застосунку.
• Віддавайте перевагу змінам, які додають, а не перейменовують чи видаляють, щоб стара версія працювала, якщо ви повернетеся назад.

Приклади промптів

Поясни, що станеться з наявними даними, якщо ми застосуємо цю зміну бази даних у продакшні. Щось видаляється або перейменовується?

Зроби так, щоб усі налаштування, залежні від середовища — URL API, ключі, відправник листів, власний URL сайту — бралися зі змінних середовища з однаковими назвами в staging і продакшні. Перелічи їх.

Склади короткий чек-лист сценаріїв, які мені слід перевірити на staging перед кожним релізом, виходячи з того, що робить цей застосунок.

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

• Спільна база даних. Найшкідливіша помилка. Staging завжди отримує власну.
• Бойові ключі в staging. Справжні списання, справжні листи справжнім клієнтам.
• Staging розходиться з продакшном. Різні версії чи налаштування — і staging перестає ловити проблеми.
• Публічний, проіндексований staging-сайт, який з'являється в результатах пошуку поруч з вашим справжнім.
• Пропуск staging для «дрібних» змін. Дрібні зміни теж ламають речі.
• Тестування не в тій вкладці. Помітний банер це вирішує.

Чек-лист

• Staging працює з тим самим кодом, стеком і сервісами, що й продакшн.
• Staging має власну базу даних з тестовими або очищеними даними.
• Платежі, електронна пошта та платні API використовують тестові ключі в staging.
• Назви змінних збігаються між середовищами; відрізняються лише значення.
• Staging закритий логіном або паролем і не індексується.
• Банер показує, що ви на staging.
• Кожен випуск спершу йде на staging із письмовим списком сценаріїв для перевірки.
• Зміни бази даних спершу застосовуються на staging, а перед випуском є резервна копія продакшну.

Staging у Mythex

Функція Publish у Mythex дає один живий URL для кожного застосунку; окремого перемикача staging немає. На практиці у вас є два варіанти:

• Попередній перегляд як перевірка перед випуском. Кожен проєкт працює в приватному хмарному робочому просторі з живим переглядом. /test дозволяє агенту пройтися по ньому, як користувачеві, а посилання Share дає клієнту або колезі змогу переглянути попередній перегляд без публікації. Див. Preview and Code. Для багатьох індивідуальних проєктів цього достатньо.
• Другий проєкт як staging. На Pro експортуйте проєкт, імпортуйте його в новий проєкт, дайте цьому проєкту власну базу даних і секрети з тестовими ключами та опублікуйте його за власним slug. Випускайте зміни туди, перш ніж публікувати основний проєкт.

У будь-якому разі перед тим, як тестувати щось руйнівне, запитайте агента, яку базу даних використовують попередній перегляд і опублікований застосунок, а для відкату поганої зміни користуйтеся контрольними точками. Ширше про запуск застосунку в продакшн — у як перевести ШІ-прототип у продакшн.

Запитання