Обновление и поддержка решения

Публикация — только начало. Реальная ценность тиражного решения проявляется в том, как вы выпускаете обновления, держите совместимость с новыми версиями ядра и PHP и реагируете на обращения клиентов.

Жизненный цикл после публикации

После того как решение прошло модерацию и появилось в каталоге Маркетплейс, начинается основной этап работы — сопровождение. Он состоит из регулярных обновлений, поддержки пользователей и контроля совместимости с постоянно меняющейся платформой 1С-Битрикс.

Технически обновления распространяются через систему SiteUpdate: партнёр загружает новую версию в кабинете, она попадает на серверы updates.bitrix.info, а установленные копии получают её при очередной проверке обновлений. Клиенту не нужно ничего скачивать вручную — обновление приходит тем же каналом, что и обновления самого ядра.

Версии и семантика

Текущая версия решения хранится в файле install/version.php в виде массива с ключами VERSION и VERSION_DATE. Именно этот файл система сравнивает при проверке обновлений: если на серверах обновлений лежит версия выше, чем установленная, клиент увидит доступное обновление.

Рекомендуется придерживаться семантического версионирования вида MAJOR.MINOR.PATCH. Это делает поведение обновлений предсказуемым и для вас, и для клиентов, и упрощает ведение changelog.

Мажорные версии, ломающие обратную совместимость, стоит выпускать редко и всегда сопровождать понятным описанием миграции.

Updater-скрипты и структура обновления

Каждое обновление — это архив с новыми файлами решения и опциональными updater-скриптами. Файлы вида updater.php внутри пакета обновления выполняются автоматически при установке и позволяют провести миграцию: добавить поля в таблицы, обновить настройки модуля, зарегистрировать новые обработчики событий.

Внутри updater-скрипта доступен объект $updater, через который выполняются служебные операции. Типовой порядок действий:

1. Проверить установленную версию модуля и редакцию продукта.
2. Выполнить изменения структуры БД идемпотентно (проверять существование полей и таблиц перед созданием).
3. Обновить или дополнить настройки, не затирая пользовательские значения.
4. Зарегистрировать новые обработчики и агенты, снять устаревшие.

Совместимость с ядром и PHP

Платформа развивается: выходят новые версии ядра, повышаются требования к версии PHP, меняются рекомендованные API. Задача разработчика решения — поддерживать актуальную совместимость и не ломать работу на поддерживаемых конфигурациях.

• Тестируйте решение на актуальных версиях PHP, поддерживаемых платформой, и уходите от устаревших конструкций языка.
• Используйте документированные API ядра (например, ORM D7) вместо прямых запросов к таблицам, которые могут измениться.
• Отслеживайте deprecated-методы и заранее переводите код на актуальные аналоги.
• Указывайте корректные требования к редакции и версии продукта в описании решения.

Проверить окружение перед запуском тяжёлой логики можно, например, обратившись к константам платформы и функциям вида CheckVersion(SM_VERSION, '...'), чтобы аккуратно деградировать функциональность на старых сборках.

Техподдержка, отзывы и рейтинг

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

Как правило, при покупке клиент получает определённый период бесплатных обновлений и поддержки (часто — год), после чего продление платное. Это нужно заранее и прозрачно отразить в описании и лицензионном соглашении, чтобы не порождать конфликтных ситуаций.

• Отвечайте на обращения быстро и по существу — история переписки видна и влияет на репутацию.
• На негативные отзывы реагируйте конструктивно: предлагайте решение проблемы, а не спорьте.
• Ведите публичный changelog, чтобы клиенты понимали, что именно меняется в каждой версии.
• Типовые вопросы выносите в документацию решения и в раздел FAQ карточки.

Регламент выпуска и регрессионное тестирование

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

1. Прогнать регрессионное тестирование на чистой установке и на копии с демо-данными.
2. Проверить установку обновления поверх предыдущей версии, а не только чистую инсталляцию.
3. Убедиться, что updater-скрипты отрабатывают на разных редакциях и версиях PHP.
4. Обновить install/version.php, changelog и, при необходимости, документацию.
5. Загрузить пакет в кабинет и дождаться прохождения модерации.

Отдельная поддерживаемая ветка для критических исправлений позволяет выпускать патчи, не выкатывая клиентам недоделанную мажорную функциональность.

Снятие и архивация решения

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

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

Итог

Обновление и поддержка — это непрерывный процесс, а не разовая задача. Аккуратное версионирование через install/version.php, безопасные updater-скрипты, контроль совместимости с ядром и PHP, честные условия поддержки и быстрая реакция на обращения формируют репутацию решения и его коммерческий успех.

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