Разработка в старом проекте Битрикс: как вносить правки без риска для работающего сайта

Разработка в старом проекте на Битрикс — это внесение изменений в код, который работает на боевом сервере и опирается на устаревшие версии ядра и модулей. Задача разработчика — внедрить правку без нарушения текущей функциональности сайта. Ниже — порядок действий, карта рисков, критерии выбора между локальной правкой и обновлением основы, учебный пример и чек-лист приёмки.

Что считать старым проектом и какую задачу решает разработчик

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

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

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

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

Карта рисков: что фиксируем до первой правки

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

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

Ограничения версии ядра, модулей и окружения

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

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

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

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

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

Локальное исправление или обновление основы

Выбор между локальной правкой и обновлением основы зависит от бизнес-требований и допустимого уровня риска. Ниже приведены критерии сравнения вариантов.

Когда выбирают локальную правку

Локальная правка уместна, когда проект в целом работает стабильно, задача касается одного участка, а изменение можно изолировать. Например, поправить расчёт, добавить поле, изменить вывод блока. В этом случае риск ограничен, а результат виден быстро.

Когда выбирают обновление основы

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

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

Как подготовить безопасную среду

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

План возврата — обязательная часть работы. Нужно заранее понимать, как откатить изменение, если после выката появится ошибка, и сколько времени это займёт. Без плана возврата выкат не начинают.

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

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

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

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

Учебный пример (данные условные):

Входные условия

Интернет-магазин на Битрикс, каталог ~20 000 товаров. Ядро и модули не обновлялись годами. Логика оформления заказа находится в кастомном компоненте без документации. Стенд не синхронизирован с боевым сервером. Задача: исправить неверный расчёт скидки при определённых условиях оформления.

Порядок действий

Шаг 1. Фиксируем границы. Договариваемся, что меняем только расчёт скидки в оформлении заказа. Обновление ядра и модулей в эту задачу не входит и обсуждается отдельно.

Шаг 2. Заполняем карту рисков. Главные строки: потеря данных при оформлении заказа, сломанный соседний сценарий (например, расчёт доставки использует тот же код), расхождение стенда и боя.

Шаг 3. Готовим среду. Снимаем копию файлов и базы, разворачиваем её на стенде, сверяем поведение с боевым. Обнаруживается, что старый стенд отличается от боевого — его пересобирают из свежей копии. Это важный момент: работать на расходящемся стенде нельзя, иначе проверка ничего не доказывает. В учебном примере стенд пересобирают, чтобы исключить расхождения.

Шаг 4. Воспроизводим ошибку. На стенде повторяют условия, при которых скидка считается неверно, и убеждаются, что поведение совпадает с боевым. Без этого шага нельзя утверждать, что правка что-то исправила.

Шаг 5. Вносим изменение. Правка делается в локальной части проекта, а не в файлах ядра или модуля, чтобы её не перезаписало при будущем обновлении. Изменение оформляется отдельным набором правок.

Шаг 6. Проверяем. Сначала — исправленный сценарий. Затем — соседние сценарии, которые используют тот же код: расчёт доставки, итоговая сумма, сохранение заказа. Затем — сценарии, которые формально не связаны, но проходят через оформление заказа.

Шаг 7. Выкатываем и наблюдаем. После выката проверяют логи ошибок и поведение оформления заказа. Если появляется отклонение, срабатывает план возврата.

Наблюдаемый результат и проверка

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

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

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

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

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

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

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

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

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

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

Расширение задачи по ходу работы. «Заодно» обновить модуль или поправить соседний компонент — это отдельная задача с отдельными рисками. Её лучше выносить в отдельное согласование.

Отсутствие плана возврата. Если непонятно, как откатить изменение, выкат превращается в лотерею.

Правки на боевом сервере в обход репозитория. Через несколько таких правок никто не может сказать, какая версия кода настоящая.

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

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

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

Список того, что стоит подготовить:

• Описание задачи: что именно должно измениться и как это проверяется.
• Где проявляется проблема: раздел сайта, сценарий, условия воспроизведения.
• Фактические версии ядра, модулей и окружения — с боевого сервера, а не по памяти.
• Список сторонних решений и интеграций, которые затрагивает задача.
• Наличие стенда и его актуальность относительно боевого сайта.
• Наличие резервных копий и проверенного восстановления.
• Наличие системы контроля версий и порядок работы с ней.
• Кто отвечает за приёмку и по каким сценариям проверяет результат.
• Ограничения: что менять нельзя, какие сроки и окна выката допустимы.
• Доступы к системе контроля версий и тестовому окружению.

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

Когда подключать внешнего разработчика

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

Если проект требует регулярной работы, а не разовой правки, стоит заранее продумать, как организовать взаимодействие: кто ставит задачи, кто принимает результат, как передаются доступы. Об этом подробно — в материале Битрикс-разработчик в аренду — как организовать работу.

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

В любом случае перед стартом стоит договориться о границах задачи, способе проверки и плане возврата. Это снижает риск и для заказчика, и для исполнителя.