Я проверял новую версию расширения у себя. Пользователи всё это время скачивали старую

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

Я показывал себе результат работы на своём компьютере и принимал его за результат для пользователя. Между этими событиями оставался незакрытый участок, который я просто перестал замечать.

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

Мы делаем сервис автоматизации для продавцов на Авито. Расширение браузера — часть этой работы, которую удобно проверять прямо во время разработки: изменил файлы, загрузил локальную сборку, посмотрел поведение.

Именно это удобство меня и подвело. В обычной работе перед глазами была локальная версия. Открыл браузер — увидел доработку. Повторил действие — убедился, что ошибка исчезла. Возвращаться после этого к вопросу, какой пакет сейчас скачивает посторонний человек, казалось лишним движением. Ведь исправление уже видно.

Но видимость исправления зависела от того, на каком компьютере смотреть. У пользователя не было моей папки на рабочем столе. Он устанавливал расширение из Chrome Web Store и получал тот пакет, который туда когда-то отправили.

Пока я проверял новые возможности, магазин продолжал отдавать прежнюю сборку. Я не могу по этому эпизоду посчитать потерянных клиентов или деньги. Зато могу точно назвать свою ошибку: подтверждением выпуска у меня служила проверка локальной установки.

Проверили магазин — и снова почти успокоились

При разборе появилась ещё одна ловушка. Сначала версию в магазине сравнили с основной веткой репозитория. Они совпадали. Получался удобный ответ: загружать нечего, всё актуально.

Только этот ответ не учитывал папку, в которой шла настоящая работа. Изменения оставались за пределами репозитория. Мы сопоставили две устаревшие копии, получили совпадение и едва не приняли его за доказательство порядка.

Меня в этом больше всего задело, что сама проверка выглядела разумной. Есть магазин, есть исходники в репозитории, номера версий одинаковые. Если не знать про отдельную рабочую папку, придраться почти не к чему.

Но я-то про неё знал. Она была частью моего рабочего процесса. Значит, я и должен был включить её в проверку, а не довольствоваться ответом про совпавшие номера.

После этого пришлось раскладывать всю цепочку: где лежат последние изменения, что сохранено в репозитории, что установлено в моём браузере и какой пакет опубликован в магазине. Пока эти точки не связаны, слово «готово» каждый участник понимает по-своему.

Описание тоже осталось в прошлом

Заодно всплыло расхождение, которое я сначала не относил к выпуску кода. Поведение расширения уже поменялось: в новой сборке появились автоматические нажатия. А в описании карточки магазина всё ещё было написано, что расширение кнопки не нажимает.

Для меня это был старый текст, до которого не дошли руки. Для человека, который устанавливает продукт, это описание того, чему он даёт доступ в браузере. Он не обязан читать нашу историю разработки и догадываться, какое обещание уже устарело.

Так в одну задачу пришлось собрать и пакет расширения, и описание его поведения. Я раньше мысленно разносил их: код — работа над продуктом, карточка — что-то про оформление. На деле человек получает их вместе и опирается на оба.

Что я изменил в приёмке

Теперь в наших правилах прямо записано: изменение расширения не считается законченным, пока исходники не попали в репозиторий, версия не поднята, а новый пакет не загружен в магазин и не отправлен на проверку. Если меняется поведение, в тот же заход обновляется описание карточки.

При этом отправка на проверку ещё не означает, что пользователь уже получил обновление. Этот последний переход нужно смотреть отдельно. Иначе легко заменить старую самоуспокоительную отметку «у меня работает» на новую — «мы всё отправили».

Мне не хочется обещать, что запись правила исключила человеческую ошибку. Пока выпуск требует отдельного действия, его можно забыть. Но теперь понятно, какой именно результат я принимаю и где искать незавершённую работу. Проверить локальное исправление недостаточно, чтобы закрыть задачу выпуска.

В этой истории не было сложной поломки браузера. Файлы были исправны, локальная сборка работала, магазин отдавал загруженный в него пакет. Сломан был мой способ принимать работу: я останавливал проверку раньше, чем до результата добирался пользователь.

Теперь, когда мне показывают исправление в моём браузере, я прошу показать ещё и то, что скачает человек, у которого нет доступа к нашему рабочему столу.