Обновление движка и модулей: как ничего не сломать

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

Зачем вообще обновлять движок и модули

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

• Закрытие уязвимостей. Главная причина. После публикации исправления информация о проблеме становится общеизвестной, и автоматические сканеры начинают искать сайты, где обновления нет.
• Исправление ошибок. Мелкие и крупные сбои в работе корзины, фильтров, расчёта доставки, отправки писем.
• Совместимость с окружением. Хостинги переходят на новые версии языка программирования и базы данных, и старый код перестаёт работать. Чем дольше пауза, тем болезненнее скачок.
• Новые возможности. Способы оплаты, службы доставки, удобства для администратора, улучшения производительности.
• Поддержка разработчиками. Устаревшие версии перестают получать исправления, и при возникновении проблемы вы остаётесь один на один с кодом, о котором никто не помнит.

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

Почему обновления ломают сайты

Страх перед обновлением не беспочвенен. Разберём типичные причины сбоев, чтобы понимать, против чего строить защиту.

Доработки в ядре и шаблоне

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

Несовместимые сторонние модули

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

Изменения в окружении

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

Миграции данных

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

Человеческий фактор

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

Тестовая копия: правило, которое нельзя пропускать

Обновлять рабочий сайт «вживую» допустимо только для самых простых проектов, и то с оговорками. Для магазина стандарт один: сначала обновление на тестовой копии, затем, после проверки, на рабочем сайте.

Что нужно от тестовой площадки:

• она максимально повторяет рабочий сайт: те же версии окружения, та же база (с обезличиванием, если это нужно), те же модули;
• она закрыта от поисковых роботов и от посетителей, чтобы не создавать дубли и не путать клиентов;
• в ней отключены реальные отправки писем покупателям, обмен с учётной системой и приём платежей, чтобы тесты не уходили в реальный мир;
• на ней можно безопасно ломать и пробовать заново.

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

Пошаговый регламент безопасного обновления

Ниже схема, по которой мы обновляем проекты. Её можно взять за основу и адаптировать под свои процессы.

Что обновлять и в каком порядке

Обновление нескольких компонентов одновременно усложняет поиск причины, если что-то пошло не так. Мы придерживаемся принципа «одно изменение за раз».

Мажорные и минорные обновления

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

Нужно ли обновляться сразу после выхода

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

Что проверять после обновления

Проверка результата так же важна, как само обновление. Составьте список сценариев и проходите его каждый раз. Тот, кто проверяет, должен действовать как покупатель, а не как администратор.

• Главная и внутренние страницы открываются без ошибок, оформление не разъехалось.
• Поиск и фильтры в каталоге выдают корректные результаты.
• В карточке товара работают выбор вариантов, галерея, расчёт цены и наличие.
• Товар добавляется в корзину, количество и итоговая сумма считаются верно.
• Оформление заказа проходит до конца с каждым способом доставки и оплаты.
• Покупателю и менеджеру приходят письма с правильным содержанием.
• Личный кабинет, регистрация и восстановление пароля работают.
• Обмен с учётной системой, маркетплейсами и службами доставки идёт без ошибок.
• В журнале ошибок нет новых записей, которых не было до обновления.
• Скорость загрузки ключевых страниц не ухудшилась.

Если что-то пошло не так

Даже при тщательной подготовке бывают сюрпризы. Главное иметь понятный план действий и не паниковать.

1. Оцените критичность. Если покупатели не могут оформить заказ, это авария, и нужно откатываться. Если разъехался второстепенный блок, можно исправить на месте.
2. Не лечите «на ходу» вслепую. Хаотичные правки на рабочем сайте часто делают хуже. Лучше вернуть копию и разобраться на тестовой площадке.
3. Откатывайтесь по заготовленному плану. Восстановите файлы и базу, проверьте сценарии, убедитесь, что заказы, поступившие во время обновления, не потерялись.
4. Найдите причину. Какой модуль или доработка конфликтует, что именно изменилось. Исправьте и повторите обновление.
5. Зафиксируйте урок. Дополните список проверок тем, что вы упустили в этот раз.

Когда обновление нужно отдать специалистам

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

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

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

Частые вопросы

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