Чек-лист передачи проекта: код, доступы и аккаунты
Практика3 минРедакция Innovialabs
Коротко
При передаче проекта заказчик должен стать владельцем всех аккаунтов — репозитория, домена, хостинга, сторов и внешних сервисов — и получить код, ключи и документацию, достаточные для работы без прежнего подрядчика.
Короткий ответ
Проект считается переданным, когда все ключевые аккаунты оформлены на заказчика, а не на подрядчика или его сотрудника, и когда новая команда может развернуть, изменить и выпустить продукт, используя только то, что вы получили. Проверить это просто: представьте, что прежний подрядчик завтра недоступен. Всё, что вы не сможете сделать сами, — ещё не передано.
Главный принцип: владелец, а не гость
Самая частая проблема — аккаунты зарегистрированы на почту разработчика, а заказчику выдан «доступ». Пока владелец — другой человек, он может потерять пароль, уволиться или просто перестать отвечать.
Правило: владельцем аккаунта является компания заказчика (корпоративная почта, юрлицо, платёжный метод заказчика). Подрядчик получает приглашение с ограниченной ролью и удаляется после окончания работ.
Код и репозитории
- Репозиторий (GitHub, GitLab, Bitbucket) находится в организации заказчика, а не в личном аккаунте разработчика.
- Передана полная история коммитов и все рабочие ветки, а не архив с последней версией.
- В репозитории нет паролей и ключей в открытом виде; секреты вынесены в переменные окружения.
- Есть файл с примером конфигурации (например,
.env.example) с перечнем всех нужных переменных без значений. - Настройки CI/CD и пайплайны доступны заказчику.
Домены и DNS
- Домен зарегистрирован на заказчика, контактная почта — корпоративная.
- Доступ к панели регистратора и к DNS-провайдеру, если они разные.
- Включено автопродление, известна дата окончания регистрации.
- Задокументированы DNS-записи: сайт, почта, верификации сервисов.
Хостинг и инфраструктура
- Аккаунт облака или хостинга оформлен на заказчика и оплачивается его картой.
- Доступы к серверам: SSH-ключи заказчика добавлены, ключи подрядчика удаляются после передачи.
- Описано, где и как запущено приложение: серверы, контейнеры, базы данных, хранилища файлов.
- Настроено резервное копирование, и известно, как восстановиться из бэкапа.
- SSL-сертификаты обновляются автоматически.
Мобильные сторы
- Google Play Console и Apple Developer — аккаунты компании заказчика.
- Ключи подписи приложения сохранены у заказчика. Потеря ключа подписи может сделать невозможным выпуск обновлений для уже опубликованного приложения, поэтому этот пункт критичен.
- Доступ к сертификатам и профилям для push-уведомлений.
Внешние сервисы и API-ключи
Составьте реестр всех сервисов, от которых зависит проект:
| Сервис | Для чего | Владелец аккаунта | Где хранится ключ |
|---|---|---|---|
| Платёжная система | Приём оплат | Заказчик | Переменные окружения |
| Почтовый сервис | Письма пользователям | Заказчик | Переменные окружения |
| Telegram-бот | Уведомления | Заказчик | Переменные окружения |
| Аналитика | Метрики сайта | Заказчик | Настройки сайта |
| Карты, SMS, AI-API | По проекту | Заказчик | Переменные окружения |
После передачи перевыпустите ключи, которые видел подрядчик, если договор и риски этого требуют.
Документация
- Как запустить проект локально — пошагово.
- Как развернуть новую версию на сервер.
- Схема архитектуры: какие части есть и как они связаны.
- Описание API, если оно есть.
- Список известных проблем и технического долга.
- Контакты: кто и до какого срока отвечает на вопросы по проекту.
Как провести передачу
- Составьте реестр всех аккаунтов и сервисов.
- Переведите владение на заказчика и проверьте оплату.
- Получите код, секреты и документацию.
- Попросите независимого разработчика развернуть проект по документации.
- Отзовите доступы подрядчика и смените общие пароли.
- Подпишите акт передачи с перечнем переданного.