Сначала сохраните работающую версию
Если разработчик не передал исходный код приложения, начните со списка того, что у компании уже есть: ссылка в магазине, доступные архивы, репозитории, серверы и резервные копии. Сохраните эти материалы и сведения о текущем выпуске. Затем новая команда проверит, можно ли повторить сборку и восстановить сервер в отдельной среде. Так появится план перехода с конкретными препятствиями и критериями результата.
Мы предлагаем начинать с ограниченной диагностики. Фиксируем версии приложения и серверной части, доступные материалы и критические действия пользователей. Для каждого пробела указываем последствия: нельзя собрать, нельзя опубликовать, нельзя восстановить данные или нельзя проверить бизнес-процесс.
До первых изменений: сохраните текущие исходники, сборочные материалы и доступные копии данных. Назначьте ответственного за работающую систему. Обновление библиотек, перенос сервера и новые функции согласуйте отдельными работами после проверки исходной точки.
Материалы запрашиваем у прежней команды и ищем в принадлежащих компании резервных копиях, хранилищах и системе сборки. Доступ восстанавливаем через штатную поддержку сервиса от имени уполномоченного владельца. Если исходного проекта нигде нет, отдельно оцениваем замену недоступного компонента или новую разработку. Обещать обычную доработку по одному установочному файлу преждевременно.
Основания для использования и передачи кода разбираются вместе с договором; спорные вопросы передают профильному юристу. Этому посвящён отдельный материал о правах на код приложения. Здесь мы разберём техническую готовность новой команды продолжать продукт.
Проверяйте весь процесс, которым пользуется бизнес
Рабочая сборка на телефоне подтверждает только часть передачи. За входом, каталогом и заказом могут стоять сервер, база данных, админ-панель и внешняя учётная система. Чтобы выбрать состав диагностики, запишите одно важное действие пользователя и проследите, какие системы дают ему результат.
В «Бакаеве» мы связали мобильный магазин, админ-панель и 1С через сервер синхронизации. Сотрудник меняет фотографию товара в админке, и она отражается в 1С. Заказ в приложении меняет остатки в админке и учётной системе; изменения из 1С доходят до приложения. Такой продукт принимают по сквозному сценарию: от действия покупателя до результата сотрудника.
Реальный проект 13FOX
Каталог в связанной системе
В «Бакаеве» мы помогли перенести локальную 1С в облако и настроили обмен с админ-панелью мобильного магазина.
Для вашего приложения мы выбираем контрольные сценарии вместе с ответственным сотрудником. Например, для магазина это вход покупателя, создание тестового заказа, появление его в админке и проверка связанных данных. Для сервиса записи набор будет другим: выбор времени, подтверждение и доступность записи сотруднику.
Каждый материал должен подтверждаться проверкой
Например, владелец аккаунта магазина выдаёт новой команде роль для тестового выпуска. Мы пробуем загрузить сборку и записываем результат. В реестре рядом с ресурсом указываем владельца, роль команды, назначение среды и способ проверки.
- Доступно и проверено: приложен результат действия.
- Доступно, проверка не выполнена: указано, что предстоит сделать.
- Отсутствует или ожидаем ответ владельца: названо препятствие и ответственное лицо.
| Что передаём | Что проверяем | Что сохраняем для приёмки |
|---|---|---|
| Код приложения, сервера и админки | Новая команда получает нужные ветки, метки релизов, вложенные репозитории и большие файлы | Адреса хранилищ, точные версии кода, результат получения всех компонентов |
| Инструкция и настройки сборки | Установка инструментов и библиотек проходит в новой среде, сборка повторяется | Версии инструментов, команда сборки, журнал и полученный файл |
| Серверы, домены и развёртывание | Известны рабочая и тестовая среды, зависимости, адреса подключения и способ выпуска | Карта ресурсов, конфигурация без секретов, инструкция запуска и возврата версии |
| База данных и файлы пользователей | Разрешённая копия восстанавливается в изоляции, данные и файлы согласованы | Дата копии, версия базы, протокол восстановления и контрольные записи |
| Магазины и подпись приложения | Назначены роли для выпуска, установлены идентификаторы приложения и схема подписи | Владельцы аккаунтов, разрешения, сведения о сертификатах и тестовый выпуск |
| Внешние сервисы и наблюдение за ошибками | Доступны уведомления, вход, платежи и другие используемые связи; ошибки видны новой команде | Список интеграций, ответственные, ограничения и результаты тестовых операций |
Секреты передают через согласованное защищённое хранилище с ограничением доступа. В обычной таблице оставляют название секрета, назначение и ответственного. Для репозитория дополнительно проверяют большие файлы Git LFS: GitHub описывает отдельный перенос этих объектов. Обычная копия истории может не включать сами большие файлы.
Восстановите сборку в новой среде
Допустим, архив открывается, но новая команда получает ошибку загрузки библиотеки из закрытого хранилища. Прежний разработчик мог использовать пакет, сохранённый только на своей машине. Мы записываем имя и версию пакета, источник загрузки и владельца доступа. Затем выбираем согласованный путь: получить доступ, передать разрешённую копию или заменить зависимость с отдельной проверкой функций.
Восстановление начинаем с версии, которая предположительно соответствует работающему выпуску. Совпадение названия ветки с номером приложения проверяем по метке релиза, журналу сборки и сохранённым материалам выпуска. Если связь установить не удалось, фиксируем это как отдельное ограничение.
- Проверяем комплект до запуска. Получаем все модули, ресурсы, генераторы и настройки автоматической сборки. Изучаем сборочные скрипты и их источники, затем запускаем их в выделенной среде.
- Воссоздаём инструменты. Фиксируем версии Java, Android SDK, Xcode и других инструментов, которые нужны конкретному проекту. Например, Gradle Wrapper задаёт используемую версию Gradle; фиксация зависимостей помогает получать согласованный набор библиотек.
- Собираем для тестовой среды. Задаём тестовые подключения и получаем сборку без настроек на машине прежней команды. Сохраняем команду, журнал, номер версии и контрольную сумму файла.
- Повторяем и проверяем сценарий. Другой специалист следует инструкции. На согласованных устройствах проверяем запуск, вход и выбранное действие пользователя. Подпись и выпуск проверяем следующим отдельным шагом.
Журнал восстановления должен быть понятен и собственнику продукта. Для каждой ошибки в нём есть причина, недостающий материал, ответственное лицо, предложенное действие и проверка результата. Например: «недоступен пакет авторизации; запросить доступ у владельца хранилища; после подключения собрать версию и проверить вход».
Поднимите сервер из копии и проверьте данные
Если сервер продолжает работать, смена команды может обойтись без его переноса. Всё равно нужно проверить, что новая команда умеет восстановить систему: доступная резервная копия полезна только вместе с совместимой версией сервера, настройками и инструкцией запуска.
Для пробного восстановления мы предлагаем отдельную среду с согласованными обезличенными данными. До запуска отключаем реальные рассылки, платежи и запись во внешние рабочие системы. Иначе восстановленный сервер может отправить клиентам старые уведомления или повторно передать заказы. Для интеграций используем тестовые кабинеты или согласованные заглушки.
Проверяем совместимость кода со структурой базы и порядок применения её изменений. Затем восстанавливаем данные и связанные файлы: фотография в карточке должна открываться, заказ должен иметь нужные позиции и статус. По журналам подтверждаем, что приложение обращается к тестовому серверу, сотрудник видит результат в тестовой админке, исходящая операция не попадает в рабочую систему.
Если предстоит перенос рабочей базы, заранее согласуем допустимый перерыв, перенос новых данных за время перехода и условия возврата. Возврат старой копии поверх новых заказов может потерять работу клиентов. Поэтому план отката отдельно описывает код, данные, внешние операции и ответственного за решение. В пробном восстановлении измеряем время; обещание срока для рабочей системы обсуждаем по этому результату.
Проверьте подпись и аккаунты до первого обновления
Для Android сначала устанавливаем, как приложение подписано и через какие магазины распространяется. В Google Play при использовании Play App Signing ключ загрузки и ключ подписи приложения могут быть разными. Потерянный ключ загрузки можно заменить через предусмотренную процедуру; это не меняет ключ, которым Google подписывает приложение для пользователей. Этот порядок описан в документации Android.
Для приёмки проверяем обновление установленной версии через подходящий тестовый канал магазина, с сохранением данных пользователя. APK, подписанный ключом загрузки, может не подойти для обновления версии, которую подписал Google. Для прямого распространения и других магазинов отдельно устанавливаем применимую схему подписи. Генерация нового ключа сама по себе не подтверждает возможность обновить старую установку.
На iOS проверяем доступы Apple Developer и App Store Connect, идентификатор приложения, сертификаты, профили и используемые возможности. Если аккаунт компании сохраняется, новая команда получает нужные роли. Перенос приложения между аккаунтами проверяют отдельно, когда меняется аккаунт размещения.
В процедуре Apple перенос начинают и принимают владельцы аккаунтов Account Holder. Для приложения с уведомлениями, Sign in with Apple или другими связанными возможностями есть отдельные действия. Доступ к карточке магазина не подтверждает, что новая команда получила серверные подключения этих функций.
Google также выделяет настройки связанных сервисов при переносе, включая Firebase. Перед первым выпуском сверяем аккаунты магазина, сервера, входа, уведомлений и аналитики. Каждую используемую связь проверяем на устройстве.
Переключите сопровождение и примите результат
Мы предлагаем согласовать одну точку передачи ответственности: какая команда наблюдает за рабочей системой, кто выпускает обновления, кто принимает сообщения об ошибках и кто решает вопрос возврата версии. В переходный период это особенно важно: два исполнителя не должны независимо менять одну рабочую среду.
Например, новая команда сначала получает персональную роль в панели сервера и проверяет тестовый выпуск. Затем по карте зависимостей меняет служебные секреты и отзывает ненужные доступы прежней команды. Перед отключением старого ключа выясняем, какие серверы и установленные версии ещё его используют. Для таких изменений согласуем порядок переключения и период совместимости.
Мобильное обновление доходит до пользователей постепенно. Сервер должен поддерживать согласованный набор старых и новых версий. Возврат серверного выпуска не возвращает автоматически приложение на телефоне пользователя; для мобильной части планируем отключение проблемной функции или исправляющий выпуск. Эти ограничения включаем в условия перехода.
Что новая команда демонстрирует на приёмке
К протоколу приёмки прикладываем точные версии кода и сборок, инструкции, результаты проверок и список незакрытых вопросов с ответственными. Секреты остаются в защищённом хранилище. Если выпуск пока заблокирован, указываем причину и условия следующего шага: например, ожидаем роль в магазине или доступ к пакету.
Как заказать и оценить первый этап
Первую смету удобнее разделить на диагностику, восстановление и подготовку выпуска. Диагностика выясняет, какие материалы доступны и что мешает работе. Восстановление закрывает найденные препятствия. Подготовка выпуска подтверждает подпись, совместимость и контрольные сценарии. Новые функции добавляем после того, как понятна исходная система.
На состав работ влияют число приложений и серверных компонентов, состояние инструкций, недоступные библиотеки, схема подписи, качество резервных копий и внешние интеграции. Если прежняя команда отвечает, часть вопросов можно закрыть передачей материалов. Если связь утрачена, закладываем восстановление контекста по доступному коду и журналам.
При выборе подрядчика просите назвать результат первого этапа: конкретную версию для проверки, перечень препятствий, план исправлений и критерии приёмки. Команда должна объяснить, какие действия она уже сможет выполнить с имеющимися доступами и какие зависят от владельцев сервисов. Состав дальнейшей работы описан на странице доработки мобильных приложений.
Для компаний из Москвы, Санкт-Петербурга и других городов России мы предлагаем удалённый разбор: показ проблемного сценария, перечень доступов без секретов и сведения о сборке. Если среда доступна только из корпоративной сети или требуется участие администратора на месте, включаем это в порядок диагностики заранее.
Частые вопросы о передаче приложения
Что делать, если разработчик не передал исходный код приложения?
Зафиксировать текущий выпуск и доступные материалы, запросить комплект у прежней команды, проверить принадлежащие компании хранилища и резервные копии. После этого заказать диагностику восстановимости. Если исходного проекта нет, замену или новую разработку оценивают отдельно.
Можно ли принять проект без документации?
Можно начать диагностику по коду, сборочным материалам, доступным журналам и работающему приложению. Приёмка перехода потребует восстановленной инструкции сборки, карты ресурсов и проверенного порядка запуска. Недостающие сведения фиксируем до оценки дальнейшей работы.
Достаточно ли успешной сборки для передачи новой команде?
Потребуются также проверка серверной части и данных, доступов для выпуска, подписи и критических сценариев. Приёмка должна подтвердить, что новая команда может обновлять продукт и восстанавливать согласованные компоненты после сбоя.
Нужно ли сразу переносить приложение в другой аккаунт магазина?
Если аккаунт компании сохраняется, обычно начинают с назначения ролей новой команде. При смене аккаунта размещения проверяют условия переноса конкретной площадки и отдельно настройки связанных сервисов.
Документы для проверки платформенных условий
Сведения о сборке, подписи и переносе сверены 7 октября 2026 года по документации GitHub, Gradle, Android, Apple и Google Play, ссылки на неё стоят рядом с соответствующими объяснениями. Перед вашим выпуском мы повторно проверяем применимые правила для конкретного приложения и аккаунта.
Разберём, что мешает передать приложение
Покажите проблемный сценарий, состав доступов и состояние сборки. Мы определим, какие материалы доступны и какой первый этап диагностики нужен. Его результатом станет план первых исправлений с критериями проверки.
Для первого разговора достаточно списка ресурсов и описания ошибки. Пароли, ключи и клиентские данные не нужны.