Публікація розширення Firefox: де застрягає рев'ю в каталозі
Пакет зібрано, підписано й надіслано на перевірку — а через кілька днів повертається одним рядком «не відповідає політиці».
Що саме порушено, із формулювання незрозуміло: чи автоматика зачепилася за мініфікований код, чи перевіряльник не побачив обґрунтування для розширених дозволів.
Релізний цикл зупиняється: збірка готова, але опублікувати її не можна, а строки перевірки в каталозі заздалегідь не оголошуються й залежать від черги та типу змін.
Причини повернення пакета майже завжди технічні й передбачувані. Динамічне виконання коду, підключення зовнішніх скриптів, обфускація без доданих вихідних кодів та інструкції з відтворюваної збірки — це готовий привід для відмови.
Окремо ловлять розбіжність між заявленими дозволами та реальною поведінкою: якщо розширення запитує доступ до вкладок, але в описі про це немає жодного слова, модерація розширення поверне пакет на доопрацювання.
Саме рев'ю відбувається у два шари: автоматичні перевірки на небезпечні виклики та ручний розбір для тих збірок, де потрібно оцінити сенс поведінки.
Будь-яка зміна в дозволах або додавання зовнішніх звернень переводить оновлення в розширену перевірку, тому точкове виправлення коштує стільки ж часу, скільки великий реліз. Повторне надсилання без усунення першопричини приводить до того ж результату й зсуває чергу.
Розбираємо, як це закривається: збираємо пакет під вимоги каталогу, готуємо вихідні коди та пояснення для перевіряльників і ведемо листування до публікації — щоб цикл не йшов на другий і третій круг.
Ефект від налагодженого релізу: строки, відмови, відтворюваність
Перший вимірюваний ефект — передбачуваний строк проходження перевірки. Коли пакет збирається за одним регламентом (маніфест, обґрунтування кожного дозволу, відсутність віддалено підвантажуваного коду, декларація обробки даних), рев'ю перестає повертатися на формальності.
Цикл перевірки в каталозі Mozilla стає плановим: одне надсилання замість серії ітерацій «правка — очікування — правка».
Другий ефект — падіння частки відмов. Повернення на доопрацювання зазвичай спричиняє не логіка коду, а розширення дозволів під час оновлення, стиснений код без долучених вихідних кодів і дані, що збираються без оголошеної мети.
Правило «новий дозвіл додається лише під конкретну функцію, з поясненням в описі» прибирає цей клас відмов майже повністю — залишаються поодинокі випадки.
Третій ефект — відтворювана збірка. Зафіксовані версії залежностей, один збирач і детермінований порядок файлів в архіві дають однаковий результат у будь-якого інженера команди.
Хеш зібраного пакета збігається з тим, що пішов у каталог, тому відкат на попередній підписаний випуск займає хвилини, а не перезбирання з пам'яті.
Четвертий — прозорий реліз. Журнал змін пишеться мовою користувача, стабільний і тестовий канали розділені, кожне оновлення підтверджено підписом. Команда бачить, що саме отримали користувачі, а підтримка — з якої версії надійшло звернення.
Способи постачання в каталог: ручне, автоматичне, окремий канал
Розширення потрапляє до користувачів кількома шляхами, і вибір між ними визначає, хто відповідає за оновлення та перевірку коду.
Основний маршрут — каталог Firefox Add-ons: він роздає оновлення автоматично й перевіряє збірку перед видачею, але кожну версію потрібно зібрати, підписати й провести через рев'ю.
Спосіб доставки обирають за частотою релізів і за тим, наскільки жорстко потрібен ручний контроль на кожному кроці. Нижче — чотири робочі варіанти та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручне надсилання пакета | рідкісні релізи, один-два на квартал; потрібен контроль на кожному кроці | версія залежить від людини, кроки збірки й завантаження легко пропустити |
| Автоматична збірка й надсилання | регулярні релізи, відтворювана збірка, є автотести | ключі доступу зберігаються в захищеному вигляді; у разі падіння перевірок реліз блокується повністю |
| Самостійний канал оновлень | поширення всередині компанії або разом з іншим продуктом | хостинг оновлень, підпис і сумісність залишаються на вас, встановлення йде поза каталогом |
| Тимчасове завантаження для тестів | перевірка збірки до публікації, налагодження на живому профілі | живе до перезапуску браузера, не підписана, користувачам недоступна |
На практиці варіанти комбінують: на етапі розробки зручне тимчасове завантаження, для релізу — автоматичне надсилання в каталог, а самостійний канал залишають для закритих контурів, де встановлення з каталогу неможливе.
Етапи підготовки розширення: від аудиту до передавання
Пакет розширення рев'юери каталогу розбирають частинами: розпаковують архів, звіряють стиснений код з вихідними кодами й перевіряють, навіщо запрошено кожен дозвіл і кожен домен.
Тому «просто завантажити архів» перетворюється на цикл правок і повторних надсилань, який затягує строки релізу. Ми ведемо підготовку як проєкт із фіксованими етапами — на виході пакет, який проходить перевірку з першого-другого заходу.
- Аудит пакета. Розбираємо поточну збірку: які дозволи реально використовуються, чи є віддалено підвантажуваний код, чи залишилися стиснені ділянки, як збирається підсумковий архів.
- Приведення маніфесту до вимог каталогу. Звужуємо дозволи до фактично потрібних, прибираємо динамічне підвантаження скриптів, приводимо опис, іконки та заяву про обробку даних до формату картки.
- Схема каналів оновлення. Визначаємо, які збірки йдуть у публічний канал, які — у закритий тестовий, і як співвідносяться номери версій, щоб перехід користувача з тестової гілки на релізну проходив без відкатів.
- Підготовка вихідних кодів для перевірки. Збираємо читабельну версію коду та інструкцію з відтворення збірки — рев'юер має отримати саме той архів, який описано в інструкції.
- Надсилання на рев'ю та супровід. Реєструємо чернетку, відповідаємо на зауваження, вносимо правки точково, без повного перезбирання й втрати історії версій.
- Автоматизація випуску й передавання. Збірка, підпис і завантаження нової версії йдуть одним сценарієм, тому вміст архіву та номер версії не розходяться. Віддаємо схему каналів і порядок відповіді на зауваження — команда випускає оновлення сама.
Комплект на виході: налаштування, політики, документація
Комплект на виході — не архів із вихідними кодами, а робоча система: за нею випуск оновлення робить інженер, який не брав участі в розробці. Кожен документ відповідає на одне питання — навіщо розширенню цей дозвіл, як зібрати валідний архів, що перевірити до надсилання на рев'ю.
- Політика дозволів. Таблиця «дозвіл — функція — ділянка коду»: кожен обґрунтовано, невикористовувані вирізані. Більшість повернень з рев'ю в AMO — про розбіжність заявлених прав і реальної поведінки, тому список прав і опис у лістингу звіряються рядок за рядком.
- Регламент випуску оновлень. Покроковий порядок: підняти версію, зібрати архів, прогнати валідацію, надіслати, дочекатися перевірки, зафіксувати результат. Окремо зазначено, які типи змін проходять автоперевірку, а які йдуть на ручне рев'ю.
- Документація зі збірки. Команди збірки, склад виключених файлів, де лежать вихідні коди й як долучити їх, якщо архів мініфіковано або зібрано транспіляцією.
- Чек-ліст перед надсиланням. Версія та номер збірки не розходяться, маніфест посилається лише на наявні файли, дозволи збігаються з політикою, опис і скриншоти актуальні, політика конфіденційності опублікована.
- Шаблон лістингу. Короткий і повний опис, категорія, ключові слова — заготовка, яку залишається лише оновити під новий функціонал.
- Порядок відкату. Що робити в разі дефекту після публікації: як зняти проблемну версію, випустити виправлення й повідомити користувачів через опис оновлення.
Документи лежать у репозиторії поруч із кодом, а не в листуванні, тому живуть рівно стільки, скільки живе розширення. Передаємо їх разом із доступами до акаунта розробника — подальші публікації команда замовника проводить самостійно.
Кейс: скоротили цикл перевірки й прибрали повторні повернення
Що було на вході
Розширення збиралося в один мініфікований файл, а маніфест запитував доступ до всіх вкладок і зовнішніх хостів «на всякий випадок».
Перевірка Firefox Add-ons у такій конфігурації не може переконатися, що код робить лише заявлене, тому кожне надсилання поверталося з новим списком зауважень.
Ітерацій доходило до чотирьох — спершу права, потім вихідні коди, далі розбіжність картки з реальною поведінкою; строк виходу оновлення розтягувався до трьох тижнів.
Що змінили
Перезібрали маніфест: залишили мінімальні права за хостами, частину логіки перевели з постійних дозволів на запит у момент дії користувача. Збірку зробили відтворюваною — залежності зафіксовані, кроки описані, архів вихідних кодів збігається зі зібраним пакетом.
Прогнали лінтер і перевірку на заборонені прийоми (виконання зовнішнього коду, обфускація) до надсилання, а опис у картці привели до фактичного збору даних.
| Показник | До | Після |
|---|---|---|
| Ітерацій перевірки на реліз | 3-4 | 1 |
| Частка надсилань із поверненням | близько 60% | менше 10% |
| Строк виходу оновлення | до 3 тижнів | 4-5 днів |
Тепер оновлення проходить з першого проходу: перевіряльник підтверджує заявлені права й бачить збіг вихідних кодів зі збіркою.
Повторні повернення майже зникли, а дата релізу перестала бути непередбачуваною — планування віх знову опирається на календар, а не на листування з перевіркою.
Що робити, якщо пакет уже відхилено модератором?
Відхилення пакета — не вирок, а список конкретних зауважень: модератор указує, які пункти політики каталогу порушено й що саме потрібно виправити.
Найчастіше це запрошені дозволи, що не збігаються з реальною функціональністю, код, підвантажуваний ззовні, або нерозкрита обробка користувацьких даних. Перший крок — прочитати лист повністю й виписати зауваження за пунктами, не намагаючись вгадати мотив перевіряльника.
Далі — розбір зауважень із перевіркою за кодом. Ми відтворюємо збірку з вихідних кодів, звіряємо маніфест із фактично використовуваними інтерфейсами й прибираємо дозволи, без яких розширення працює: саме розбіжність «просимо більше, ніж потрібно» відхиляє більшість пакетів.
Окремо проходимо по зовнішніх підключеннях і віддалено виконуваному коду — каталог вимагає, щоб уся логіка лежала всередині пакета й була оглядною для перевіряльника.
Правки робимо точково: мінімальний набір змін, без попутного переписування сусідніх модулів, щоб повторна перевірка не відкривала нових питань.
Версію в маніфесті піднімаємо й готуємо коротке пояснення до надсилання — по рядку на кожне зауваження, із зазначенням файлу та суті правки. Так перевіряльнику не потрібно зіставляти стару й нову збірку наосліп.
Повторне надсилання йде тим самим каналом, звичайним оновленням, разом із цим поясненням.
Якщо зауваження спірне або сформульоване неоднозначно, корисніше не надсилати пакет знову, а відповісти в тому самому листуванні: спокійно, за пунктами, із посиланням на документацію платформи й проханням уточнити, який саме пункт політики застосовано до конкретного місця в коді.
Повторне надсилання ідентичної збірки без відповіді подовжує перевірку й підвищує шанс, що наступний розбір буде суворішим.
Звернення до модератора — робочий інструмент, а не конфлікт. Формулюйте питання вузько й по суті, фіксуйте відповіді в документації проєкту: тоді на наступному оновленні ті самі зауваження не повторяться.
Технічні сумніви: дозволи, маніфест, оновлення
Сумніви перед стартом зазвичай стосуються трьох речей: чи не відлякає користувача список запитаних прав, чи не зламає оновлення вже встановлені копії та що саме перевіряє рев'ю. Нижче — як ми закриваємо кожне з цих питань у проєкті.
Чи можна обійтися мінімальним набором дозволів?
Так, і це базовий принцип. Ідемо від сценарію: якщо функція працює через активну вкладку та явно перелічені хости, запит доступу до всіх сайтів не потрібен. В описі до кожного права даємо рев'юеру обґрунтування — навіщо це користувачу, а не «так зібралося».
Що робити, якщо розширення зібрано на старій гілці маніфесту?
Переводимо на актуальну: фоновий скрипт стає сервіс-воркером, а підвантажувані частини переносимо всередину збірки. Якщо продукт до переходу не готовий, залишаємо поточну гілку й фіксуємо строк, до якого міграцію потрібно закрити, щоб публікація не зупинилася.
Як оновлення доходять до встановлених копій?
Публікуємо версію — браузер сам підтягує її в користувачів, без їхньої участі. Для перевірок тримаємо окремий канал: збірка йде закритому списку тестувальників, у загальний потік — лише після підтвердження. Відкат робиться повторним завантаженням попередньої версії, номер збірки при цьому завжди зростає.
Чи можна підвантажувати код із сервера?
Ні, і це обмеження закладаємо в архітектуру одразу. Увесь виконуваний код має лежати всередині пакета — зовнішні скрипти й динамічний розбір рядків рев'ю відхиляє. Логіку, залежну від конфігурації, виносимо в дані, які розширення отримує, а не виконує.
Обговорімо задачу: надішлемо оцінку та план релізу
Щоб оцінка задачі була предметною, а не «плюс-мінус», до запиту достатньо долучити кілька артефактів. За ними видно обсяг правок у маніфесті, стан збірки та ймовірність повернення з рев'ю — із цього складається план релізу з етапами й точками контролю.
Що долучити до запиту:
- Посилання на репозиторій або архів із вихідними кодами та команду збірки, яка відтворюється з нуля.
- Поточний маніфест: запитані дозволи й обґрунтування кожного — у Firefox рев'юери дивляться на мінімально необхідний набір.
- Перелік мережевих запитів і зовнішніх сервісів, з якими спілкується розширення, і які дані туди йдуть.
- Чернетку картки в магазині: назва, опис, знімки інтерфейсу, локалізація — їх перевіряють разом із кодом.
- Посилання на політику конфіденційності або її чернетку, якщо збираються користувацькі дані.
- Дані акаунта розробника та роль, від імені якої йде публікація: без підтвердженого власника викладку не запустити.
- Побажання щодо автоматизації: ручне завантаження версії або збірка й надсилання на перевірку за міткою репозиторію.
Частину матеріалів готуємо самі й показуємо до старту робіт — відсутність пункту зі списку не привід відкладати розмову. Опишіть задачу як є: повернемося з оцінкою задачі та планом релізу, де видно етапи, відповідальних і точки, у яких потрібне ваше рішення.
