Передача сайта должна позволять заказчику продолжать работу: обновлять материалы, оплачивать нужные сервисы, получать обращения и привлекать специалистов к развитию. Ссылка на работающую главную и архив файлов сами по себе этого не подтверждают. Нужен понятный состав результата и проверка возможностей получателя.
Согласуйте состав передачи до завершения разработки. Для проекта на управляемой платформе, собственного приложения и сайта на CMS набор материалов отличается. Ниже — реестр для обсуждения; применимость каждого пункта определяется устройством сайта и согласованным объёмом. Он не устанавливает договорные права автоматически.
Составьте реестр передачи
В реестре храните адрес системы или документа, владельца, назначенную роль, дату проверки и результат. Пароли, ключи API, резервные коды и другие секреты в эту таблицу не включайте. Для доступа укажите согласованный способ передачи отдельно от самих значений.
| Объект | Что получить или уточнить | Чем проверить передачу |
|---|---|---|
| Исходный код | Репозиторий, версия релиза, инструкция сборки и зависимости | Получатель имеет согласованные права; специалист воспроизвёл сборку в разрешённом окружении |
| Дизайн | Исходные макеты, компоненты, состояния и используемые материалы | Файл открывается с правами, нужными для дальнейшей работы |
| Домен и DNS | Регистратор, администратор домена, доступная роль, продление и место управления записями | Подтверждены полномочия и ответственный за продление; записи не меняют ради проверки |
| Хостинг и окружения | Кабинет, состав ресурсов, рабочая и тестовая среды, оплата | Получатель видит нужные ресурсы и понимает их назначение |
| CMS и контент | Учётные записи по ролям, материалы, файлы, границы редактирования | Редактор выполнил согласованные операции и проверил результат страницы |
| Интеграции | Системы-получатели, владельцы, назначение обмена и порядок диагностики | Доступ и разрешённый контрольный сценарий подтверждены |
| Аналитика и поиск | Ресурсы, счётчики, роли, список целей и правила исключения тестов | Получатель открыл правильный ресурс и видит данные нужного периода |
| Инструкции и поддержка | Обновление, выпуск, восстановление, обращения при ошибке, границы поддержки | Другой участник может повторить выбранную операцию по инструкции |
| Резервные копии | Состав, место, ответственный, срок хранения и порядок восстановления | Есть результат проверки восстановления в разрешённой среде либо явно указан пробел |
Для каждого неприменимого пункта запишите основание. Например, отсутствие собственного сервера на управляемой платформе не означает отсутствия ответственности за оплату, экспорт данных или доступ к кабинету.
Код и макеты: проверьте возможность продолжить работу
Уточните, какой репозиторий соответствует опубликованной версии и какой идентификатор релиза передаётся. Нужны инструкции запуска и сборки, требования к окружению и описание параметров конфигурации без секретных значений. Архив исходников может быть частью передачи, но не заменяет ответы о версии, зависимостях и процедуре выпуска.
Доступ к чтению и право управлять репозиторием решают разные задачи. Если договорённость предусматривает перенос репозитория в аккаунт заказчика, проверьте результат переноса, участников и связанные настройки. В GitHub при переносе могут сохраняться участники, webhooks, secrets и deploy keys: смена владельца сама по себе не означает удаление прежних доступов. Это описано в документации GitHub.
Для макетов проверьте не только ссылку, но и нужный режим работы: просмотр, редактирование, копирование или передача владения согласно договорённости. Отдельно перечислите шрифты, фото, иллюстрации, плагины и другие сторонние материалы, источник и известные условия использования. Право открыть файл не доказывает право свободно распространять каждый его элемент.
Домен и хостинг: назначьте ответственных
Выясните, кто управляет доменом и кто может решать вопросы продления и восстановления доступа. Управление DNS может находиться в другой системе, чем регистрация домена. В реестре должны быть обе роли, если это разные кабинеты.
Для хостинга перечислите приложение, хранилища, базу данных, файлы и другие используемые ресурсы. Отметьте, где рабочее окружение, а где тестовое. Укажите плательщика и источник уведомлений о продлении. Не подставляйте приблизительную стоимость вместо фактического тарифа: в документ можно внести ссылку на кабинет и дату проверки условий.
Проверка передачи не требует менять DNS или выключать сервер. Начните с подтверждения видимости ресурсов и полномочий получателя. Действия, способные затронуть рабочий сайт, выполняются по отдельному согласованному плану. Для переключения пригодится урок о запуске и откате.
CMS: проверьте работу редактора
Попросите получателя войти своей учётной записью и выполнить согласованную операцию: создать черновик, обновить текст, заменить изображение, открыть предпросмотр и опубликовать разрешённый материал. Сверяйте возможности с требованиями к CMS, а не с тем, что доступно разработчику под его аккаунтом.
Название роли ещё не описывает все ограничения конкретного проекта. Например, WordPress разделяет роли и разрешённые действия; редактор и администратор имеют разный набор возможностей. Проверяйте нужные операции, а не требуйте максимальных прав каждому сотруднику. Источник: роли и возможности WordPress.
В инструкции покажите также действия при ошибке и границы редактирования. Если изменение шаблона требует разработчика, это должно быть ясно до передачи. Для материалов, которые поступают из внешней системы, назначьте владельца источника и порядок исправления данных.
Интеграции, копии и инструкции
Составьте перечень подключённых систем: обработка заявок, почта, каталог, платёжный сервис, авторизация и другие фактически используемые зависимости. Для каждой укажите владельца, назначение доступа и место проверки результата. Секреты передают согласованным защищённым способом; в реестре фиксируют только факт и ответственного. Изменение ключей планируют вместе с проверкой зависимых процессов, чтобы не остановить обмен.
Демонстрация сообщения «отправлено» не доказывает обработку обращения. Для приёмки интеграции согласуйте тестовые данные и получателя, затем проследите путь заявки. Если разрешения или доступа нет, оставьте состояние «Не проверено» и следующий шаг.
По резервным копиям задайте два отдельных вопроса: что сохраняется и что уже удавалось восстановить. Запишите состав данных и файлов, версию, дату проверки, окружение и ограничения. Наличие архива не подтверждает восстановление работающего сайта. Новые записи после создания копии требуют отдельного решения при возврате.
Попросите другого участника выполнить по инструкции одну разрешённую операцию без подсказок автора. Недостающие условия, шаги или доступы станут конкретными задачами до закрытия передачи.
Пробный запуск у нового подрядчика
Если цель передачи — сменить исполнителя, проверьте возможность продолжить работу без его постоянных подсказок. До начала согласуйте объём, получателя и изолированное тестовое окружение. Пробный запуск не требует переключать домен или прекращать поддержку работающего сайта.
- Зафиксируйте исходную версию. Укажите релиз, состав кода, контента и файлов, дату копии и зависимости. Отдельно перечислите данные, появившиеся после копирования: тест старого снимка не подтверждает сохранность новых обращений.
- Проверьте возможность переноса. Для управляемой платформы выясните, что доступно: передача проекта внутри сервиса, экспорт материалов или запуск вне платформы. Это разные возможности. Перечислите лицензии шрифтов, плагинов, изображений и платных компонентов; переносимость прав уточняется по условиям конкретного продукта. Наличие архива не делает лицензию переносимой.
- Подготовьте безопасные входные данные. Передайте описание параметров конфигурации отдельно от секретов. Используйте разрешённую обезличенную копию или тестовый набор; укажите, какие реальные сценарии он не покрывает. Отключите исходящие письма, платежи и другие рабочие действия либо направьте их в согласованные тестовые системы. Одна отметка «тестовый сайт» не изолирует интеграции.
- Попросите получателя повторить инструкцию. Другой специалист разворачивает согласованную версию, подключает тестовые данные и открывает ключевые страницы. Все устные подсказки превращаются в дополнения к инструкции, после чего соответствующий шаг повторяется. Запишите недоступные зависимости и ручные операции.
- Проверьте продолжение работы. Выполните разрешённое изменение текста в CMS, откройте новую редакцию страницы и пройдите согласованный сценарий обращения до тестового получателя. Проверьте восстановление тестовой копии по инструкции. Если интеграция недоступна, отметьте её как «не проверено», а не как успешно перенесённую.
- Примите отдельное решение о переключении. Сопоставьте результаты с обязательным объёмом. Назначьте исправления, повторные проверки, ответственного за поддержку и план переноса новых данных. Только затем согласуйте рабочее переключение и проверку после него. Успех пробного запуска не означает, что production уже перенесён.
Протокол проверки смены подрядчика
Учебный пример ниже показывает, как записывать наблюдения. Это не результат переноса проекта CoreWeb и не подтверждение переносимости какой-либо платформы.
| Проверка | Наблюдение в учебном примере | Решение |
|---|---|---|
| Версия и инструкция | Релиз указан, версия среды отсутствует | Дополнить требования и повторить запуск |
| Контент и файлы | Страницы открываются, часть документов не включена в копию | Уточнить состав и повторить сверку |
| Редактирование | Получатель изменил тестовый текст и увидел новую редакцию | Пройдено в указанном окружении |
| Интеграция | Форма показывает успех, получение не проверено | Не проверено; подтвердить приём тестовым получателем |
| Лицензии | Для платного компонента не уточнены условия передачи | Запросить условия до решения о переносе |
| Восстановление | Копия создана, восстановление ещё не выполнялось | Назначить проверку; готовность не подтверждена |
В рабочем протоколе добавьте версию, окружение, дату, проверяющую роль, ожидаемый результат, ссылку на безопасное доказательство и срок следующего шага. Для неприменимого пункта укажите причину. Не помещайте туда пароли, ключи или содержимое реальных заявок.
Если получатель может работать только с постоянной помощью прежнего исполнителя, зафиксируйте зависимость: какой шаг, доступ или знание отсутствует. Возможные решения — дополнить передачу, согласовать ограниченный переходный период или отдельно оценить замену непереносимого компонента. Не обещайте смену подрядчика «без потерь» до проверки этих условий.
Как закрыть передачу
Зафиксируйте также расходы и ответственных после запуска: продления, сопровождение, контент и порядок согласования новых задач.
У каждого объекта должно быть состояние: передано и проверено, передано без проверки, ожидает передачи или не применимо с основанием. Добавьте доказательство и открытые вопросы. Отдельно зафиксируйте, кто сопровождает сайт после передачи и какие работы требуют нового согласования.
Пересмотрите временные доступы после подтверждения доступа заказчика. Их отключение и смену ключей согласуйте с ответственными за зависимые процессы. Не удаляйте единственный рабочий способ управления ради формального завершения списка.
Передачу удобно связать с протоколом приёмки, но проверка функций и передача управления — разные части результата. При обсуждении сайта под ключ заранее включите обе в состав работ: что должно работать и чем заказчик сможет управлять после запуска.
Собрать собственный документ поможет практикум по реестру передачи: заполните роли, подтвердите доступы получателя и назначьте действия по незавершённым пунктам.
Для проверки инфраструктуры используйте карточку домена: регистрация, DNS и продление и матрицу хостинга: размещение и обслуживание. Наличие одного пароля не подтверждает контроль всех этих частей.
В термине «Резервная копия» есть паспорт копирования и порядок учебного восстановления. Включите в передачу последний протокол, а не только сообщение о создании архива.