Один из самых острых вопросов при разработке на Битрикс - это миграции базы данных.
Какие же способы облегчить эту задачу есть на данный момент?
Способ 1 - никак
Оставляем перенос данных на откуп разработчика. Как правило, в таких ситуациях ID инфоблока указывается в коде числом.
Вводим правило "при создании инфоблока на площадке разработчика одновременно должен быть создан инфоблок на боевом сервере".
Правило перестаёт работать при выполнении одного из двух условий:
- рост команды и, как следствие, появление новичка, которому выдаются ключи к базе данных. Кровью написаны строки о том, как джуниоры случайно уничтожают БД "боевого" сервера.
- усталость и/или несогласованность работы нескольких разработчиков, возможно - личностный конфликт. Даже идеальный разработчик может хорошо провести выходные, с печальными последствиями для своей концентрации.
При бесконечном доверии разработчикам можно оставить такую схему деплоя изменений в базе данных.
Способ 2 - ресурсозатратный, но рабочий
Решение на базе консольных утилит mysqldump, grep и diff. Оно позволяет отслеживать изменения на уровне базы данных.
Суть же способа следующая:
- перед началом работы над задачей делается дамп бд с помощью mysqldump
- после окончания работы делается дамп бд
- затем с помощью скрипта, использующего grep и diff (утилита, позволяющая проходиться регулярными выражениями по тексту и утилита, сравнивающая содержимое двух файлов) выделяются произошедшие изменения
- изменения кладутся в .sql файл, который отсматривает и правит разработчик
- .sql файл выкатывается на боевой сервер и запускается там.
К плюсам можно отнести возможность автоматизации процессов выкатки.
Способ может дать серьёзные сбои при отличии id записей, и толком не работает, когда одни сущности ссылаются на другие. Но необходимость выкатывать подобные изменения бывает не так часто.
Способ 3 - рекомендованный Битриксом
Можно на каждую задачу писать специальный скрипт, описывающий с помощью API Битрикса, какие изменения должны быть внесены.
Например, создать новое свойство инфоблока
// добавим пользовательское свойство инфоблоку.
$arFields = array(
"ENTITY_ID" => "IBLOCK_".$iBlockChild."_SECTION",
"FIELD_NAME" => "UF_NOT_VIEW_DATE",
"USER_TYPE_ID" => "boolean",
"EDIT_FORM_LABEL" => Array("ru"=>"Не показывать дату", "en"=>"NOT VIEW DATE"),
);
$obUserField = new CUserTypeEntity;
$iUserFieldId = $obUserField->Add($arFields);
echo "New UserTypeEntity: ".$iUserFieldId."\n";
Это сложно: скрипт нужно написать, выкатить и запустить. Так гораздо сложнее, чем работать с приветливой админкой Битрикса.
Но есть и ряд преимуществ:
- разработчики учат API Битрикса (что они и так, в общем-то, должны делать) и открывают для себя ранее неизвестные методы. Реально зафиксировано повышение квалификации благодаря этому решению!
- всегда известно, кто и что конкретно поправил.
- есть возможность разделить зоны ответственности и повысить дисциплину.
- разработчик трижды думает, прежде чем вносить изменения на боевой сервер, и его мысли может понять и подхватить другой разработчик.
Есть набор best practicies, которые облегчают внедрение такого способа выкатки изменений. До них можно дойти своим умом или почитать
в отдельном посте.
Способ 4 - экспериментальный
Есть ребята, которые пишут сейчас свой модуль миграций. Пишут уже долго и мучительно и написали что-то только для инфоблоков, и то он обрабатывает не все ситуации. Правда на выходе наиболее чистый "код" миграции.
Жирный минус только один: поддержка только модуля инфоблоков.
В остальном - это очень интересное направление, которое бы стоило поддержать самому 1С-Битрикс.
Вместо послесловия
Как-то раз сотрудники Битрикса обмолвились, что они работают над полноценными миграциями, но "это в такой глубокой альфа-версии, что пока и говорить об этом рано". Пока что нам остаётся только ждать и мечтать.
О чём мечтать? Например о таких решениях: