- Регистрация
- 23 Авг 2023
- Сообщения
- 3,969
- Реакции
- 0
- Баллы
- 36
Ofline
Привет! Меня зовут Владислав Лаптев, я директор по инновациям в Fork-Tech. Сегодня РБК выпустил материал о том, что замедление Telegram срывает релизы мобильных приложений в России. Мы дали комментарий для этого материала, и я решил рассказать подробнее, потому что проблема не в Telegram. Проблема в том, что российские мобильные разработчики третий раз за четыре года теряют инструмент доставки сборок.
Мы создали PWS (Product Web Services) — платформу для управления цифровыми продуктами. Сегодня речь про модуль App Distribution: как мы к нему пришли, где взяли лучшее от Firebase, почему этого было мало, и как всё работает под капотом. С примерами кода из документации. Платформа включена в реестр российского ПО.
Четыре года без нормального инструмента
2022 — Google ограничивает доступ к Firebase для российских компаний. Firebase App Distribution — основной инструмент для раздачи тестовых сборок — становится недоступен. 2025 — Microsoft закрывает App Center. Apple отзывает корпоративные сертификаты (ADEP) у российских компаний. Февраль 2026 — Роскомнадзор замедляет Telegram.
После потери Firebase и App Center команды массово ушли в Telegram. Собрали ботов, через которых рассылали ссылки на скачивание сборок с внешних хранилищ — именно ссылки, а не файлы: Bot API ограничивает размер файла 50 МБ, а банковское приложение весит 80–150 МБ. Для iOS это тем более не работает — OTA-установка .ipa требует manifest.plist, который Telegram генерировать не умеет. Но деваться было некуда — Telegram стал де-факто инфраструктурным звеном CI/CD-пайплайна.
10 февраля Telegram замедлили. Да, он по-прежнему доступен. Но доля таймаутов при работе с Bot API выросла до 28% в отдельных регионах, и вектор очевиден: сегодня замедление, завтра — регулярные сбои, послезавтра — запрет использования в корпоративных процессах. Для CI/CD-пайплайна, который каждый день рассылает ссылки на сборки по группам тестирования, это уже сейчас создаёт проблемы.
Timeline-инфографика
Сотни сборок в месяц — и ни одного нормального инструмента на российском рынке
В крупных компаниях команды разработки мобильных приложений генерируют сотни сборок в месяц. Это 15–20 билдов в день. Каждый нужно доставить нужной группе тестирования, обеспечить установку на устройство, сохранить Release Notes, при необходимости ограничить доступ.
Когда единственный канал доставки - Telegram-бот со ссылками на внешнее хранилище, вы получаете:
Отсутствие ролевой модели. Ссылки свободно можно пересылать, нет разделения на роли viewer и editor. Необходимо разрабатывать собственную матрицу доступов и инструменты администрирования.
OTA для iOS невозможен. Без manifest.plist — нет установки .ipa через браузер. Нужен отдельный хостинг.
Нет аудита. Кто скачал? Когда? Информация недоступна. Необходимо прикручивать собственную систему логирования к боту.
Внешняя зависимость. Telegram не контролируется вашей компанией. Сегодня он замедлен, завтра может быть заблокирован или запрещён для корпоративного использования. Мы уже теряли инфраструктуру дважды за четыре года.
RuStore и PWS App Distribution решают разные задачи. RuStore — магазин приложений: публикация готового релиза для широкой аудитории. PWS — доставка предрелизных сборок внутренним командам в процессе разработки. Два разных этапа жизненного цикла.
Только Android. iOS-сборки RuStore не поддерживает — для кроссплатформенных команд это половина потребности. Нет On-Premise. Для банков, которым нужно держать сборки внутри контура, облачный сервис не подходит. VK ID вместо корпоративного SSO. Для enterprise с AD/LDAP это параллельное управление учётными записями.
В идеальном пайплайне PWS и RuStore работают вместе: сборка проходит через PWS (тестирование, QA, обратная связь), а затем релиз публикуется в RuStore для пользователей.
Цикл разработки мобильных приложений
Почему мы этим занялись
Мы работаем с компаниями из регулируемых отраслей — банки, страхование, телеком. И видим эту проблему изнутри: вместе с нашими клиентами мы прошли через потерю Firebase, закрытие App Center, отзыв ADEP. Каждый раз — экстренный поиск замены, миграция, костыли. Это общая боль, и она подтолкнула нас к созданию платформы.
В феврале 2025 мы начали разработку PWS — платформы, которая объединяет Remote Config, Feature Flags, App Distribution и матрицу доступов. По сути — enterprise-альтернатива Firebase, которую можно развернуть On-Premise.
Что мы взяли от Firebase App Distribution
Firebase App Distribution был хорошим продуктом. Он задал стандарт рынка, и мы честно скажем: мы брали от него лучшее.
Группы тестирования — возможность создавать группы и назначать доступ к конкретным сборкам. Загрузка через API — интеграция с CI/CD. Release Notes — описание изменений, привязанное к сборке. Кроссплатформенность — Android (.apk) и iOS (.ipa) из единого интерфейса. Простота для тестировщика — получил ссылку, открыл, установил. Мы реализовали это через PWA-приложение.
PWS - PWA приложение для установки предрелизных сборок приложений
Почему Firebase было мало
Нет On-Premise. Firebase — только облако Google. Для банка, которому нельзя хранить сборки за рубежом, нерешаемая проблема. PWS разворачивается на вашем сервере.
Нет корпоративного SSO. Firebase работает через Google-аккаунты. PWS интегрируется с корпоративным SSO.
Нет окружений (Environments). В Firebase нельзя разделить dev, staging, production на уровне платформы. У нас окружения закладывались с самого начала.
Нет гибкого RBAC. Нам нужно: администратор организации, администратор проекта, менеджер сборок, тестировщик с доступом к определённым группам, сервисный аккаунт для CI/CD. Мы реализовали матрицу доступов.
Что мы построили: архитектура
PWS App Distribution — экосистема из четырёх компонентов.
Консоль администратора (Web UI)
Основной интерфейс: создание проектов, загрузка сборок, управление группами тестирования, настройка доступов, Release Notes, приватный и публичный доступ.
PWA-приложение для установки
Тестировщик получает ссылку, открывает в браузере и видит список доступных сборок. Для Android — стандартная загрузка .apk. Для iOS — OTA-установка: браузер обращается к manifest.plist, iOS загружает и устанавливает .ipa. Без TestFlight, без App Store.
REST API
Полноценный API для автоматизации: загрузка сборок из CI/CD, получение списка релизов, распространение по группам, управление Release Notes. Документация открытая, с примерами на шести языках. Подробнее — в следующем разделе.
MCP-сервер
Платформа поддерживает Model Context Protocol — открытый стандарт для подключения AI-ассистентов (Claude, Cursor, GigaChat и других) к внешним сервисам. Через MCP-сервер агенты могут запрашивать информацию о сборках и управлять релизами программно.
Web-консоль PWS
Интеграция с CI/CD: примеры из документации
Самое ценное для разработчиков — возможность встроить дистрибуцию в пайплайн и забыть о ручной работе. Все примеры ниже — из публичной документации PWS.
Загрузка сборки: POST /v1/builds
Загружает файл и автоматически создаёт релиз. Версия и номер сборки извлекаются из метаданных файла:
curl -X POST "https://<DOMAIN>/v1/builds" \
-H "Authorization: Bearer <API_KEY>" \
-F "file=@app-release.apk" \
-F "description=Версия 2.5.1:\n- Исправлена авторизация по биометрии\n- Обновлён SDK платёжного шлюза"
Ответ — 202 Accepted:
{
"status": "processing",
"message": "The build has been saved",
"buildId": "e891fc1d-d7ab-4be5-b5a1-228a6e6716de",
"releaseId": "6b35f2c5-fe2e-4654-b747-b4572783af9a",
"buildNumber": 1,
"buildVersion": "2.5.1"
}
Распространение релиза: POST /v1/releases/{releaseId}/distribute
После загрузки сборку нужно распространить на группы тестирования. Можно указать конкретные группы и отправить email-уведомления:
curl -X POST "https://<DOMAIN>/v1/releases/6b35f2c5-fe2e-4654-b747-b4572783af9a/distribute" \
-H "Authorization: Bearer <API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"access": "private",
"groupIds": ["group-uuid-qa", "group-uuid-stakeholders"],
"sendNotification": true,
"notificationChannels": ["email"]
}'
Ответ:
{
"status": "success",
"message": "Test groups successfully added to the release. Notifications sent via email."
}
GitLab CI: полный stage
Вот готовый stage, который собирает Release Notes из git log, загружает сборку и распространяет на группу тестирования:
# .gitlab-ci.yml
distribute_to_pws:
stage: distribute
needs:
- job: build_release
artifacts: true
script:
# Release Notes из последних коммитов
- RELEASE_NOTES=$(git log --oneline -5 --pretty=format:'- %s')
# Находим собранный APK
- APK_PATH=$(find app/build/outputs/apk/release -name '*.apk' | head -1)
# Шаг 1: Загружаем сборку
- |
UPLOAD_RESPONSE=$(curl -s -X POST \
"$PWS_BASE_URL/v1/builds" \
-H "Authorization: Bearer $PWS_API_KEY" \
-F "file=@$APK_PATH" \
-F "description=$RELEASE_NOTES")
- RELEASE_ID=$(echo $UPLOAD_RESPONSE | jq -r '.releaseId')
- BUILD_VERSION=$(echo $UPLOAD_RESPONSE | jq -r '.buildVersion')
- echo "Сборка $BUILD_VERSION загружена, releaseId: $RELEASE_ID"
# Шаг 2: Распространяем на группу тестирования
- |
curl -s -X POST \
"$PWS_BASE_URL/v1/releases/$RELEASE_ID/distribute" \
-H "Authorization: Bearer $PWS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"access": "private",
"groupIds": ["'$PWS_QA_GROUP_ID'"],
"sendNotification": true,
"notificationChannels": ["email"]
}'
- echo "Релиз распространён на QA-группу"
only:
- develop
- /^release.*$/
variables:
PWS_BASE_URL: https://pws.company.ru
# PWS_API_KEY и PWS_QA_GROUP_ID задаются в CI/CD Variables (masked)
Список релизов: GET /v1/releases
Для дашбордов или интеграции с другими системами — можно запросить список релизов, сгруппированных по версиям:
curl -s -X GET "https://<DOMAIN>/v1/releases?page=1&pageSize=50" \
-H "Authorization: Bearer <API_KEY>" | jq .
Ответ содержит версии с вложенными релизами, ссылками для скачивания и QR-кодами:
{
"status": "success",
"totalCount": 2,
"page": 1,
"pageSize": 50,
"totalPages": 1,
"versions": [
{
"version": "2.5.1",
"totalReleases": 1,
"releases": [
{
"id": "7fd896a6-ab07-4f23-b584-b172279c2f3e",
"number": 1,
"description": "Исправления багов",
"access": "private",
"status": "success",
"createdAt": "2026-02-12T14:30:00Z",
"build": {
"id": "fc764c00-d24d-49ce-83f3-e929691671ac",
"scanStatus": "success",
"downloadUrl": "https://<DOMAIN>/app/application/private?releaseId=...",
"qrUrl": "https://storage.example.ru/qr_xxx.png"
}
}
]
}
]
}
Полная документация API с примерами: публичная документация PWS
Приватная и публичная дистрибуция
Приватная дистрибуция. Тестировщик авторизуется в системе. Доступ определяется ролью и группой. Для внутренней разработки, когда сборки содержат чувствительную бизнес-логику.
Публичная дистрибуция. Сгенерированная ссылка работает без авторизации. Для демонстрации стейкхолдерам или передачи внешним тестировщикам. Ссылку можно отозвать в любой момент.
Тип доступа задаётся при распространении релиза через API (поле access: private | public) или через консоль. Для On-Premise весь трафик остаётся внутри корпоративного контура.
Сравнение: Firebase vs. Telegram vs. RuStore vs. PWS
Возможность | Firebase | Telegram | RuStore | PWS |
Доступность в РФ | Нет | Нестабилен | Да | Да |
On-Premise | Нет | Нет | Нет | Да |
iOS (.ipa) | Да | Ссылка на собственное Web-приложение | Нет | Да |
Корпоративный SSO | Нет | Нет | Нет | Да |
Гибкий RBAC | Базовый | Нет | Нет | Да |
Окружения | Нет | Нет | Нет | Да |
Реестр РПО | Нет | Нет | Да | Да |
Сейчас PWS App Distribution доступна в On-Premise варианте — мы разворачиваем платформу в контуре клиентов. Для компаний из регулируемых отраслей (банки, страхование, телеком) это основной сценарий. Если вам интересно — готовы помочь развернуть решение уже сегодня.
Параллельно мы делаем облачные демо-стенды, на которых можно самостоятельно оценить функционал: загрузить сборку, настроить группы, попробовать API. Это быстрый способ понять, подходит ли платформа вашей команде.
Мы активно готовим релиз SaaS-версии, которая станет доступна всем разработчикам без необходимости разворачивать инфраструктуру. Если хотите получить ранний доступ к SaaS — оставляйте заявку, мы включим вас в программу раннего доступа. Форма запроса раннего доступа к SaaS PWS
Документация уже открыта: Публичная документация PWS
Вместо заключения
Мы не злорадствуем по поводу ситуации с Telegram. Telegram — великолепный мессенджер, и то, что он стал инфраструктурным инструментом для разработчиков — показатель его качества. Но зависимость от внешнего канала, который вы не контролируете — это архитектурный антипаттерн.
Ситуация 2022 года повторяется. Тогда ушёл Firebase. Сейчас Telegram работает нестабильно, и нет гарантий, что завтра не станет хуже. Результат для разработчиков одинаковый — сломанный пайплайн и ручная работа.
Мы построили PWS App Distribution, потому что нам самим и нашим клиентам нужен инструмент, который контролируется компанией, работает стабильно и не зависит от внешних решений. Мы вывели его на рынок, потому что эта проблема — не только наша.
