Короткий ответ: безопасная передача приложения начинается с инвентаризации активов и доступов, продолжается техническим аудитом и заканчивается первым контролируемым релизом новой команды. Доступ к репозиторию сам по себе не означает передачу продукта.
Смена подрядчика может происходить спокойно: команда выросла, изменились требования к скорости или прежний исполнитель больше не может поддерживать продукт. Главный риск появляется, когда знания об архитектуре, инфраструктуре и выпуске приложения существуют только в переписке и памяти отдельных людей.
Что должно перейти новой команде
Код и история изменений
- репозитории мобильных клиентов, backend и административной панели;
- доступ к веткам, тегам и истории релизов;
- инструкции по локальному запуску и сборке;
- зависимости, приватные пакеты и лицензии;
- тесты и данные для тестового окружения.
Инфраструктура
- облако, серверы, домены и DNS;
- базы данных, хранилища и очереди;
- CI/CD и секреты окружений;
- резервные копии и процедура восстановления;
- логи, метрики и уведомления;
- тестовое и production-окружение.
Сторонние сервисы
Нужно передать кабинеты App Store, Google Play или RuStore, push-уведомления, аналитику, карты, SMS, почту, эквайринг и другие API. Владелец аккаунта должен быть связан с компанией-заказчиком, а не с личной почтой разработчика.
Первый этап — аудит, а не срочная переделка
Новая команда сначала должна понять, что именно находится в production и как оно туда попадает. Аудит отвечает на вопросы:
- можно ли воспроизвести сборку опубликованной версии;
- какие компоненты являются критическими;
- где находятся риски безопасности и потери данных;
- какие интеграции не имеют мониторинга;
- что мешает выпускать изменения предсказуемо;
- какой технический долг нужно исправлять первым.
Не весь найденный технический долг нужно устранять сразу. Его связывают с риском для бизнеса, частотой изменений и планом продукта. Иначе поддержка превратится в бесконечный «рефакторинг» без видимого результата.
Передавайте доступы безопасно
- Создайте именные учётные записи для новой команды.
- Не пересылайте общие пароли в чатах и документах.
- Включите двухфакторную авторизацию.
- Зафиксируйте владельцев и уровни прав.
- После передачи отзовите лишние доступы прежней команды.
- Поменяйте секреты, если нельзя подтвердить историю их использования.
Как провести переход без остановки продукта
На время передачи полезен короткий период пересечения команд. Прежний подрядчик объясняет архитектуру и релизный процесс, новая команда фиксирует знания и проверяет их на практике. Критические изменения в этот период лучше ограничить.
Признак завершённой передачи — новая команда самостоятельно собирает продукт, разворачивает тестовый контур, диагностирует типовой инцидент и выпускает небольшое безопасное изменение в production.
Что зафиксировать в SLA
- часы доступности поддержки;
- уровни критичности инцидентов;
- время реакции и начала работы;
- канал регистрации задач и инцидентов;
- порядок эскалации;
- ответственность за внешние сервисы;
- формат отчётности и плановых работ.
Не обещайте и не покупайте 24/7 автоматически. Для части продуктов достаточно рабочего времени и мониторинга критических событий. Режим поддержки должен соответствовать реальной цене простоя.
Если нужно принять работающий продукт, посмотрите услуги поддержки приложений и информационных систем и поддержки сайтов. Мы начинаем с аудита и плана безопасного первого релиза.