Pair programming через туннель — доступ к dev

Проблема: удалённая работа без доступа к машинам друг друга

Удалённый pair programming звучит просто: два разработчика работают над одним кодом одновременно. На практике логистика оказывается болезненной. Разработчик A запускает веб-приложение на localhost:3000. Разработчик B должен его увидеть, протестировать и отладить. Но localhost на то и localhost — он не существует за пределами машины.

Стандартные обходные решения неудобны:

• Screen sharing — Разработчик B смотрит видеопоток. Он не может взаимодействовать с приложением, открыть DevTools или протестировать на своём устройстве. Задержка раздражает.
• Деплой на staging — каждое изменение требует push, сборки и деплоя. Цикл обратной связи растягивается с секунд до минут.
• VPN — соединение двух разработчиков через корпоративный VPN требует инфраструктуры, настройки и поддержки IT. Избыточно для pair programming сессии.
• Клонировать и запустить локально — Разработчик B пуллит ветку, устанавливает зависимости, настраивает переменные окружения, запускает проект. Это может занять 15 минут и больше, а различия в окружении приводят к проблеме «у меня на машине работает».

Ни один из этих подходов не даёт Разработчику B мгновенный интерактивный доступ к работающему приложению Разработчика A. Туннель — даёт.

Решение: туннель превращает localhost в общую среду

Туннель создаёт публичный HTTPS-адрес, который указывает на ваш локальный сервер. Когда коллега открывает ссылку, он видит ваше работающее приложение — то же состояние, те же данные, то же поведение. Каждое изменение кода отражается мгновенно (если вы используете dev-сервер с hot reload).

Рабочий процесс прост:

1. Разработчик A запускает приложение локально.
2. Разработчик A выполняет fxtunnel http 3000.
3. Разработчик A отправляет публичный URL Разработчику B.
4. Разработчик B открывает URL в браузере.
5. Оба разработчика видят одно и то же живое приложение.

# Разработчик A: запускает приложение и создаёт туннель
npm run dev
# -> http://localhost:3000

fxtunnel http 3000

Результат:

fxTunnel v1.x — tunnel is active
Public URL:  https://pair-abc.fxtun.dev
Forwarding:  https://pair-abc.fxtun.dev -> http://localhost:3000

Press Ctrl+C to stop

Разработчик B открывает https://pair-abc.fxtun.dev в браузере — видит приложение, может кликать по нему, открывать DevTools, инспектировать сетевые запросы и тестировать функционал самостоятельно. Никакой настройки на его стороне.

Как устроен туннель изнутри – разобрано в статье «Что такое туннелирование».

Сценарий 1: Код-ревью на живом приложении

Код-ревью в diff на GitHub полезно, но ограничено. Вы видите, что изменилось в коде, но не видите, как приложение реально себя ведёт. Правильно ли выровнена новая кнопка? Срабатывает ли валидация формы на нужных полях? Возвращает ли API ожидаемый ответ?

Туннель позволяет ревьюеру взаимодействовать с работающим приложением прямо во время ревью.

Рабочий процесс

# Автор PR запускает приложение на своей ветке
git checkout feature/new-checkout-flow
npm run dev
# -> http://localhost:3000

# Открывает туннель
fxtunnel http 3000
# -> https://review-abc.fxtun.dev

Автор размещает URL в комментарии к PR:

## Preview

Живой превью: https://review-abc.fxtun.dev

Протестируйте новый checkout:
1. Добавьте товар в корзину
2. Нажмите «Оформить заказ»
3. Заполните форму и отправьте

Ревьюер открывает ссылку, тестирует флоу и оставляет комментарии прямо в PR — основываясь на реальном опыте взаимодействия, а не только на чтении кода.

Ревью фронтенда + бэкенда

Если PR затрагивает и фронтенд, и API, откройте два туннеля:

# Терминал 1 — фронтенд
fxtunnel http 3000
# -> https://front-review.fxtun.dev

# Терминал 2 — API
fxtunnel http 8000
# -> https://api-review.fxtun.dev

Обновите конфигурацию фронтенда, чтобы он обращался к туннелю API:

# .env.local
REACT_APP_API_URL=https://api-review.fxtun.dev

Ревьюер может протестировать весь стек, не пуллив ветку и не запуская ничего локально.

Сценарий 2: VS Code Live Share + туннель

VS Code Live Share — отличный инструмент для совместного редактирования: два разработчика видят один и тот же код, могут редактировать одновременно и делить терминалы. Но Live Share не даёт гостю доступ к работающему приложению в браузере. Гость видит код, но не может открыть localhost:3000 — этот адрес существует только на машине хоста.

Туннель заполняет этот пробел.

Настройка

Хост (Разработчик A):

1. Откройте VS Code и запустите Live Share сессию (Ctrl+Shift+P -> Live Share: Start Collaboration Session).
2. Запустите dev-сервер в терминале VS Code.
3. Откройте туннель к порту dev-сервера.

# В терминале VS Code
npm run dev
# -> http://localhost:3000

fxtunnel http 3000
# -> https://liveshare-abc.fxtun.dev

4. Отправьте гостю ссылку Live Share и URL туннеля.

Гость (Разработчик B):

1. Присоединяется к Live Share сессии — теперь может редактировать код вместе с хостом.
2. Открывает URL туннеля в браузере — видит работающее приложение.
3. Каждое изменение кода от любого разработчика отражается в приложении (через hot reload).

Настройки VS Code для интеграции с туннелем

Можно создать VS Code task, который автоматически запускает туннель вместе с dev-сервером:

// .vscode/tasks.json
{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "Dev Server",
      "type": "shell",
      "command": "npm run dev",
      "isBackground": true,
      "problemMatcher": []
    },
    {
      "label": "Tunnel",
      "type": "shell",
      "command": "fxtunnel http 3000",
      "isBackground": true,
      "problemMatcher": [],
      "dependsOn": "Dev Server"
    },
    {
      "label": "Pair Programming",
      "dependsOn": ["Dev Server", "Tunnel"],
      "problemMatcher": []
    }
  ]
}

Запустите задачу «Pair Programming», и dev-сервер с туннелем стартуют вместе. URL туннеля появится в терминале — скопируйте и отправьте коллеге.

Сценарий 3: Совместная отладка

Отладка сложнее в удалённом формате. Когда обнаруживается баг, нужно, чтобы коллега видел точное состояние приложения — сломанную страницу, упавший запрос, ошибку в консоли. Screen sharing показывает сжатое видео. Туннель даёт полный интерактивный доступ.

Отладка фронтенд-бага

Разработчик B сообщает о визуальном баге. Разработчик A открывает туннель и просит Разработчика B воспроизвести баг по URL.

# Разработчик A
fxtunnel http 3000
# -> https://debug-abc.fxtun.dev

Разработчик B открывает URL, воспроизводит баг и открывает DevTools. Он может:

• Инспектировать DOM и CSS для выявления проблем вёрстки.
• Проверить консоль на наличие JavaScript-ошибок.
• Изучить сетевые запросы на предмет упавших вызовов API.
• Протестировать на своём устройстве и в своём браузере (который может быть именно тем, где проявляется баг).

Это продуктивнее, чем просить Разработчика B описать баг в чате или записать видео.

Отладка API с Inspector

При отладке проблем с API незаменим встроенный Traffic Inspector. Inspector показывает каждый HTTP-запрос, проходящий через туннель, в реальном времени — заголовки, тело запроса, статус и тело ответа.

# Запуск туннеля с Inspector (от $5/мес)
fxtunnel http 8000

Оба разработчика могут просматривать Inspector в браузере. Когда Разработчик B отправляет запрос через туннель, Разработчик A видит точный payload и ответ. Если запрос падает, Разработчик A может использовать функцию Replay, чтобы повторить его, пошагово проходя код в дебаггере.

Отладка с несколькими сервисами

Сложные приложения включают несколько сервисов. Во время pair programming сессии можно открыть их все:

# Терминал 1 — фронтенд (React на порту 3000)
fxtunnel http 3000
# -> https://front-debug.fxtun.dev

# Терминал 2 — API (Express на порту 8000)
fxtunnel http 8000
# -> https://api-debug.fxtun.dev

# Терминал 3 — WebSocket-сервер (порт 8081)
fxtunnel http 8081
# -> https://ws-debug.fxtun.dev

Коллега может взаимодействовать с фронтендом, обращаться к API напрямую и даже подключиться к WebSocket-серверу — всё через публичные URL. Такой уровень доступа делает удалённую отладку столь же эффективной, как работу за одним столом.

Сценарий 4: QA-тестирование в процессе разработки

QA-инженеры часто не могут протестировать фичу, пока она не окажется на staging-сервере. Это создаёт узкое место: разработчик заканчивает фичу, ждёт деплоя, а потом ждёт фидбека от QA. С туннелем QA может тестировать фичу, пока разработчик ещё работает над ней.

Рабочий процесс

# Разработчик открывает туннель и делится URL с QA
fxtunnel http 3000
# -> https://qa-test.fxtun.dev

Разработчик публикует URL в командном канале:

Фича «редактирование профиля пользователя» готова к тестированию:
https://qa-test.fxtun.dev/profile

Сценарии для проверки:
- Редактирование имени и сохранение
- Загрузка аватара (JPEG, PNG)
- Смена пароля

QA-инженер открывает ссылку и тестирует. Когда находит баг:

1. QA описывает баг с шагами воспроизведения.
2. Разработчик исправляет его локально.
3. Исправление мгновенно доступно через туннель (hot reload).
4. QA обновляет страницу и проверяет исправление.

Цикл от «баг найден» до «исправление проверено» занимает минуты, а не часы.

QA-тестирование на мобильных устройствах

Если фича имеет мобильную составляющую, QA может открыть URL туннеля на реальном телефоне. Никакой специальной настройки – это обычная HTTPS-ссылка. Другие сценарии мобильного тестирования описаны в статье о мобильных приложениях.

Сценарий 5: Демонстрации клиентам во время pair-сессий

Иногда pair programming включает нетехнического участника — продакт-менеджера, дизайнера или клиента. Им нужно видеть приложение, а не код. URL туннеля позволяет им следить за процессом в реальном времени.

# Разработчик делится URL туннеля во время созвона
fxtunnel http 3000
# -> https://demo-pair.fxtun.dev

Клиент открывает URL на своём устройстве и видит приложение. Разработчик вносит изменения — клиент видит их после обновления страницы. Это интерактивнее, чем screen sharing, потому что клиент может навигировать самостоятельно, тестировать на своём устройстве и взаимодействовать с приложением в своём темпе.

Для профессиональных демонстраций клиентам используйте кастомный домен (от $5/мес):

fxtunnel http 3000 --domain preview.yourcompany.com

Брендированный URL выглядит солиднее случайного поддомена, а в статье о демонстрациях есть ещё советы, как сделать такие показы гладкими.

Настройка окружения для pair programming

Полный чеклист для продуктивной удалённой pair programming сессии с туннелями.

Предварительные требования

# Установка fxTunnel
curl -fsSL https://fxtun.dev/install.sh | bash

# Проверка установки
fxtunnel --version

Конфигурационный файл для регулярных сессий

Если вы занимаетесь pair programming регулярно, создайте конфигурацию, чтобы не набирать команды туннеля каждый раз:

# Запуск нескольких туннелей для фулстек-проекта
#!/bin/bash
# pair-session.sh

echo "Запуск окружения для pair programming..."

# Запуск фронтенда
npm run dev &
FRONTEND_PID=$!

# Запуск API
cd api && npm start &
API_PID=$!

# Ждём запуска серверов
sleep 3

# Открываем туннели
fxtunnel http 3000 --log-file /tmp/tunnel-front.log &
fxtunnel http 8000 --log-file /tmp/tunnel-api.log &

echo "Туннель фронтенда: см. /tmp/tunnel-front.log для URL"
echo "Туннель API: см. /tmp/tunnel-api.log для URL"
echo "Нажмите Ctrl+C для остановки"

wait

Переменные окружения для URL туннелей

Настройте приложение для использования переменных окружения для URL API, чтобы переключение между localhost и туннелем занимало одну строку:

# .env.development
API_URL=http://localhost:8000

# .env.tunnel (для pair programming сессий)
API_URL=https://api-pair.fxtun.dev

# Запуск с конфигурацией для туннеля
DOTENV=.env.tunnel npm run dev

Безопасность при pair programming

Открытие локального сервера в интернет требует внимания. Вот основные правила (подробный гайд по безопасности раскрывает тему полнее).

Лучшие практики

• Закрывайте туннель после завершения сессии. Нажмите Ctrl+C. Не оставляйте туннели запущенными на ночь.
• Используйте тестовые данные. Никогда не открывайте базу данных с реальными пользовательскими данными через туннель.
• Храните секреты в .env файлах. API-ключи, пароли баз данных и токены не должны быть в исходном коде.
• Не открывайте админ-панели. Если в приложении есть роут /admin, убедитесь, что он требует аутентификации.

Что не стоит делать

Контроль доступа

Для сессий, которые длятся дольше быстрого pair programming созвона, рассмотрите дополнительные меры безопасности:

# Кастомный домен для стабильных и узнаваемых URL (от $5/мес)
fxtunnel http 3000 --domain pair.yourteam.dev

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

Сравнение: туннель vs другие инструменты удалённой работы

Связка fxTunnel и VS Code Live Share закрывает обе потребности: совместное редактирование кода и полный интерактивный доступ к работающему приложению.

Тарифы для команд, практикующих pair programming

Для большинства сценариев pair programming хватает бесплатного тарифа – неограниченные туннели, HTTPS, стабильные URL. Если в вашем процессе регулярно нужна отладка API или брендированные домены для показов клиентам, платные тарифы (от $5/мес за кастомные домены и Inspector, от $10/мес за 10+ туннелей) закрывают эти задачи.

Как fxTunnel соотносится с альтернативами? Сравнение – в статье «ngrok vs Cloudflare Tunnel vs fxTunnel».

FAQ

Как поделиться локальным dev-окружением с удалённым коллегой?

Одна команда – fxtunnel http 3000 – создаёт публичный HTTPS-адрес. Отправьте ссылку коллеге, и он увидит ваше работающее приложение прямо в своём браузере с полным доступом к DevTools. Ни деплоя, ни VPN, ни правил файрвола.

Можно ли использовать туннель вместе с VS Code Live Share?

Конечно. Live Share берёт на себя совместное редактирование, а fxTunnel даёт обоим разработчикам URL работающего приложения. Запустите Live Share для кодовой базы и fxtunnel http 3000 для приложения – вместе они покрывают и написание кода, и тестирование.

Безопасно ли делиться dev-окружением через туннель?

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

Могут ли два разработчика подключиться к одному URL туннеля?

URL – это обычный HTTPS-адрес, количество одновременных посетителей не ограничено. Каждый видит одно и то же состояние приложения, что удобно для код-ревью, прогонов QA и демонстраций.

Добавляет ли туннель заметную задержку при pair programming?

На практике нет. Туннель добавляет порядка 10-30 мс – ощущения такие же, как при обычном веб-сёрфинге. Для совместного редактирования кода VS Code Live Share использует собственный низколатентный протокол отдельно от туннеля, так что ни та, ни другая сторона не тормозит.