Как агентству передать чужой Laravel без сюрприза на проде

Страница выглядит как страница, прошлый разработчик из переписки вышел, дату назвали по видимой части. Невидимая часть встречает человека в последний вечер: тестовой среды нет, боевой пароль где-то в старом чате, правка задевает оплату, которой не было в брифе, а в базе лежит больше одного клиента, и никто не сказал, так задумано или нет.

Читать фреймворк от вас не ждут. Ждут, что вы отличите факты, без которых мелкая правка превращается в тот созвон.

Ниже передача чужого Laravel, не креативный бриф на кампанию. Что приложить, когда работа — новая страница или новый сценарий: бриф, с которого можно начать. Берите оба, если приложение уже работает и одновременно просят новое. Этот пакет нужен всякий раз, когда код уже крутится там, где его видят клиенты.

1. Откуда берётся сюрприз, который потом объясняют клиенту

Файлы, которые у вас на руках, обычно те, что клиент и сам видит: текст, макет, список страниц. Поведение живёт в репозитории прошлого разработчика, на сервере, за который клиент платит и который не открывает, и в задаче, которая стартует ночью. «Это Laravel» говорит про форму кода. Не говорит, какая ветка выложена, есть ли копия и какой клик снимает деньги.

Дата — вторая половина той же ошибки. Её обещали по картинке. Чтобы её удержать, остаётся попробовать изменение на живом сайте. Это похоже на верность сроку и кладёт заказы клиента в эксперимент. Если попробовать негде, кроме прода, напишите это в первом сообщении и сдвиньте дату до того, как кто-то откроет боевой сервер. Со стороны владельца то же решение разобрано здесь: почему отсутствие тестовой среды — не повод править на бою.

Дыру записывают раньше даты.

• Что вы уже сказали клиенту и на чём эта фраза держится. «Мелкая правка, в пятницу на бою» предполагает, что есть где попробовать и какой шаг вы можете назвать.
• Чего вы не видели: репозиторий, выложенную ветку, тестовую среду, восстановление из копии.
• Кто с вашей стороны говорит с клиентом, если допущение развалится. Разработчик не должен обнаружить, что он теперь аккаунт.

2. Кто чем владеет, без паролей в переписке

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

Перечислите системы по именам: репозиторий, хостинг, домен, платежи, почта, очередь или задача по расписанию, если клиент о ней говорил. Кто выдаёт вход: клиент, вы или прошлый подрядчик. Доступ — через учётки, которые вы или клиент можете отозвать. Боевой пароль, платёжный секрет и копию клиентской базы в чат и в бриф не кладут. Полная копия живых записей на ноутбуке — не «более безопасный предпрод». Это второе место, откуда данные утекут.

• У каждой системы есть человек, который выдаёт вход и может его забрать.
• Разработчик получает учётку, не общий пароль из пересланного письма.
• Боевых секретов нет ни в документе, ни в чате.
• Вы знаете, какая ветка на боевом сайте и когда её последний раз выкладывали. «Последняя» — не имя ветки.
• Если сервер открывает только прошлый разработчик, это первая задача, не сноска под новым баннером.

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

3. Есть ли где прогнать Laravel, кроме боя

Этот факт чаще всего приезжает поздно. Разработчик спрашивает, где пробовать. Честный ответ — живой сайт, а дата завтра. Скажите это в первый день, письменно. Отсутствия тестовой среды стыдиться не надо. Стыдно делать вид, что она есть, до вечера перед выкладкой: так ваша дата становится их инцидентом.

Если среда есть, напишите, что это: адрес, чей аккаунт её открывает, данные из восстановленного бэкапа или игрушечный набор. Игрушка не покажет баг, который живёт на настоящем заказе. Бэкап считается бэкапом, если его хотя бы раз разворачивали у вас на глазах. Не разворачивали — пишите «не проверяли», а не «копии есть».

• Да или нет: этот Laravel можно запустить не на боевом сайте.
• Если да — адрес и как получить вход. Если нет — дата, названная клиенту, держится на том, что среду ещё предстоит собрать.
• Если данные из бэкапа, кто-то его восстанавливал, или вы прямо написали, что нет.
• Разработчика не просят «просто быть аккуратным» на проде вместо этой строки.

4. Какие шаги могут задеть клиента

Это описывают, не открывая код. Какой клик берёт деньги? Какая форма создаёт заявку, о которой вы отчитываетесь? Какая ночная задача шлёт почту, собирает файл или списывает ещё раз? Что прошлый разработчик называл хрупким? Если вы этого не знаете, правка пока не мелкая. «Мелкая» появляется, когда названы соседи изменения.

Если приложением пользуются несколько клиентов вашего клиента, так и скажите. Права на экране для своих сотрудников могут показать одной компании строки другой, или задача ушлёт не тот файл. Как данные разделены, решать не вам. Сказать, что разделение есть и его надо перепроверить, — вам. Что именно перепроверять: где в общем продукте смешиваются чужие данные.

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

Системы, которые уже были в плохом состоянии, сначала ставили на ноги, и только потом на них клали новые функции. Если этот Laravel приехал полусломанным, не отдавайте разработчику стабилизацию и запуск кампании на одну пятницу. Порядок скажите клиенту. На втором созвоне вы будете выглядеть надёжнее, чем на первом, где эти задачи притворились одной.

5. Смотреть на копии, дату выкладки называть отдельно

Ваша приёмка — проверки из пакета, пройденные в тестовой среде, и хотя бы одна из них у вас на глазах. Разработчик показывает оплату или шаг заявки, или ближайшую безопасную замену. Вы сверяете с предложением в пакете. Прод — отдельная выкладка после этого, со временем и человеком, который посмотрит ещё раз, когда уже живо. Не место для первой пробы и не сюрприз, который вы оба встречаете на созвоне с клиентом.

• Разработчик показывает, какая проверка прошла на копии, до разговора о проде.
• Один критичный шаг вы видели сами или назвали коллегу, который видел.
• Дата для клиента совпадает с этим порядком. Если нет, её поправляют до выкладки, не после инцидента.
• Записку «что изменилось» можно переслать клиенту, не переводя коммит.

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

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

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

Техническую сторону такой передачи для агентств я беру: чем вы владеете, где изменение можно попробовать, какие шаги могут задеть, и уже потом само изменение. Услуги — отдельный проект или сопровождение Laravel и backend, у которых уже есть клиенты. Проекты — как раз унаследованные продукты, на которые такие передачи садятся. Если есть чужой Laravel, напишите в LinkedIn: кто чем владеет, есть ли тестовая среда, и дату, которую вы уже назвали или ещё нет. Пароли оставьте у себя.