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