Как автоматизировать сбор баг-репортов и не нарушить приватность: связка Tally, Make и GitHub
Indie-разработчик приложения Timety для Android нашёл элегантный способ собирать обратную связь от пользователей, не требуя от них регистрации, и автоматически превращать её в тикеты на GitHub.
Автоматизация потоков между Tally, Make и GitHub превращает хаос пользовательских отзывов в структурированные задачи — и делает это, не посягая на конфиденциальность аудитории.
Разработка приложения — это только начало. Следующий, часто непредсказуемый этап — сбор и обработка обратной связи. Для сольного разработчика или маленькой команды превращение пользовательских баг-репортов и идей в систематизированный рабочий процесс может отнимать время, сопоставимое с написанием кода. Особенно если ваш проект, как приложение Timety для Android, строится на принципах приватности и не хочет принуждать пользователей создавать учётную запись просто для отправки отзыва.
Проблема: приватность vs. удобство сбора обратной связи
Типичный путь таков: пользователь замечает баг, ищет в приложении кнопку «Написать разработчику» и сталкивается с просьбой авторизоваться. Для многих это стоп-фактор. Обратная связь теряется. Альтернатива — уведомления по электронной почте — превращает почтовый ящик разработчика в свалку, из которой потом вручную нужно копировать данные в трекер задач, такой как GitHub Issues.
Разработчик Timety решил эту дилемму, отказавшись от привязки к аккаунту. Вместо этого он интегрировал в приложение ссылку на внешнюю форму, созданную в сервисе Tally. Это сервис для создания опросов и форм с простым интерфейсом. Пользователь заполняет форму анонимно (или указывает контакт по желанию), а разработчик получает структурированные данные.
Но появилась новая проблема: Tally по умолчанию отправляет ответы на электронную почту. Для управления проектом используется GitHub, где Issues и Discussions — основные единицы работы. Ручное перенесение каждого сообщения из письма в тикет — рутина, убивающая продуктивность.
Решение: построение конвейера на платформе Make
Выход был найден в использовании платформы автоматизации Make (ранее Integromat). Она позволяет связывать разные веб-сервисы в единую цепочку действий без написания кода. Разработчик создал workflow (рабочий процесс), который:
- Ловит каждую новую отправку формы из Tally.
- Анализирует тип ответа: это баг-репорт, запрос на функцию или общий отзыв?
- Маршрутизирует данные по разным веткам: баг-репорты и идеи создают Issue на GitHub, а общие отзывы — Discussion.
- Уведомляет о новом тикете в канал Discord.
Архитектура этого конвейера интересна с инженерной точки зрения. Используется модуль «Router» в Make, который выступает как условный оператор, направляющий поток данных в зависимости от значения поля. Это базовый, но мощный паттерн для подобных автоматизаций.
Технические нюансы: почему GraphQL, а не готовый модуль?
Особое внимание стоит уделить реализации интеграции с GitHub. В Make есть готовый модуль для создания Issue. Однако разработчик отказался в его пользу, предпочтя отправку запроса напрямую в GitHub GraphQL API. Зачем?
Стандартный модуль создает «голый» тикет: заголовок и тело. Но в реальном проекте на GitHub Issue обычно шаблонизированы. У баг-репорта есть секции для описания шагов воспроизведения, ожидаемого и фактического поведения, информации о среде. У запроса на функцию — своя структура.
Прямой запрос к GraphQL API позволяет вставлять данные из формы Tally напрямую в HTML-шаблон, хранящийся в репозитории в папке .github/ISSUE_TEMPLATE. Результат — тикет, который выглядит как будто его заполнил сам пользователь через веб-интерфейс GitHub. Это значительно повышает качество и скорость обработки входящих обращений.
Для этого потребовалось получить внутренние идентификаторы репозитория, меток (labels) и категорий обсуждений (discussions). Простой запрос к GitHub GraphQL Explorer выводит эти уникальные строки, которые затем используются как константы в Make.
Сборка и подводные камни
Настройка такого pipeline требует первоначальных усилий. Нужно создать и настроить аккаунты в Tally и Make, авторизовать доступ к GitHub (через OAuth) и Discord. Придется один раз «прогнать» тестовую форму, чтобы Make «увидел» все доступные переменные для маппинга (сопоставления полей).
Ключевой момент надежности — резервирование. Tally продолжает дублировать отправки на почту. Если автоматизация по какой-то причине «упадет» (например, токен доступа к GitHub истечет), отзывы не потеряются. Они просто придут в почтовый ящик, и их можно будет обработать вручную.
Еще одно преимущество — модульность. Discord-уведомления — это просто ветка. Её можно отключить или заменить на Telegram, Slack, интеграцию с корпоративным мессенджером. Ядро — связка «форма -> маршрутизация -> трекер задач» — останется неизменной.
Выводы и границы применимости
Это решение идеально подходит для indie-разработчиков и небольших проектов с фокусом на приватность. Оно нивелирует недостаток в виде отсутствия системы авторизации в приложении, превращая открытую форму в мощный инструмент сбора багов.
Для крупных компаний с собственными серверами и строгими требованиями к безопасности передачи данных через сторонние сервисы (Tally, Make) этот подход может оказаться неприемлемым. Также он не подходит, если требуется многоуровневая модерация или сложные бизнес-логика обработки тикетов до их попадания в GitHub.
Тем не менее, для массы малых проектов это отличный пример того, как, не изобретая велосипед, можно выстроить профессиональный процесс сбора обратной связи с минимальными затратами. Автоматизация здесь не роскошь, а необходимое условие, чтобы разработчик мог сосредоточиться на коде, а не на перекопировании данных между сервисами.