Как избежать проблем при переносе изменений в Bitrix с тестового на боевой сервер

  • 17.02.2016

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

  1. Использование системы контроля версий, как на тестовом, так и на рабочем (git). Master-ветка в git всегда стабильна. Новая разработка ведется на тестовом сервере в отдельных ветках git. Commit напрямую в master возможен только в случае необходимости исправления срочного бага. После тестирования перед релизом ветка разработки сливается в master, помечается тегом, по тегу выкатывается на рабочий сервер тоже с помощью git, не в ручную. В случае появления ошибок остается возможность откатиться на предыдущую версию также одной командой и восстановить все как было. Возможен также более продвинутый способ работы с ветками в git (см. https://habrahabr.ru/post/106912/), но минимум хотя бы такой.
  2. git позволит управлять только кодом и файлами (например картинками, да и то не всеми, а только теми, которые не заливаются пользователем, папка upload исключается из git), но не позволит управлять структурой базы данных и данными в ней. Для того, чтобы вынос на рабочий данных из БД не происходил вручную, пишутся скрипты миграции. Т.е. не через админку добавляется новый инфоблок и настраиваются свойства в нем, а пишется скрипт на php с использованием API битрикс, который автоматически создаст нужный инфоблок с нужными свойствами. При релизе скрипт запускается 1 раз на рабочем сервере, чтобы создать нужную структуру/данные в БД. И по-хорошему нужно писать еще скрипт обратной миграции, чтобы была возможность отката к предыдущей версии БД. Но это уже не так обязательно. Миграции - самая затратная часть - на нее уходит больше всего времени.
  3. И все равно, даже при таком подходе останется ручная работа: миграцией в битриксе не перенести настройки списков и форм редактирования инфоблоков. Нелегко будет также переносить данные в инфоблоках (новости, фотографии к ним), если их делать на тестовом - лучше их делать сразу на рабочем. Из-за несоответствия БД на рабочем и тестовом могут отличаться id инфоблоков, так что время от времени БД с рабочего и папку upload имеет смысл переливать обратно на тестовый. Обновление битрикса до новой версии также лучше делать сразу на рабочем, а потом переносить на тестовый целиком - тоже, кстати, затратная часть это обновление.
  4. Админка битрикса работает так, что она сама меняет содержимое файлов. Т.е. возможна ситуация, когда файлы будут на рабочем изменены и эти изменения будут отсутствовать git. Поэтому время от времени нужно совершать commit в master-ветку не с тестового, а с рабочего сервера тоже.