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