Обновление модулей Битрикс: реестр, проверки на копии и приёмка результата

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

Что входит в задачу обновления модулей Битрикс и где её границы

Обновление модулей — часть регулярного обслуживания сайта. Речь идёт о модулях, которые установлены на сайте и входят в лицензию: система обновлений работает именно с таким набором. Это важно понимать заранее: если модуль установлен в папке `bitrix/modules`, система обновлений может затронуть его файлы, даже если функционал не активирован в настройках.

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

Отдельно уточните, что считается результатом. Формулировка «обновить всё» слишком широкая: она не даёт критерия приёмки. Рабочая формулировка — «модули обновлены до актуальных версий, доступных по лицензии, ключевые сценарии проверены на копии и на рабочем сайте, есть точка возврата».

Реестр модулей: какие данные собрать до начала

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

Что внести в реестр по каждому модулю:

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

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

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

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

Зависимости модулей и поддержка поставщика

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

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

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

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

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

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

Проверки на копии перед выпуском

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

Как организовать копию

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

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

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

Проверка не сводится к «сайт открывается». Пройдите по сценариям, которые приносят бизнесу результат:

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

Обязательно проверьте места с доработками под проект. Стандартное обновление перезаписывает файлы модуля, поэтому правки, внесённые непосредственно в системные файлы, будут утеряны. Это частая причина сбоев после обновления.

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

Порядок выпуска и план возврата

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

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

Порядок выпуска обычно такой:

1. Убедиться, что резервная копия снята и проверена. 2. Перевести сайт в режим, когда изменения не мешают посетителям, если это принято в проекте. 3. Запустить обновление согласованной группы модулей. 4. Сразу пройти быстрый набор проверок на рабочем сайте. 5. Если проверки пройдены — снять ограничения и зафиксировать результат в реестре. 6. Если нет — вернуться к плану возврата.

Не стоит обновлять всё сразу на большом проекте. Групповой выпуск даёт контроль: вы понимаете, после какой группы появилась проблема.

Учебный пример: обновление на тестовом контуре

Учебный пример. Данные условные, это не реальный проект.

Вводные условия. Интернет-магазин на Битрикс, около двухсот товаров, оформление заказа с оплатой и уведомлениями, обмен с внешней системой учёта. Сайт не обновлялся больше года. Есть тестовый контур, повторяющий рабочий сайт. Ответственный за выпуск — администратор сайта, решение об откате принимает руководитель проекта.

Шаг 1. Собрали реестр: перечислили модули, зафиксировали текущие версии, отметили модули с доработками и модули интеграции. Обнаружили, что два модуля давно не поддерживаются поставщиком.

Шаг 2. Сняли резервную копию рабочего сайта и проверили, что из неё разворачивается рабочий сайт. Развернули тестовый контур.

Шаг 3. Разбили модули на три группы: системные, оформление заказа и оплата, интеграции. Обновление начали с системной группы на тестовом контуре.

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

Шаг 5. Обновили группу оформления заказа. На тестовом контуре провели тестовую оплату и проверили, что статус заказа меняется корректно, а уведомления приходят.

Шаг 6. Обновили группу интеграций. Здесь проверка потребовала участия владельца внешней системы: обмен проверяли на тестовых данных, чтобы не задеть рабочие записи.

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

Шаг 8. Выпустили на рабочий сайт в согласованное окно, группами, с быстрой проверкой после каждой группы. Зафиксировали новые версии в реестре.

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

Что показал пример: основное время ушло не на само обновление, а на реестр, проверки и восстановление доработок. Это нормальное соотношение — именно эти шаги и делают задачу управляемой.

Как проверить результат и принять работу

Приёмка опирается на заранее согласованные критерии, а не на общее впечатление. Ниже — рабочий чек-лист.

• Реестр модулей заполнен: по каждому модулю указаны прежняя и новая версия, дата выпуска.
• Резервная копия снята до изменений и проверена на восстановление.
• Обновление прошло на копии, ключевые сценарии проверены там же.
• На рабочем сайте открываются главная и ключевые разделы, нет ошибок на страницах.
• Работает вход в административную часть, права пользователей сохранены.
• Проходит оформление заказа или отправка заявки от начала до конца.
• Уведомления уходят и доходят до получателей.
• Обмен с внешними системами работает, данные не потеряны.
• Доработки под проект на месте, ничего не перезаписано.
• Журналы ошибок проверены после выпуска, новых ошибок нет.
• Модули, оставшиеся на прежних версиях, отмечены с причиной.
• План возврата зафиксирован, ответственный за решение об откате известен.

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

Типичные ошибки и ограничения

Ошибки в этой задаче повторяются из раза в раз.

• Обновление сразу на рабочем сайте, без копии. Экономит время один раз и создаёт простой в самый неподходящий момент.
• Нет резервной копии или копия не проверена на восстановление. Копия, из которой нельзя развернуть сайт, копией не является.
• Реестр не ведётся. Через месяц никто не помнит, что обновлялось и что осталось.
• Игнорирование доработок. Правки внутри модуля могут быть перезаписаны при обновлении.
• Обновление всего сразу. При проблеме непонятно, какой модуль её вызвал.
• Нет плана возврата. Решение об откате принимается в спешке, когда сайт уже недоступен.
• Обновление в разгар кампании или в конце дня, когда рядом никого нет.

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

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

Какие исходные данные подготовить для оценки

Чтобы оценить объём работ, подрядчику или своему специалисту нужны конкретные данные. Чем полнее они собраны, тем точнее оценка.

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

Если по части пунктов данных нет, это тоже результат: значит, сначала нужно навести порядок в учёте, а уже потом планировать выпуск.

Ответственные и роли

У задачи должны быть роли, даже если её ведёт один человек.

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

Когда роли не распределены, выпуск затягивается: непонятно, кто имеет право нажать кнопку и кто отвечает за последствия.

Что делать дальше

Начните с реестра модулей — это самый дешёвый шаг с самой большой отдачей. Затем проверьте, что резервные копии снимаются и восстанавливаются. После этого можно планировать выпуск: группами, на копии, с проверками и планом возврата. Если нужен внешний исполнитель, подготовьте исходные данные из раздела выше — и уточните, что входит в работы, а что нет. Ориентир по составу и формату работ можно сверить в описании Сколько стоит поддержка сайта на Битрикс: тарифы и что входит.