Передача сайта команде заказчика: список артефактов и что проверить на приёмке

Сайт, портал или кабинет готов, и дальше его ведёт ваша команда. Технический директор в этот момент думает не про акт, а про одну картинку: придёт архив, и окажется, что проект собирается только на ноутбуке разработчика, который уже ушёл на другой проект. Выкатить правку нечем, базу накатить не из чего, журналов нет, половина ключей оформлена на чью-то личную почту.

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

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

Данные для теста заводятся отдельно и обезличенно: учётные записи всех ролей, типовые записи, крайние случаи. Копия боевой базы с живыми людьми в медицине и финансах — прямое нарушение требований к персональным данным. Учётные записи инфраструктуры — облако, хостинг, домен, сертификаты, магазины приложений, почтовый шлюз — оформляются на компанию; проверка простая: вы сами выдаёте доступ новому сотруднику и отзываете у уволенного. Отдельно уточните, кто продлевает сертификат: просроченный останавливает продукт целиком, обычно в выходной.

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

Приложение EdPro мы делали для Международной академии дополнительного профессионального образования: Топ-3 сегмента, более 10 000 выпускников, аудитория продуктов свыше 150 000 человек. Платформа уже работала в вебе, и приложение должно было не «упаковать сайт», а встать рядом: расписание, оценки, материалы, связь с преподавателем, работа при нестабильном интернете.

Для приёмки важна серверная часть. Приложение интегрировано с существующей платформой через защищённые API, авторизация построена на ролях — студент, преподаватель, администратор, — управление ролями осталось централизованным. Кроссплатформенный Flutter дал единый код для iOS и Android: одна кодовая база вместо двух. Оценку дал технический руководитель академии: проект получился легко поддерживаемым, команда без проблем взяла его к себе и продолжает развивать. Другой оценки передачи не бывает.

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

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

Дальше два числа, которые называет бизнес, а не разработчик: за сколько вы восстанавливаетесь после аварии и за какой период готовы потерять данные. Из них выводится расписание копий; без них у вас не план восстановления, а надежда. Рядом — дата последней успешной проверки: не «копии делаются», а «такого-то числа копию подняли и вошли»; обновляют её раз в квартал.

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

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

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

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

И правило отката, названное заранее: признак, по которому откатывают немедленно и разбираются потом. Это способ снять с дежурного решение в три часа ночи — пока правило не записано, он час выясняет, достаточно ли всё плохо, чтобы кого-то будить.

Часть продукта существует только как договорённость между людьми и в репозиторий не попадает. Личный кабинет агента для медицинской группы EMC — пример. В модуле сотрудника клиники заявки распределяются автоматически, с учётом загруженности специалиста и области его экспертизы; время от поступления запроса до медицинского заключения сократилось на 60%.

Код маршрутизации передаётся вместе с остальным кодом. А вот какие случаи считаются срочными и как в спорном случае выбирают специалиста — знание врачей, а не репозитория. Не записали на приёмке — через полгода команда будет бояться трогать правила распределения, потому что никто не знает, что сломается.

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

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

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

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