Деплой прототипа: как открыть проект жюри и не потерять настройки
Как развернуть прототип хакатона: проверить сборку, переменные окружения, доступ жюри и тестовые данные, сохранить рабочую версию перед финалом.
Проект работает у разработчика, но по внешней ссылке открывается пустой экран. Причина может быть в сборке, настройках сервера, адресе API или отсутствии данных. Поэтому первый деплой стоит делать, когда появился минимальный рабочий маршрут. К финалу публикация должна быть знакомой процедурой.
Для хакатонного прототипа достаточно понятного адреса, воспроизводимой сборки и доступа к заявленному сценарию. Не усложняйте инфраструктуру без требования задачи. Но и не считайте успешное сообщение платформы доказательством: после развёртывания результат нужно открыть с другого устройства.
Назначьте владельца публикации
Один участник следит за сборкой, настройками и текущей версией демо. Ещё один умеет повторить запуск и знает, где искать ошибки. Это особенно полезно перед финалом, когда основной разработчик может одновременно отвечать ментору или готовить выступление.
Договоритесь, какая ветка или зафиксированная версия отправляется на сервер. Случайное изменение в рабочей ветке не должно незаметно заменить проверенное демо. Для общей работы используйте согласованный порядок объединения кода.
Запишите адрес проекта, идентификатор развёртывания, время проверки и ответственного. Храните эти сведения рядом с инструкцией запуска. Доступ к личному кабинету автора не должен быть единственным способом понять, какая версия сейчас доступна жюри.
Разберите различия локальной и внешней среды
Проверьте команду сборки, версию среды, каталог приложения и команду запуска. Если проект состоит из интерфейса и сервера, убедитесь, что опубликованы обе части. Отдельно проверьте, откуда берётся адрес API и не остался ли там локальный адрес компьютера разработчика.
Составьте список настроек. Для каждой укажите назначение, окружение и момент чтения: во время сборки или при запуске, если используемый инструмент различает эти этапы. Сверяйте поведение с его документацией. Изменение настройки после сборки не всегда меняет уже подготовленные файлы интерфейса.
Не переносите файл окружения в публичный репозиторий. Если сборка выполняется через GitHub Actions, используйте предусмотренные платформой секреты; способы передачи значений в workflow описаны в документации GitHub. Наличие секрета в настройках CI не делает безопасной его последующую запись в клиентский код или журнал.
