Немає тестового середовища: чому не варто тихцем латати живий сайт

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

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

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

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

1. В одному рядку чату три різні рішення

«На продакшені зламалось, поправимо вночі, тестового середовища немає». Баг — це екран і хибний результат. Відсутність передпроду — властивість проєкту, вона була і вчора. Рішення правити без свідка — третє, і від нього можна відмовитись, навіть якщо зі строком ви згодні.

До сервера тягне, бо окреме оточення звучить як новий проєкт, а клієнт пише зараз. Правлять по SSH або рядком, якого немає в репозиторії. Зранку бага немає або стало гірше, а файл, який змінився, показати нікому. Хід думки лишається в голові того, хто був на сервері. Завтра ця людина у відпустці, і наступна відкриває продакшен як чорну скриньку.

Перш ніж хтось почне набирати, розкладіть це на папері. Не для звіту. Щоб зранку було що перечитати.

• Екран, хто бачить кривий результат і чого чекали замість нього. Вистачить одного речення.
• Де спробі можна провалитися без клієнтів. Відповідь «лише на живому сайті» — дірка в проєкті, не план на ніч.
• Хто подивиться результат. Навіть якщо це ви самі за годину, ім’я має бути написане.
• Чи потрапить правка в репозиторій, звідки її забере наступна людина, чи лишиться лише на сервері.
• Які години ви насправді бережете. «Сьогодні вночі» — час. Не аргумент обійтися без запису.

2. Живий сайт погано годиться, щоб «просто глянути»

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

Окремо незрозуміло, чи допомогла правка і що ще поїхало. Автору сторінка здається нормальною. Нічна задача може кликати ту саму функцію.

На системах, які дісталися у спадок, це звичний слід. Минула команда правила продакшен, копію ніхто не тримав, наступна людина отримує і баг, і страх щось чіпати. Лагодити таке починали з питання, як застосунок уже працює. Не з ще однієї правки, яку бачила одна людина, і не з рішення все викинути.

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

• Запит пише, списує гроші чи щось надсилає, чи лише читає? Не знаєте — правка не дрібна.
• Ту саму функцію смикає задача за розкладом, вивантаження чи інший екран?
• Якщо продуктом користуються кілька клієнтів, чи змінить правка те, що бачить другий? Поки не глянете, латка для одного облікового запису в спільній таблиці — уже другий баг. Де це виринає: чужі дані у спільному продукті.
• Завтра ви побачите ту саму зміну і в репозиторії, і на сервері?

3. Що має існувати до самого редагування

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

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

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

Успадкований Laravel часто встає тут на побуті: немає файлу налаштувань, ключ оплати лише на сервері, ім’я бази вписане в код. Це список блокерів, не запрошення відкрити живі файли. Коли приймають увесь проєкт, довший прохід у чек-листі приймання. Він потрібен, якщо репозиторій або хостинг не ваші. Сьогоднішнє рішення вужче: не ховайте правку, поки цей прохід не зроблено.

• База, в яку клієнти зараз не пишуть. Відновлена копія краща за порожню схему: на порожніх даних бага не видно.
• Той самий екран на цій копії, з тим самим кривим результатом, ще до зміни коду.
• Правка в репозиторії, навіть якщо на живий сайт вона потрапить пізніше тієї самої ночі.
• Одне відновлення, яке ви бачили, або письмове «не відновлювали», яке бачили всі на дзвінку.
• Секрети лишаються там, де їх тримає хостинг. У чат із проханням «поправ уночі» вони не їдуть.

Якщо «поправ сьогодні» пише агенція, той самий список — те, що вони мають принести, а не внутрішня деталь розробника. Як віддати чужий Laravel, щоб сюрприз не виринув на дзвінку з клієнтом: передача з боку агенції.

4. Вечірня викладка після того, як копія вже поводиться нормально

Коли на копії сценарій сходиться, живий сайт стає викладкою, а не місцем для проб. Це все ще може бути той самий вечір. Різниця в тому, що екран ви бачили, правку бачили, і є фраза, на що дивитися після. У нічної правки, яку бачив лише автор, цього немає: є людина і надія, що минеться.

Дивіться на крок, де народжується заявка або проходять гроші, не лише на сторінку, яку чіпали. Якщо без справжньої картки замовлення не оформити, запишіть найближчу перевірку, яка гроші клієнта не рухає, і спершу пройдіть її на копії. На продакшені — один раз, і щоб на той самий результат дивився ще хтось.

• Що змінилось, одним-двома реченнями для людини без розробки.
• Який екран переглянули після викладки і о котрій.
• Якщо екран і далі бреше, відкочуєте цю викладку. Не «ще раз поправимо, поки ніхто не бачить».
• Задача, вивантаження або другий екран на тому самому коді. Назвіть їх, навіть якщо встигли переглянути один.

Новий дизайн — інша розмова. Якщо від «сторінка бреше» вже поїхали до «треба переробити сайт», переробку відкладіть. Редизайн системи, яку можна міняти лише на продакшені, — той самий ризик, файлів більше. Спершу час і місце, де правку можна побачити. Про це окремо: що дивитися до редизайну.

5. Короткий список з іменами замість «будемо обережні»

У кожного рядка є людина. «Будемо обережні» в список не входить.

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

• Хто відповідає за копію, хай навіть чорнову.
• Хто дивиться живий сайт після викладки і не вгадує, як виглядає «готово».
• Наступний баг не латають уночі з звички. Звичка — запис із першого розділу.

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

Коли кликати людину, яка підніме копію

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

За таку роботу я беруся: сценарій спершу запускається там, де помилка нікому не видна, потім його міняють. На тій системі, яка у вас уже є. Послуги — відновлення, швидкість і backend із живими клієнтами. Роботи — ті самі ситуації, цифра біля своєї операції. Якщо потрібен другий погляд до сьогоднішньої правки, напишіть у LinkedIn. Баг одним реченням і чи є бодай якась копія, крім продакшену. Паролі не надсилайте.