Як агенції передати чужий Laravel, щоб сюрприз не виліз на дзвінку

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

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

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

1. Звідки береться сюрприз, який потім пояснюють клієнту

Файли, які у вас на руках, зазвичай ті, що клієнт і сам бачить: текст, макет, список сторінок. Поведінка живе в репозиторії минулого розробника, на сервері, за який клієнт платить і якого не відкриває, і в задачі, яка стартує вночі. «Це Laravel» каже про форму коду. Не каже, яка гілка викладена, чи є копія і який клік знімає гроші.

Дата — друга половина тієї самої помилки. Її обіцяли з картинки. Щоб її втримати, лишається спробувати зміну на живому сайті. Це схоже на вірність строку і кладе замовлення клієнта в експеримент.

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

• Що ви вже сказали клієнту і на чому ця фраза тримається. «Дрібна правка, у п’ятницю наживо» припускає, що є де спробувати і який крок ви можете назвати.
• Чого ви не бачили: репозиторій, викладену гілку, тестове середовище, відновлення з копії.
• Хто з вашого боку говорить із клієнтом, якщо припущення розвалиться. Розробник не повинен виявити, що він тепер акаунт.

2. Хто чим володіє, без паролів у листуванні

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

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

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

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

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

3. Чи є де прогнати Laravel, крім продакшену

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

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

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

4. Які кроки можуть зачепити клієнта

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

Якщо ви цього не знаєте, правка поки не дрібна. «Дрібна» з’являється, коли названі сусіди зміни.

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

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

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

5. Дивитися на копії, дату викладки називати окремо

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

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

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

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

Коли кликати розробника до того, як дату сказано вголос

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

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