Как показать локальный сайт заказчику и передать его на тестирование

Чтобы показать локальный сайт заказчику, можно открыть его через HTTPS-туннель. Заказчику понадобится браузер и ссылка; приложение продолжит работать на компьютере разработчика. Для короткой демонстрации этого достаточно, если заранее проверить API, авторизацию и время доступности.

Ниже — порядок подготовки демо, который помогает избежать ситуации «у меня работает, у коллеги пустой экран».

1. Выберите, что именно показывать

Для обсуждения вёрстки подходит dev-сервер с горячей перезагрузкой. Для передачи QA лучше зафиксировать коммит и, если проект это поддерживает, собрать production-версию. Иначе приложение может измениться прямо во время воспроизведения ошибки.

Запишите версию, сценарий проверки и ожидаемый результат. Например: «Ветка checkout, коммит abc123; добавить тестовый товар и проверить расчёт доставки». Не используйте для демо реальные платёжные данные и персональные данные клиентов.

2. Проверьте сайт локально и откройте туннель

Предположим, веб-приложение слушает порт 3000:

curl -i http://127.0.0.1:3000/
ssh -p 2222 -o ExitOnForwardFailure=yes -R 80:127.0.0.1:3000 tunnelhunt.ru

Адрес из терминала — ссылка для демонстрации. Если это ваш первый туннель, используйте полный пример запуска.

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

3. Уберите localhost из запросов браузера

В браузере заказчика http://localhost:8080 означает компьютер заказчика. Поэтому frontend с таким API-адресом не получит данные от вашего backend.

Для совместного демо удобен единый origin: браузер вызывает относительный /api, а локальный сервер frontend проксирует запрос на backend. Например, для Vite:

import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    port: 3000,
    strictPort: true,
    allowedHosts: ['YOUR-SUBDOMAIN.tunnelhunt.ru'],
    proxy: {
      '/api': 'http://127.0.0.1:8080',
    },
  },
});

Замените hostname точным именем туннеля. Этот пример сохраняет префикс /api: backend должен обслуживать такой путь. Настройки описаны в документации Vite.

Если frontend и API открываются через разные публичные домены, настройте CORS на API, cookies и HTTPS для каждого origin. Туннель сам не устраняет ограничения браузера.

4. Подготовьте тестовый вход

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

Если приложение перенаправляет на OAuth-провайдера, добавьте точный callback URL тестового окружения в разрешённые адреса провайдера. После завершения демонстрации удалите временный callback, если он больше не нужен.

5. Передайте QA достаточно контекста

Вместе со ссылкой укажите:

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

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

6. Завершите демонстрацию

Остановите SSH через Ctrl+C и проверьте, что ссылка больше не открывает ваше приложение. Завершите тестовую сессию пользователя и отключите временные интеграции, если они были созданы для показа.

Если QA должен работать независимо от вашего ноутбука, вынесите приложение на отдельный тестовый стенд. Туннель подходит для согласованного окна демонстрации; постоянно доступный стенд требует отдельного работающего хоста.

Смежные сценарии: приложение в Docker, локальный backend на телефоне и отладка вебхуков.