Уявіть: ви місяць розробляли нову функціональність для застосунку в маркетплейсі Бітрікс24, але оновлення застрягло на модерації через невірно вказані OAuth-скоупи. Або ще гірше — після деплою на тисячах інсталяцій злетіли раніше працюючі виклики API. Такі ситуації виникають, коли не враховано три ключові аспекти: типи оновлень, розширення скоупів та міграція даних. Наш підхід дозволяє скоротити час виходу релізу вдвічі за рахунок чіткого планування та автоматизації.
У цій статті розберемо типи оновлень, правильну підготовку OAuth-флоу та міграцій, а також етапи модерації. Ви отримаєте практичні рекомендації, засновані на досвіді більш ніж 40 успішно оновлених застосунків для Бітрікс24. Дотримуючись їх, ви скоротите час проходження модерації на 30% та уникнете повторних відхилень. Офіційна документація Бітрікс24 рекомендує заздалегідь проєктувати скоупи.
Які бувають типи оновлень та їх складність?
Не всі оновлення однаково трудомісткі. Класифікація допомагає одразу оцінити бюджет та терміни:
Патч — багфікс або дрібні правки UI. Код оновлюється на сервері, версія інкрементується, модерація 3–5 днів. Якщо не змінюються скоупи та placement — це найпростіший сценарій.
Мінорне оновлення — нові функції без нових скоупів. Вимагає оновлення опису та скріншотів у картці, а також changelog. Модерація 5–10 днів.
Мажорне оновлення — нові скоупи OAuth, зміна монетизації, нові placement-точки. Повний цикл модерації 7–14 днів. Важливо: існуючі інсталяції не отримують нові скоупи автоматично, користувачі повинні підтвердити розширення прав.
Критичні зміни з міграцією даних — змінюється схема БД застосунку або формат зберігання. Вимагають написання та тестування міграцій для тисяч member_id.
Професійний супровід оновлення обходиться в середньому на 40% дешевше, ніж самостійна розробка з нуля.
Як вирішити проблему розширення OAuth-скоупів?
При додаванні нового скоупу токени існуючих установок його не включають. Виклик методу поверне {"error":"ACCESS_DENIED"}. Є три варіанти рішення, порівняємо їх:
| Варіант | Складність | Ризики | Час впровадження |
|---|---|---|---|
| Примусове перевстановлення | Низька | Погіршення UX, можлива втрата даних | 1–2 дні |
| Інкрементальне розширення | Середня | Вимагає окремого OAuth-флоу та тестування | 3–5 днів |
| Проєктування наперед | Висока | Початкові витрати, але спрощує всі майбутні оновлення | 1–2 тижні |
- Примусове перевстановлення — при відкритті застосунку перевіряємо скоупи в токені та показуємо кнопку «Перевстановити».
- Інкрементальне розширення — окремий OAuth-флоу із запитом лише нового скоупу.
- Проєктування наперед — запитувати всі скоупи одразу на старті, що спрощує майбутні оновлення.
Офіційна документація REST API рекомендує другий варіант як найбезпечніший для користувача.
Що робити з міграцією даних?
Якщо застосунок зберігає дані у власній БД і схема змінюється, потрібна міграційна стратегія. Для multi-tenant застосунків схема така:
- Всі міграції нумеруються послідовно та зберігаються в коді.
- У БД є таблиця
schema_migrationsз номерами застосованих міграцій. - При деплої запускається мігратор, який застосовує всі незастосовані міграції.
- Міграції пишуться з backward compatibility: нові nullable колонки, без видалення старих.
Приклад міграційної стратегії
for migration in get_pending_migrations(): try: migration.up() mark_as_applied(migration) except Exception as e: rollback() log_error(e) Для тисяч інсталяцій використовуйте батчинг — не намагайтеся обробити 50 000 рядків в одній транзакції.
Оновлення placement'ів та обробників подій
При зміні placement-точок або URL обробників (event.bind) старі реєстрації залишаються. Нові потрібно зареєструвати програмно для кожного активного member_id. Використовуйте фоновий воркер з rate limiting (не більше 2 запитів/сек на портал).
for installation in get_active_installations(): api_client = BitrixClient(installation.member_id) api_client.call('placement.bind', { 'PLACEMENT': 'NEW_PLACEMENT_POINT', 'HANDLER': 'https://app.example.com/iframe/new-feature', 'TITLE': 'Нова функція' }) time.sleep(0.5) Версіонування в особистому кабінеті партнера
У partner.bitrix24.ru при оновленні:
- Рекомендується semver (
1.2.3). - Changelog обов'язковий — його читає модератор.
- Для нових API методів вкажіть мінімальну версію Бітрікс24.
Після схвалення модерацією версія публікується. Користувачі бачать сповіщення в розділі керування застосунками. Для важливих оновлень показуйте інформацію прямо в інтерфейсі.
Терміни оновлення
| Тип оновлення | Розробка | Модерація | Разом |
|---|---|---|---|
| Bugfix без змін API та скоупів | 1–3 дні | 3–5 днів | 1–2 тижні |
| Нова функція, ті ж скоупи | 1–4 тижні | 5–10 днів | 2–6 тижнів |
| Нові скоупи OAuth | 1–4 тижні | 7–14 днів | 3–7 тижнів |
| Переробка монетизаційної моделі | 2–5 тижнів | 10–21 день | 4–10 тижнів |
Що входить в роботу з оновлення
- Аналіз поточної версії застосунку та складання плану.
- Розробка змін (код, міграції, конфігурації).
- Тестування на staging-порталі.
- Підготовка метаданих та changelog для модерації.
- Супровід проходження модерації.
- Документація та передача доступів.
Ми оновили більш ніж 40 застосунків для Бітрікс24 за 7 років роботи. Команда інженерів гарантує проходження модерації з першого разу. Зв'яжіться з нами, щоб отримати консультацію щодо вашого проєкту.
Що дає професійний супровід?
Самостійне оновлення часто затягується через невраховані нюанси модерації. Наша команда виконує всю підготовчу роботу: від аналізу поточного застосунку до фінального деплою. Це скорочує загальний час виходу релізу на 30–50% порівняно з самостійним підходом. Отримайте консультацію — ми допоможемо спланувати оновлення вашого застосунку.