Деплой прототипа: как открыть проект жюри и не потерять настройки

Проект работает у разработчика, но по внешней ссылке открывается пустой экран. Причина может быть в сборке, настройках сервера, адресе API или отсутствии данных. Поэтому первый деплой стоит делать, когда появился минимальный рабочий маршрут. К финалу публикация должна быть знакомой процедурой.

Для хакатонного прототипа достаточно понятного адреса, воспроизводимой сборки и доступа к заявленному сценарию. Не усложняйте инфраструктуру без требования задачи. Но и не считайте успешное сообщение платформы доказательством: после развёртывания результат нужно открыть с другого устройства.

Назначьте владельца публикации

Один участник следит за сборкой, настройками и текущей версией демо. Ещё один умеет повторить запуск и знает, где искать ошибки. Это особенно полезно перед финалом, когда основной разработчик может одновременно отвечать ментору или готовить выступление.

Договоритесь, какая ветка или зафиксированная версия отправляется на сервер. Случайное изменение в рабочей ветке не должно незаметно заменить проверенное демо. Для общей работы используйте согласованный порядок объединения кода.

Запишите адрес проекта, идентификатор развёртывания, время проверки и ответственного. Храните эти сведения рядом с инструкцией запуска. Доступ к личному кабинету автора не должен быть единственным способом понять, какая версия сейчас доступна жюри.

Разберите различия локальной и внешней среды

Проверьте команду сборки, версию среды, каталог приложения и команду запуска. Если проект состоит из интерфейса и сервера, убедитесь, что опубликованы обе части. Отдельно проверьте, откуда берётся адрес API и не остался ли там локальный адрес компьютера разработчика.

Составьте список настроек. Для каждой укажите назначение, окружение и момент чтения: во время сборки или при запуске, если используемый инструмент различает эти этапы. Сверяйте поведение с его документацией. Изменение настройки после сборки не всегда меняет уже подготовленные файлы интерфейса.

Не переносите файл окружения в публичный репозиторий. Если сборка выполняется через GitHub Actions, используйте предусмотренные платформой секреты; способы передачи значений в workflow описаны в документации GitHub. Наличие секрета в настройках CI не делает безопасной его последующую запись в клиентский код или журнал.

Подготовьте демонстрационные данные

Создайте отдельный набор, на котором можно повторить основной сценарий. Укажите, кто и как возвращает его в начальное состояние. Если несколько судей будут проверять проект одновременно, один пользователь не должен случайно удалять результат другого.

Для входа используйте специально подготовленный способ доступа с ограниченными возможностями. Не раздавайте пароль владельца инфраструктуры и не открывайте административный кабинет ради удобства демонстрации. Если вход обязателен, проверьте его так, как будет проверять внешний посетитель.

Сопоставьте ограничения прототипа с заявкой. Например, обработка может быть доступна только для подготовленных файлов. Это допустимое ограничение, если оно указано и не скрывается за обещанием поддержки любых данных. Напишите рядом с примером, какой формат реально проверен.

Пройдите маршрут внешнего пользователя

Откройте адрес в новом сеансе браузера или на другом устройстве без авторизации разработчика. Пройдите действия от первого экрана до результата. Обновите страницу результата напрямую: приложение должно вести себя так, как описано в инструкции.

Проверьте несколько неприятных, но обычных ситуаций: пустой ввод, неверный файл, повторное нажатие, недоступный внешний сервис. Не обязательно исправлять все ограничения до финала. Нужно убрать блокирующие ошибки, а оставшиеся объяснить без обещаний, которые продукт не выполняет.

Проверьте и ссылку, вставленную в заявку. Рабочий адрес в командном чате не поможет жюри, если в форме сохранён старый. Эту проверку удобно совместить с подготовкой комплекта сдачи.

Сохраните проверенную версию

Перед выступлением запишите, какое развёртывание прошло последний прогон. Узнайте штатный способ вернуться к нему. Возврат приложения и возврат данных могут быть разными операциями; не обещайте себе «откат в один клик», если миграция уже изменила структуру хранилища.

После фиксации демо принимайте только понятные исправления с повторной проверкой. Небольшая визуальная правка тоже может сломать сборку. Если изменение не помогает показать обещанный результат, его можно оставить до завершения оценки.

Наконец, договоритесь о сроке жизни демо после события и владельце расходов. Когда адрес будет отключён, обновите описание проекта и оставьте запись или инструкцию локального запуска. Деплой заканчивается проверкой доступного сценария, а не нажатием кнопки публикации.

Порядок доступа к демо сверяйте с требованиями организатора. Откройте выбранное событие через каталог Stavleak и проверьте, какие ссылки нужно передать жюри.