Исходники и работающий сайт — не одно и то же

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

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

Какие вопросы задать до запуска

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

Архив выбранного состояния Git и репозиторий с историей имеют разные возможности. Документация git archive описывает выгрузку дерева файлов заданной версии. Такой результат сам по себе не следует принимать за полную историю проекта.

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

Как проверить возможность сборки и запуска

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

Зависимости устанавливают предусмотренным проектом способом. Например, npm ci использует существующий файл фиксации версий и сообщает об ошибке при его несоответствии описанию зависимостей. Этот режим описан в документации npm. Подмена версий «чтобы заработало» меняет условия проверки и должна фиксироваться отдельно.

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

Чек-лист проверки комплекта

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

Условный пример: отсутствующий пакет

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

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

Техническая проверка не устанавливает автоматически авторство, стоимость работ или объём переданных исключительных прав. Отсутствие истории в архиве также не означает дефект передачи, если история не входила в согласованный комплект.